11.3.1 Загальні положення
У цьому підрозділі встановлено, яким чином стандарти, які посилаються на цей стандарт, можуть застосовувати поняття несуперечності та узгодженості, визначені вище. Твердження про несуперечності та узгодженості з цим стандартом повинні бути наявними в тих стандартах, які на нього посилаються, щоб уникнути неузгодженості та неоднозначності.
11.3.2 Несуперечність
Деяка архітектура, основні положення, багаторівнева модель, модель з єдиним рівнем, означення послуги або опис протоколу, в яких твердиться про Несуперечність щодо цього стандарту та інших ІТU-Т Рекомендацій | міжнародних стандартів з ЯП, що доповнює його, повинні обирати застосовні елементи з установленого списку, а саме:
«Ця {архітектура, багаторівнева модель, модель з єдиним рівнем, визначання послуги чи опису протоколу}2)
а) використовує поняття, введені в основних положеннях з ЯП з ідентичними визначеннями і термінологією, для таких термінів...;
b) розширює поняття, визначені в основних положеннях з ЯП, для таких термінів...;
с) визначає такі поняття...».
Останній елемент з наведеного вище списку повинен використовуватися в тому випадку, коли деякий термін застосовують у значенні, відмінному від того, що міститься в цьому стандарті.
11.3.3 Узгодженість
11.3.3.1 Узгодженість деякої архітектури, основних положень або моделі Деяка архітектура, основні положення або багаторівнева модель, яка є узгодженою з цим стандартом і яка уточнює вміст цього стандарту, повинна містити твердження:
1) Ці поняття виведено із затверджених інтерпретацій базової еталонної моделі ВВС (див. Rес. ІТU-Т.Х.200 | ІSО/ІЕС 7498-1).
2) Під час формулювання твердження невідповідні елементи треба вилучити.
«Ця архітектура, основні положення або багаторівнева модель є узгодженою з основними положеннями з ЯП в тому, що вона описує операції (дії) та механізми, які визначено в основних положеннях з ЯП».
11.3.3.2 Узгодженість деякого опису протоколу
Деяке визначення протоколу, яке є узгодженим із цим стандартом, повинно містити твердження:
«Це визначення протоколу узгоджене з основними положеннями з ЯП в тому, що воно описує функції, які належать окремому рівню, як це встановлено у відповідному розділі цього документа».
11.4 Несуперечність та узгодженість з ITU-T Rec. X.200 | ISO/IEC 7498-1
a) цей стандарт є несуперечним щодо ITU-T Rec. X.200 | ISO/IEC 7498-1;
b) цей стандарт є узгодженим із підрозділами 5.10, 7.2, 7.4, 7.5 та 7.6 ITU-T Rec. X.200 | ISO/IEC 7498-1.
ДОДАТОК А (обов'язковий)
МОДЕЛЬ ЯКОСТІ ПОСЛУГ ДЛЯ ВВС
А.1 Вступ
Модель ЯП для ВВС визначає принципи архітектури, поняття і структури, на яких ґрунтується забезпечення ЯП у ВВС. Сама модель не встановлює параметри ЯП інформації з ЯП, якими обмінюються під час встановлювання ЯП.
Модель ЯП для ВВС разом зі змістом розділу 6 забезпечує основу для застосовування розділів 7, 8 і 9 до ВВС, для описування забезпечування і керування ЯП ВВС комунікацій.
А.2 Принципи архітектури
Модель ЯП для ВВС заснована на поняттях базової еталонної моделі взаємозв'язку відкритих систем і основних положень керування ВВС.
У моделі розглядають два класи об'єктів, що беруть участь у керуванні ЯП у відкритих системах:
— системні об'єкти ЯП (об'єкти, що відіграють роль у рамках усієї системи);
— об'єкти ЯП-рівня (об'єкти, зв'язані з функціюванням конкретної (М)-підсистеми). Системними об'єктами ЯП є ті, що координують відповідність вимогам, які поставлено до
системи. Системні об'єкти ЯП взаємодіють з об'єктами ЯП рівня для відстежування і керування функціюванням системи. Крім того, вони можуть реалізувати керовані об'єкти як засоби взаємодії об'єктів керування системою для забезпечування ЯП у системі.
Об'єкти ЯП-рівня здійснюють безпосереднє керування об'єктами протоколу, необхідними для підтримання ЯП-з'єднань. У процесі цього вони відповідають на керівні впливання з боку системних об'єктів ЯП, і можуть погоджувати з користувачем послуг рівня і їх безпосереднім підлеглим постачальником послуг поставлені до них вимоги.
На рисунку А.1 показано взаємозв'язок між системними об'єктами ЯП і об'єктами ЯП-рівня. Крім зв'язку з (М)-об'єктами ЯП, системні об'єкти ЯП зв'язані з (Ы)-користувачем-послуг і з (М-1)-поста-чальником-послуг [(М)-об'єкти ЯП не є (М)-об'єктами в сенсі базової еталонної моделі ВВС]. Подробиці цієї взаємодії не розглядають під час моделювання (М)-рівня.
У відкритих системах, що відповідають деякому набору ВВС стандартів, деякі об'єкти ЯП можуть бути порожніми (тобто можуть не виконувати ніяких функцій, зв'язаних із керуванням ЯП). Не потрібно, щоб кожен об'єкт ЯП був присутнім на кожному рівні. Отже, окремі реальні відкриті системи можуть бути сконфігуровані так, щоб володіти лише підмножиною із найзагальнішого набору об'єктів ЯП, описаного в цьому підрозділі.
Рисунок А.1 — Взаємозв'язок системних об'єктів із ЯП-об'єктами ЯП рівня
А.З Мотивація забезпечення ЯП
Система, що реалізує заходи для встановлювання, регулювання й відстежування ЯП на своїх з'єднаннях, відповідає вимозі підприємства з передбачуваності тих або інших аспектів своїх комунікацій. Ця вимога представлена в системній політиці (регламенті); ця політика встановлює обмеження, у межах яких повинне відбуватися функціювання системи.
У свою чергу, з цієї системної політики випливає політика рівня, що застосовують до кожного рівня стека протоколів.
На рисунку А.2 представлено загальну модель того, як забезпечення послуг може відповідати вимогам користувачів послуг. Існують два види загальних керівних вхідних даних для забезпечування послуг:
— вимоги з ЯП користувача, що встановлюють початкові умови для забезпечування послуг;
— результати спостереження за функціюванням системи зв'язку, який забезпечує зворотний зв'язок, що може призвести до зміни мережею своїх параметрів функціювання.
Рисунок А.2 - Вимога до ЯП
А.4.1 Інформація, що підлягає обміну
Об'єкти ЯП обмінюються відповідними до ЯП інформаційними елементами (у вигляді ЯП-параметрів), що можуть бути таких видів:
— вимоги з ЯП: сформульована вимога до однієї або кількох характеристик ЯП. Прикладом є набір параметрів ЯП, використовуваний в узгодженні ЯП на конкретному (N)-ПДП.
— дані ЯП: ЯП-інформація, відмінна від вимог до ЯП. Вона включає міри, попередження, запити інформації тощо.
Термін (N)-ЯП вимогу використовують для позначання параметрів вимог до ЯП, якими обмінюються через (N)-границю послуг між об'єктами в рамках (N)-підсистеми.
А.4.2 Інформаційний потік на (N)-границі послуг
У загальному випадку (N)-користувач-послуг і (N)-постачальник-послуг обмінюються інформацією, зв'язаною з ЯП. На рисунках А.3 і А.4 наведено типові приклади потоку вимог до ЯП на (N)-границі послуг для непідтверджених і підтверджених (N)-засобів послуг відповідно (приклад узято з існуючих стандартів послуг ВВС). Однак рисунки А.3 і А.4 не покривають усі можливі випадки.
Рисунок А.З — Приклад потоку вимог з ЯП у непідтвердженому (N)-засобі-послуг
Рисунок А.4 — Приклад потоку вимог з ЯП у підтвердженому (N)-засобі-послуг
А.4.3 Інформаційний потік у (N)-підсистемі
На рисунках А.5 і А.6 представлено загальний вигляд потоку вимог до ЯП між (N)-підсистемами й усередині (N)-підсистем для випадків вихідної і вхідної інформації (такі інформаційні потоки описані в деталях у А.5.7 і А.5.8).
Потік називається вихідним, якщо вимоги до ЯП, виражені в деякій точці (N)-підсистеми приводять до однієї з подій:
— (можливо модифіковані) вимоги з ЯП передаються до (М-І)-підсистеми через (N-1)-границі послуг;
— (можливо модифіковані) вимоги по ЯП повідомляють рівноправній (N)-підсистемі з (N)-протоколом. Аналогічно, потік називають вхідним, якщо (N)-підсистема одержує ЯП вимоги або:
— з (N-1)-підсистеми через (N-1)-границі послуг; або
— містяться в (N)-протоколі, переданому рівноправною (N)-підсистемою.
Кожний з потоків, показаних на рисунках А.5 і А.6, має відповідний «зворотний» потік, що має місце, якщо об'єкт одержує вимоги з ЯП і дійде висновку, що він не може їх задовольнити. У цьому випадку відповідальність за дії повертається до попереднього об'єкта потоку.
Крім цього, (N)-підсистема може самостійно ініціювати вихідний чи вхідний потоки без відповідних вимог, що переміщаються відповідно через (N-1)-чи (N)-границі послуг. Подібна ситуація виникає у разі виявлення одним з об'єктів (N)-підсистеми таких змін у досягнутій ЯП, що необхідне втручання. Події такого типу можуть приводитися в дію функціями відстежування ЯП у (N-підсистемі, або виникати як результат взаємодії з рівнем або системним керуванням. У цих випадках може бути справедливий зображений на рисунку А.5 вихідний потік без верхнього обміну між (N)-користувачем-послуг і (N)-ФПР. Аналогічно, зображений на рисунку А.6 вхідний потік ЯП-вимог може використовуватися без нижнього обміну даними між (N-1)-постачальником-послуг і (N)-ФПР.
Рисунок А.5 — Вихідний потік ЯП-вимог усередині (N)-підсистеми
Рисунок А.6 — Вхідний потік вимог до ЯП усередині (N)-підсистеми
На рисунках А.5 і А.6 показано декомпозицію (N)-підсистеми на (N)-ФПР, (N)-ФРЯП і (N)-ПС, ролі яких детально пояснено нижче. Ця декомпозиція є детальнішим описом порівняно з тим, що використовують у визначенні послуг рівня. Весь потік між (N)- і (N-1)-підсистемами розглядають як переданий у (N-1)-примітив послуг, незалежно від того, чи моделюється він у цьому розділі як такий, що протікає між (N-1)-ПС і (N)-ФПР, чи між (N-1)-ФПР і (N)-ПС.
А.5 Рівнева модель ЯП для ВВС
А. 5.1 Вступ
Рівнева модель ЯП для ВВС відображає лише ті аспекти потоків вимог з ЯП і даних ЯП через границі послуг та всередині (N)-підсистем, що зв'язані з роботою протоколів рівня. Вона моделює взаємодію, за допомогою якої (N)-підсистеми на різних рівнях можуть запросити, погодити чи декларувати ЯП, на якому будуть функціювати вони і їхні підлеглі постачальники послуг. Більш того, вона моделює взаємодію, за якою може відбуватися обмін вимірами ЯП, попередженнями з ЯП та іншою інформацією з метою прогнозу, чи досягнутого ЯП та виміри чи регулювання. Ця взаємодія може мати місце в будь-який момент часу: вона не обмежена встановленням зв'язку чи асоціації і не повинна в обов'язковому порядку збігатися з моментами обміну даних, хоча в багатьох випадках відбувається саме так.
Інші потоки інформації (наприклад, потоки інформації, що використовують керування системами) знаходяться поза сферою стандарту.
Для виконання своїх функцій у багатьох випадках об'єктам ЯП рівня може знадобитися послатися на збережений контекст ЯП або одержати доступ до інформації, забезпечений системними об'єктами ЯП. Проте ці питання не розглядають у моделі рівня ЯП для ВВС.
Примітка. Ця модель рівня для ЯП не покриває випадків множинних рівноправних систем і багатоабонентського функціювання, а також випадків якої-небудь кореляції або синхронізації між окремими обмінами даними. Зокрема, вона не охоплює вимог з ЯП для обробляння транзакцій. Подібні загальні можливості ВВС будуть долучати до наступних редакцій стандарту у процесі узгодження.
А.5.2 Рівні і підрівні
Вважають, що відкрита система організована у виді семи (N)-підсистем, що можуть функціювати і керуватися автономно. Деякі (N)-підсистеми далі декомпозуються відповідно до аналогічних принципів незалежності й автономії (це особливо справедливо для рівнів 2, 3 і 7).
Рівнева модель ЯП для ВВС призначена для подвійного застосовування:
— для (N)-підсистем, що далі не декомпозуються, тобто (N)-підсистем, що включають єдиний (N)-об'єкт-протоколу, що повністю виконує приписи протоколу для рівня ВВС (наприклад, транспортна підсистема ВВС, що охоплює суб'єкт транспортного протоколу ВВС);
— для автономного поділу (N)-підсистеми, тобто ОПП або функцій усередині відкритої системи, що відповідають підкомпонентам (N)-рівня.
А.5.3 Ролі (N)-користувача-послуг
У цьому підрозділі описано ті аспекти операцій (N)-користувача-послуг, що відповідають керуванню ЯП усередині (N)-підсистеми.
Під час обміну ЯП-інформацією на (N)-ПДП (N)-користувач-послуг може виступати в одній з таких ролей:
— як замовник, він посилає ЯП-інформацію (N)-постачальнику-послуг і, можливо, одержує відповідну інформацію від (N)-постачальника-послуг;
— як одержувач, він одержує ЯП-інформацію, доставлену (N)-постачальником-послуг і, можливо, посилає відповідну відповідь.
Треба зазначити, що (N)-користувач-послуг виступає в ролі замовника й одержувача лише протягом (N)-засобу-послуг; отже, у випадку (N)-послуг у режимі з установленням з'єднання, окремий (N)-користувач-послуг може відігравати різну роль у різних (N)-засобах-послуг протягом одного або декількох (N)-з'єднань.
А.5.4 Роль (N-1)-постачальника-послуг
У цьому підрозділі описано ті аспекти операцій (N-1)-постачальника-послуг, що відповідають керуванню ЯП усередині (N)-підсистеми.
Під час обміну ЯП-інформацією на (N-1)-ПДС (N-1 )-постачальника-послуг виконує такі дії:
— одержує ЯП-інформацію від (N-І)-користувача-послуг, діючи як замовник і, можливо, відправляє відповідну інформацію тому самому (N-1)-користувачу-послуг;
— відправляє ЯП-інформацію (М-І)-користувачу-послуг, діючи як одержувач, і можливо, одержує відповідні відповіді від того самого (М-І)-користувача-послуг.
А.5.5 Роль об'єктів ЯП-рівнів
А.5.5.1 (N)-функція-керування-політикою
(N)-функція-керування-політикою визначає політику, що повинна застосовуватися до функцію-вання (N)-підсистеми. Вона визначає обмеження, за яких приймають всі рішення (N)-підсистеми. Таким чином, (N)-ФПР моделює будь-які дії, які треба виконувати для керування функціюванням (N)-підсистеми.
Наприклад, (N)-ФПР може застосовувати політику безпеки. Така політика не належить до сфери стандарту, але (N)-ФПР представляє точку взаємодії, у якій знання ЯП може впливати на забезпечення безпеки, і в якій розуміння безпеки можуть впливати на забезпечення ЯП. Завдяки цій функції (N)-ФПР може автономно ініціювати вхідний чи вихідний потік, як описано у А.5.8 чи А.5.7 відповідно.
