Действующий
b) вероятность возникновения ошибок при установлении соединения;
c) задержка освобождения соединения;
d) вероятность возникновения ошибок при освобождении соединения;
e) устойчивость соединения.
6 Вводное описание уровней ВОС
6.1.1 Общая архитектура ВОС, описанная в
разделе 5, устанавливает принципы, на основе которых была разработана эталонная модель ВОС путем формирования конкретных уровней и их внутреннего состава.
6.1.2 Эталонная модель содержит семь уровней (
рисунок 11):
а) прикладной уровень (уровень 7);
Рисунок 11 - Семь уровней эталонной модели и протоколы равноправных логических объектов
b) уровень представления данных (уровень 6);
c) сеансовый уровень (уровень 5);
d) транспортный уровень (уровень 4);
e) сетевой уровень (уровень 3);
f) уровень звена данных (уровень 2);
g) физический уровень (уровень 1).
6.1.3 Самым верхним является прикладной уровень, который состоит из прикладных логических объектов, взаимодействующих в функциональной среде ВОС. Нижние уровни предоставляют услуги, посредством которых взаимодействуют логические объекты прикладного уровня.
6.1.4 Уровни с 1-го по 6-й вместе с физической средой ВОС обеспечивают поэтапное расширение предоставляемых услуг связи. Граница между двумя уровнями обозначает ступень в расширении этих услуг. Последние определяются соответствующими стандартами на услуги ВОС, а функционирование уровней определяется соответствующими стандартами на протоколы ВОС.
6.1.5 Не все открытые системы содержат исходного отправителя или конечного получателя данных. Если физическая среда ВОС непосредственно не соединяет все открытые системы, некоторые открытые системы действуют только как ретрансляционные, передающие данные в другие открытые системы. Таким образом, функции и протоколы, обеспечивающие передачу данных, предоставляются нижними уровнями (см.
рисунок 12).
Рисунок 12 - Обмен данными через ретрансляционную открытую систему
6.2 Принципы разбиения на семь уровней эталонной модели
6.2.1 Следующие принципы были использованы для определения семи уровней эталонной модели. Эти же принципы будут полезными в качестве руководства при разработке стандартов ВОС.
Примечание - Не всегда можно доказать, что выбранная уровневая организация является наилучшим решением. Однако существуют принципы, основываясь на которых можно решить, где должны проходить границы между уровнями и сколько должно быть границ:
a) не следует создавать слишком много уровней, потому что это усложнит системотехническую задачу их описания;
b) проводить границу следует в том месте, где описание услуг является наименьшим и число операций взаимодействия через границу сведено к минимуму;
c) следует создавать отдельные уровни для выполнения таких функций, которые явно различаются по реализующим их процессам или используемым техническим решениям;
d) следует сосредоточивать аналогичные функции в одном и том же уровне;.
e) проводить границы следует в том месте, на которое указывает опыт;
f) следует формировать уровень из легколокализуемых функций. Это позволяет в случае необходимости полностью перестроить уровень и существенно изменить его протоколы для использования новых достижений в области архитектуры, аппаратных и программных средств, не изменяя при этом услуги как получаемые от смежных уровней, так и предоставляемые им;
g) проводить границу следует в том месте, где в какой-то момент времени может оказаться полезным наличие соответствующего стандартного интерфейса.
1 В настоящем стандарте не рассматриваются преимущества и недостатки внутренних интерфейсов в открытых системах. В частности, ссылка на
принцип g) не должна означать необходимость стандартов для таких внутренних интерфейсов.
2 Важно отметить, что ВОС не требует стандартизации интерфейсов внутри открытых систем. Более того, когда определяются стандарты для таких интерфейсов, соответствие этим стандартам не рассматривается как признак открытости;
h) следует создавать уровень тогда, когда ощущается необходимость в другом уровне абстракции при обработке данных, например в морфологии, синтаксисе, семантике;
j) следует предусмотреть возможность такого изменения функций или протоколов уровня, которое не оказывает влияния на другие уровни;
к) для каждого уровня следует создавать интерфейсы только с вышерасположенным и нижерасположенным уровнями.
Принципы, указанные ниже, применимы и к подуровням;
m) создавать новые подгруппы в пределах уже существующих групп функций и образовывать из них подуровни в рамках одного уровня следует в том случае, когда этого требуют специфические виды услуг;
n) в необходимых случаях следует создавать два или более подуровней с общей и поэтому минимальной функциональностью, чтобы обеспечить интерфейсные операции с соседними уровнями;
р) следует предусмотреть возможность обхода подуровней.
6.3.1 В
разделе 7 для каждого из семи уровней, определенных выше, дана следующая информация:
b) услуги, предоставляемые вышерасположенному уровню нижерасположенным;
c) функции, выполняемые уровнем, и использование услуг, предоставляемых нижерасположенным уровнем.
Приводимое описание не содержит полного определения услуг и протоколов для каждого уровня. Это является предметом отдельных стандартов.
6.3.2 Средства и функции, перечисленные в
разделе 7 для каждого уровня, представляют набор архитектурных возможностей. Определения услуг, полученные из определений конкретного уровня, могут включать в себя часть или все средства и могут не сопровождаться некоторыми или всеми параметрами качества услуг, определенными для каждого уровня в разделе 7 и в
5.10 настоящего стандарта. Спецификация протокола, полученная на основе этих определений для конкретного уровня, может включать в себя некоторые или все функции, определенные для уровня. Такие услуги или протокол не налагают ограничения ни на использование, ни на привлечение функций, которые не перечислены.
6.4 Комбинация режимов с установлением соединения и без установления соединения