РАЗДЕЛ 6. СЕТЬ Х.25

РАЗДЕЛ 6. СЕТЬ Х.25.

 

В 1974 г. МККТТ издало первый проект стандарта Х.25 («Серая книга»). Он был пересмотрен в 1976, 1978 и 1980 ГГ., затем в 1984 г., после чего издан в виде рекомендаций, известных как «Красная книга», в 1985 г. В 1988 году была издана «Синяя книга». Исходный документ представлял в основном предложения трех новых для того времени сетей коммутации пакетов Datapac (Канада), Tymnet и Telenet (обе США). С 1974 г. проект стандарта Х.25 расширялся за счет включения многих возможностей, сервисных средств и режимов. И в настоящее время стандарт Х.25 занимает господствующее место как стандарт пользовательского интерфейса для широкого класса сетей коммутации пакетов.

 

Стандарт Х.25 определяет процедура обмена данными для устройств передачи данных между пользователями и узлом сети коммутации пакетов. Формальное наименование стандарта Х.25 следующее - «Интерфейс между терминальным оборудованием данных и оконечным оборудованием цепей данных для терминалов, функционирующих в пакетном режиме в сетях передачи данных общего пользования».

 

Х.25 используется в сетях для установления процедур взаимодействиячерез сеть между двумя устройствами данных (ООД) посредством определения сессий этих устройств с соответствующим конечным оборудованием цепей данных (АКД). Таким образом, основная идея рекомендуемого стандарта заключается в обеспечении единых процедур взаимодействия между пользовательскими ООД.

 

Стандарт Х.25 не содержит алгоритмов маршрутизации.

Схемы фиксированной или динамической маршрутизации пакетов в сети, отнесены к специфике реализации, поскольку эта специфика полностью определяется при поставке системы.

Хотя интерфейсы ООД/АКД на каждом конце сети не зависят друг от друга, тем не менее этот стандарт обеспечивает сквозное (end-to-end) согласование, поскольку выделенный трафик пересылается между оконечными пунктами сети.

Рекомендуемый стандарт является асимметричным, т.к. определяется только одна сторона сетевого интерфейса (т.е. ООД/АКД).

 

На рис. 9.1 показано место стандарта Х.25 в структуре сети по отношению к средствам переключения и маршрутизации.

Поток передается из ООД А в промежуточный узел, который может быть узлом входа пользователя в сеть (в терминах Х.25 - ОКД). В этом узле пользователя А обслуживают физический уровень (1), уровень передачи данных (2, LAPB) и сетевой уровень (3, Х.25). В этом примере пользователь А идентифицирует себя в сети номером логического канала (LCN) 11.

Далее данные поступают к программным средствам маршрутизации, которые выполняют функции коммутации.

Эти функции не являются частью стандарта Х.25.

После этого данные возвращаются в Х.25 (и в более низкие уровни) и выводятся из промежуточного узла (который может являться сетевым узлом пользователя В) в ООД В.

Сетевой узел назначает номер логического канала 16 для сеанса с ООД В.

 

Реальная ценность стандарта:

1. Принятие стандарта производителями сетевого оборудования создает условия для более простого согласования между изделиями разных производителей.

2. Стандарт прошел множество пересмотров и представляет собой вполне зрелый документ. Стандарт находит широкое применение с 1980 г., и множество систем реализованы на его основе. Изменения и совершенствования введенные в документ до настоящего времени, отражают опыт, накопленный в работе с интерфейсами пакетных сетей.

3. Использование стандарта позволяет снизить стоимость сетей, обеспечиваемое применением стандартного оборудования и программных средств.

4. Гораздо легче предоставить требования изготовителю в том, чтобы сеть отвечала стандарту Х.25 нежели создавать документ спецификаций объемом порядка 180 страниц.

5. На уровне передачи данных с HDLC/LAPB обеспечивается только восстановление от ошибок и учет передачи данных на отдельной связи между ООД и АКД. Стандарт Х.25 обеспечивает более высокий уровень поддержки этих функций, устанавливая учет передачи данных между каждым посылающим ООД и его АКД (узел вхождения в сеть) и каждым приемным ООД и его АКД (узел выхода из сети). Другими словами, обеспечивается поддержка от конца до конца, чего не дает HDLC/LAPB.

 

Тема 6.1. Уровни стандарта Х.25.

 

Х.25 и физический уровень.

Как показано на рис. 9.1, уровень коммутациипакетов из рекомендаций стандарта Х.25 соответствует третьему уровню модели МОС. На самом деле рекомендации стандарта Х.25 охватывают не только третий уровень,… Рекомендуемый интерфейс физического уровня между ООД и АКД установлен Х.21.

Х.25 и уровень передачи данных.

В стандарте Х.25 предполагается, что уровень передачи данных - LAPB. Этот линейный протокол является подмножеством HDLC. Это позволяет, но не…   Пакет Х.25 транспортируется в кадре LAPB как поле I(информационное).

Стандарты, сопутствующие Х.25.

Использование Х.25 предполагает наличиетакже некоторых других стандартовв дополнение к тем, которые относятся к уровням физическому и звену… Следующие сопутствующие стандарты используются как часть стандарта Х.25.  

Рекомендация Х.10: Категории доступа оконечного оборудования данных (ООД) к сетям данных общего пользования (СДОП) и/или цифровым сетям интегрированного обслуживания (ISDN) через оконечные адаптеры.

Х.10 определяет различные категории доступа ООД к сетям различных типов.

Конкретно стандарт определяет интерфейс с сетями:

а) коммутации каналов;

б) коммутации пакетов;

в) арендованными каналами.

Кроме того стандарт определяет интерфейс терминалов с сетью ISDN.

 

Рекомендация Х.92: Гипотетические эталонные соединения для синхронных сетей данных общего пользования.

 

Эта рекомендация определяет соединения, устанавливаемые для ООД, СКД (станция коммутации данных) и АКД в сетях данных.

На Х.92 ссылаются многие сетевые стандарты, например Х.25 и Х.75.

Поэтому, подобно другим стандартам, Х.92 служит основой для других стандартов более высокого уровня.

На рис. 9.6 показаны эталонные соединения. Подписи под рисунком поясняют различные варианты соединений.

 

Рекомендация Х.96: Сигналы прохождения вызова в сетях данных общего пользования.

 

Этим стандартом устанавливаются сигналы, которые могут быть использованы для информирования ООД(например, вызывающих ООД) о прохождении вызова соединения или запроса соединения через сеть общего пользования.

Х.96 определяет сигналы, возвращающиеся к вызывающему ООД и указывающие, что соединение не может быть выполнено (а также причину этого), или условия прохождения вызова через сеть.

Для вызывающего ООД часто важна такая информация, как:

а) существуют какие-либо проблемы на уровне интерфейса ООД/АКД;

б) является ли виртуальный вызов отложенным или это невозможно;

в) приведен ли постоянный виртуальный канал в исходное положение и др.

На рис 9.7. указаны сигналы обработки вызова.

 

Рекомендация Х.121: Международный план нумерации для сетей данных общего пользования.

 

В рекомендации предлагается универсальная схема адресации, позволяющая пользователям связываться через многочисленные сети с любым другим абонентом.

Х.121 устанавливает стандартную схему нумерации для сетей во всех странах, а также для каждого отдельного пользователя внутри этих сетей.

Каждому ООДв сети данных общего пользования присваивается международный сетевой адрес.

Международный сетевой адрес состоит из кода идентификации сети данных (DNIC) и сетевого номера (NTN).

Другой вариант международного номера включает код страны (DCC) и национальный номер (NN).

Эти четыре кода состоят из следующих идентификаторов: DNICсостоит из четырех цифр – первые три цифры обозначают страну и могут рассматриваться как код страны (DCC).

Четвертая цифра обозначает конкретную сеть данных внутри страны.

Сетевой оконечный номер может состоять из 10 цифр или, вместо NTNиспользуется национальный номер NN, - из 11 цифр.

На рис. 9.8 показаны возможные конфигурации в соответствии с Х.21.

 

Рекомендация Х.213: Определение услуг сетевого уровня модели взаимосвязи открытых систем для приложений МККТТ.

 

Стандарт используется стандартами высших уровней в модели ВОС.

Определяет перечень услуг предоставляемых сетевым уровнем транспортному.

Рекомендация определяет сетевые услуги в терминах примитивных действий и событий, происходящих между уровнями, а также параметры, связанные с каждым действием, и последовательность событий.

Тема 6.2. Характеристики Х.25.

 

Стандарт Х.25 действует на основе предпосылки обслуживания виртуальных цепей.

Виртуальная цепь (также называемая в терминах Х.25 логическим каналом) является цепью, относительно которой пользователь считает, что эта цепь существует и физически подключена к компьютеру, хотя в действительности «выделенная» цепь распределена для многих пользователей.

 

С помощью методов мультиплексирования пакеты различных пользователей перекрываются в одном и том же физическом канале.

В идеальном случае пропускная способность канала считается хорошей при гарантии того, что любой из пользователей не заметит ухудшения обслуживания при прохождении через канал других пользователей.

В Х.25 используются номера логических каналов (НЛК) для идентификации подключений ООД в сеть. Одному физическому каналу можно назначить до 4095 логических каналов и пользователей сети.

 

Канальные режимы.

 

Стандарт обеспечивает четыре механизма для создания и поддержания коммуникаций:

- постоянная виртуальная цепь (ПВЦ);

- виртуальный вызов (ВВ);

- вызов с быстрым выбором;

- вызов с быстрым выбором и немедленной очисткой.

 

Постоянная виртуальная цепь (ПВЦ).

Постоянная виртуальная цепь аналогична арендованной линии в телефонной сети – передающему ООД гарантировано соединение с принимающим ООД в пакетной сети (рис. 9.9,а).

Стандарт Х.25 требует создания виртуальной цепи до начала сессии.

После создания виртуального соединения, при посылке передающим ООД пакета в сеть в пакете будет содержаться идентифицирующая информация, которая указывает, что запрашивающий ООД имеет постоянное виртуальное соединение с принимающим ООД.

Сетью и принимающим ООД устанавливается соединение без какого-либо арбитража и соглашение о сессии.

ПВЦ не требует процедур установки вызова или очистки, а логический канал постоянно находится в состоянии передачи данных.

 

Виртуальный вызов.

Виртуальный вызов напоминает процедуры, связанных с телефонными линиями, по которым осуществляется набор номера.

Процесс показан на рис. 9.9,б. Исходный ООД посылает пакет запроса на вызов в сеть, имея номер логического канала 11(НЛК). Сеть направляет пакет запроса на вызов как входящий пакет вызова из узла сети с НЛК, равным 16.

Логическая нумерация каналов выполнена в каждом конце сети. Главным требованием является то, чтобы специфические сессии между ООД всякий раз идентифицировались НЛК 11 и НЛК 16.

Норма логических каналов специфически идентифицируют сеансы разных пользователей для каждой физической цепи на каждом конце сети.

В самой сети промежуточные узлы коммутации пакетов также могут выполнять их собственную нумерацию НЛК.

Когда принимающее ООД опознало и приняло запрос на вызов, оно посылает в сеть пакет приема вызова.

Сеть передает этот пакет затребовавшему ООД в форме пакета соединения вызова.

Канал переходит в состояние передачи данных после того, как связь установлена.

Для завершения сеанса любой из ООД посылает запрос на очистку. Он воспринимается как указатель очистки и подтверждения пакетом подтверждения очистки.

 

Обобщение процедуры установки состояния следующее:

Пакет	НЛК выбран посредством
Запрос на вызов Входящий вызов Прием вызова Вызов установки	Исходного ООД Узлом сети по назначению АКД Того же НЛК, что у входящего вызова Того же НЛК, что у запроса на вызов

 

Все сказанное здесь напоминает сети, ориентируемые на соединение.В сетях ориентируемых на соединения, требуется, чтобы установка соединения предшествовала обмену данными.

Как только принимающее (вызывающее) ООД принимает запрос на вызов, устанавливается обмен данными с соответствии со стандартом Х.25.

 

Быстрый вызов.

Быстрый выбор обеспечивается для двух режимов.

ООД может затребовать это средство во время вызова к узлу сети (ОКД), указывая соответствующий запрос в головой метке пакета.

Пакет запроса вызова (входящего вызова) определяет, должно ли удаленное ООД отвечать запросом на очистку или же приемом вызова.

Первый режим - прием вызова показан на рис. 9.9,в.

Быстрый вызов с немедленной очисткой показан на рис. 9.9,г.

Пакет запроса вызова содержит данные пользователя.

Этот пакет пересылается через сеть к принимающему ООД, который после приема пакета посылает запрос на очистку или прием вызова, также содержащие данные пользователя.

Запрос на очистку принимается в исходном узле как пакет индикации очистки.

Пакет подтверждения очистки не содержит данных пользователя.

Идея быстрого выбора заключается в обеспечении работы для пользовательских приложений, в которых выполняются одна-две транзакции, например запрос-ответ.

В таких прикладных областях невозможно эффективно использовать переключаемый виртуальный вызов из-за накладных расходов и задержек, требуемых при установке и снятии сеанса. В этих прикладных областях невозможно эффективно использовать и постоянную виртуальную цепь, поскольку ее случайное использование не гарантирует постоянного выделения ресурсов в рабочих узлах.

 

Тема 6.3. Принципы управления потоком.

 

Стандарт Х.25 позволяет устройству пользователя ООД ограничивать степень восприятия пакетов. Это свойство полезно в предотвращении чрезмерного потока на входе в любую принимающую станцию.

Управление потоком организуется раздельно для каждого направления, оно основано на санкциях самих станций.

 

Тема 6.4. Типы пакетов.

 

Помимо пакетов, описанных ранее в данном разделе (см. тему 9.1 «Уровни стандарта Х.25», Х.25 и уровень передачи данных, рис. 9.4), в Х.25 рекомендовано использование нескольких других типов пакетов (рис. 9.10).

 

Процедура прерывания позволяет ООД послать один пакет вне последовательности к другому ООД помимо нормальной процедуры управления потоком, которая установлена в Х.25.

Высокоприоритетное сообщение может быть передано как пакет прерывания для обеспечения приема данных принимающим ООД.

Данные пользователя (32 байт) допустимы в составе пакета прерывания.

Применение прерываний не влияет на регулярные пакеты данных в режиме виртуального вызова или постоянной виртуальной цепи.

Как показано на рис. 9.10, пакет прерывания требует подтверждения прерывания до того, как другой пакет прерывания может быть послан по логическому каналу.

 

Готовность к неприему (ГПР) и Нет готовности к приему (НГПР).

Выполняют функцию управления потоком со стороны устройства пользователя. Оба пакета обеспечивают последовательный номер принимающий стороны, чтобы указать последовательный номер следующего пакета, который ожидается от передающего ООД.

Пакет ГПР сообщает передающему ООД/АКД о посылке пакетов, если нет пакетов данных, которые нужно переправить обратно к передающей стороне.

Пакет НГПР запрашивает передающую станцию прекратить посылку пакетов, и он также использует поле последовательности посылки для опознавания любого ранее отосланного пакета.

Часть НГПР используется, если станция временно не может принимать поток.

Узлы сети, содержат ограниченные возможности буферизации и емкости очередей. Следовательно, НГПР требует «сдерживания» обеих сторон в сеансе ООД/АКД.

Два типа пакетов обеспечивают Х.25 добавочным видом управления потоком данных LAPB, и поэтому управление потоками и окна обеспечиваются и на уровне связи данных LAPB, и на сетевом уровне Х.25.

Уровень связи данных не обеспечивает эффективного управления потоками для отдельных пользовательских устройств (DTE).

На сетевом уровне Х.25, используя ГПР и НГПР для номеров отдельных логических каналов, обеспечивается индивидуальное управление потоками.

 

Пакет неприема (НПГ) отвергает принятые пакеты. В случае если этот пакет используется, станция требует повторной передачи пакетов, начиная с номера, указанного в поле последовательного номера приема.

 

Пакеты сброса повторно инициализируют коммутируемый виртуальный вызов или постоянную виртуальную цепь.

Процедура сброс удаляет все пакеты данных прерываний, которые оказались в сети между двумя станциями (для сеанса в одном логическом канале).

Процедура необходима, если возникают проблемы, такие, как потеря пакетов, дублирование пакетов, или же нарушена последовательность пакетов.

Сброс применяется только в состоянии передачи данных. Он может задаваться ООД (запрос сброса) или же сетью (индикация сброса).

 

Процедура рестарта инициализирует впервые или повторно интерфейс ООД/АКД пакетного уровня.

На физический порт может быть подсоединено до 4095 логических каналов. Процедура снимает все виртуальные вызовы и сбрасывает все постоянные виртуальные цепи на уровне интерфейса.

Рестарт может произойти в результате серьезной проблемы, такой, как поломка всей сети (например, выход из строя управляющего центра сети). Все неразрешенные пакеты теряются и могут быть восстановлены протоколом более высокого уровня.

Иногда сеть использует рестарт для повторной инициализации и запуска системы с целью гарантировать новую организацию всех сеансов.

Когда ООД выдает рестарт, сеть направляет рестарт всем ООД которые имеют сеансы виртуальной цепи с выдавшим ООД.

Пакеты рестарта также могут содержать коды, указывающие на причину рестарта.

 

Пакеты данных пользователя могут затеряться в сети.

Пакеты очистки, сброса и рестарта очищают сеть от недопоставленных по назначению пакетов, поскольку они прибывают в узел назначения прежде любых пакетов с данными пользователей.

Пакеты управления не подвергаются задержкам, которые присущи процедурам управления потоками, применяемым к пакетам данных пользователя. Требуются протоколы более высокого уровня, чтобы учесть потерю этих пакетов.

 

Пакет очистки используется в выполнении многих функций Х.25, однако в первую очередь – для очистки сеанса ООД-ООД.

Следующим из использований заключается в индикации того, что запрос на вызов не может быть выполнен. Если отдаленное ООД отвергает вызов, он выдает запрос очистки к своему сетевому узлу.

Пакет пересылается по сети к исходному узлу сети, а исходное ООД получает указание очистки (см. рис. 9.11,а).

Если сеть не может выполнять вызов, она отсылает указание очистки исходному ООД (рис. 9.11,б). Четвертый байт пакета содержит битовый код, указывающий причину очистки.

Стандарт Х.25 обеспечивает различные коды для указания причин пакета очистки.

 

Диагностический пакет используется сетью Х.25 для указания условий, которые не устраняются другими методами, такими, как повторная установка или рестарт.

Диагностический пакет с НЛК=0 используется только однажды (и только сетевым АКД) для конкретной проблемы: для этого пакета не требуется подтверждения.

 

Стандарт Х.25 определяет 66 диагностических кодов для помощи при выявлении проблем сети или ООД. Эти же коды могут быть использованы пакетами очистки, переустановки и рестарта.

Примеры диагностических кодов Х.25:

- неидентифицированный пакет;

- пакет слишком велик или слишком короток;

- подтверждение несанкционированного прерывания;

- исчерпан лимит времени;

- неверно задан адрес;

- нет допустимого логического канала;

- средство не обеспечено;

- неизвестен международный адрес;

- проблема в удаленной сети;

- постоянная проблема маршрутизации сети.

 

Пакеты регистрации используются для вызова или подтверждения возможностей Х.25. Это позволяет конечному пользователю требовать изменений в возможностях в рабочем режиме сети без ручного вмешательства или отказа от решения запроса производителем сети.

 

Тема 6.5. Состояния логического канала.

 

Состояния логического канала обеспечивают основание для организации соединений ООД/АКД.

При использовании различных типов пакетов логический канал может принимать состояния указанные на рис. 9.12.

 

На рис. 9.13 приведен пример организации вызова для разъяснения того, как используются состояния канала (установка вызова см. рис. 9.9,б).

 

Тема 6.6. Время простоя и временные ограничения.

 

Большинство коммуникационных протоколов имеют таймеры, и Х.25 не является исключением.

 

Таймеры используются для установки ограничений на длительность соединений, очистки каналов, рестарта сети и т.д.

 

Без таймеров пользователь может ждать бесконечно некоторого события, если оно невыполнимо.

Таймеры усиливают возможности Х.25 при решениях проблематичных ситуаций, они способствуют восстановлению при ошибках.

Х.25 обеспечивает временные пределы для ООД и времена простоя (timeouts) для АКД.

Эти таймеры описаны на рис. 9.14 и рис. 9.15, а также в нем определены ситуации, возникающие при превышении пределов времени.

Во всех случаях, если проблема не разрешается, а таймеры снова запускаются с нуля, канал рассматривается как вышедший из строя, от сети следует выполнение мер по устранению возникших неполадок.

 

Тема 6.7. Форматы пакетов.

 

Длина поля данных пользователя в пакете по умолчанию равна 128 байт (восьмеричных), но стандарт Х.25 обеспечивает возможности других длин. Доступны также другие значения: 16, 32, 64, 512, 1024, 2048, 4096 байт. Последние два значения были добавлены в издании 1984 г.

 

Если длина поля пользовательских данных в пакете превышает максимально допустимую длину данных в сети, приемное ООД сбросит виртуальный вызов, выдав пакет сброса.

 

Каждый пакет, пересекающий интерфейс ООЖ/АКД, при входе в сеть должен содержать по меньшей мере 3 байта. Эти байты содержат головную метку пакета. Другие байты также могут быть использованы для уточнения головной метки. Головная метка для пакетов с данными и без данных показана на рис. 9.16 и рис 9.17.

 

Первые 4 бит первого байта головной метки содержат номер логического канала.

Последние 4 бит первого байта содержат идентификатор общего формата.

Биты 5 и 6 идентификатора (SS) используются для указания следования пакетов в сеансе.

В Х.25 допускаются два вида следования. Первый по модулю 8, который обеспечивает номера следований 0-7. Также доступен второй вид – по модулю 128, в котором допустимы номера следования 0-127 (будет обсужден позднее в управлении потоком и окном).

Седьмой бит, или бит D, идентификатор общего формата используется только с некоторыми пакетами (бит D будет обсужден позднее).

Восьмой бит, или бит Q, используется только для пакетов данных конечного пользователя. Он дает уточнение уровня (одного или двух) данных пользователя в сети (разъяснения позже, одновременно с Х.29).

 

Второй байт головной метки пакета содержит номер логического канала (НЛК). Это 8-битное поле совместно с номером группы логических каналов обеспечивает полную идентификацию логического канала из 12 бит, что предоставляет возможность 4095 логических каналов (2 без канала с номером 0). НЛК с номером 0 резервирован для управления (пакеты рестарта и диагностики).

Номера логических каналов (рис 9.18) используются для идентификации ООД пакету от узла АКД и наоборот.

Номера назначены:

а) постоянным виртуальным цепям;

б) односторонним входящим вызовам;

в) двусторонним вызовам;

г) односторонним выходящим вызовам.

Термин «односторонний» относится к обозначению направления, в котором выполняется установка вызова.

Возможно использование ООД и АКД одного и того же НЛК при начале процесса связи. Например, ООД в запросе вызова использует тот же НЛК, что и АКД в соединении вызова. Чтобы избежать случайности, сеть (АКД) начинает нумерацию с больших номеров.

Если выходящий вызов (запрос вызова) от ООД имеет тот же НЛК, что и входящий вызов (соединение вызова) от сетевых АКД, то входящий вызов должен быть очищен, а запрос на вызов – обработан.

 

Третий байт головной метки является байтом идентификации типа пакета для пакетов, не являющихся данными, и байтом последовательности для пакетов-данных. Это поле идентифицирует специфические типы пакетов, не являющиеся данными, которые показаны на рис. 9.10.

 

Рисунок 9.16,в иллюстрирует дополнительные поля в пакете Х.25.

Для пакетов организации вызова включаются адреса ООД и длина адреса.

Соглашение об адресации основано на стандарте Х.121. Поля адресов могут находится в любом от четвертого до девятнадцатого байта (наибольшая длина) пакета запроса на вызов.

Сеть использует связанные номера логических каналов для идентификации сеансов ООД-ООД.

 

 

Данные по запросу пользователя могут находиться в пакете запроса вызова и составляют 16 байт. Это поле полезно для входных данных, таких как пароли, учетная информация для принимающих ООД. Оно также используется для протокола Х.29. для некоторых режимов, таких, как быстрый выбор. Допустимы до 128 байт данных пользователя.

Головная метка пакета модифицируется для обеспечения движения данных через сеть. Третий байт метки, рис. 9.16,а, резервируемый для идентификатора типа пакета, разделен на четыре отдельных поля.

Биты	Описание или значение
2-4     6-8	Последовательность отсылки пакета [P(S)]   Бит наличия данных [М бит]   Последовательность приема пакета [P(R)]

Эти поля имеют следующие функции.

 

Первый бит, имеющий значение 0, идентифицируется как пакет данных.

Три бита предоставлены номеру последовательности отсылки пакета.

Один бит отведен функции М (об этом подробнее ниже).

Три оставшихся бита предоставлены номеру последовательности приема пакета.

 

Большинство производителей сетей и большая часть документов описывают формат пакета так, как показано на рис. 9.17. Сущность пакета остается той же самой, разница в том, что байты расположены по принципу «бутерброда», а не последовательно, как на рис. 9.16.

 

Номера посылки и номера приема используются для координации и опознавания передач между ООД и АКД.

По мере передвижения пакета сквозь сеть от узла к узлу последовательные номера изменяются в моменты перехода через эти узлы.

Как показано на рис. 9.16, принимающие ООД или АКД должны знать, какой номер последовательности приема пакета необходимо послать обратно передающему устройству для правильного опознавания конкретного пакета.

Эти возможности Х.25 подобны возможностям второго уровня ВОС, а именно управления связью данных.

Использование P(R) и P(S) на сетевом уровне требует, чтобы P(R) было на единицу больше, чем P(S) в пакете данных. Заметим, что как LAPB, так и Х.25 обеспечивают независимые нумерации последовательностей (R) (S).

 

Бит D.

Средство бита D используется для:

1. Когда бит установлен в 0, то значение P(R) указывает, как опознан прием пакета данных сетью.

2. Когда бит установлен в 1, то поле P(R) используется для сквозного опознавания пакета, т.е. от одного ООД и до другого ООД.

Функции бита D для опознавания пакета сетью или оконечным ООД показаны на рис. 9.19. При использовании режима с битом D, равным 1, Х.25 предполагает наличие одной из функций транспортного уровня: сквозной учет.

 

Бит М.

Бит М идентифицирует связанную последовательность пакетов, передаваемых через сеть. Это средство помогает сети и ООД в сохранении корректной идентификации блоков данных, если сеть разделяет эти блоки на более короткие пакеты.

Например, блок данных, имеющих отношение к базе данных, необходимо передать на некоторый ООД. Это средство крайне важно, когда сети взаимодействуют друг с другом (предмет, обсуждаемый далее).

 

Пакеты А и В.

 

Комбинации пакетов M и D обеспечивают две категории пакетов в сетях Х.25. Эти категории обозначаются А и В.

Средство позволяет ООД и АКД указывать последовательность не более чем одного пакета (рис. 9.20), а также позволяет сети комбинировать пакеты. Х.25 определяет полную последовательность пакетов, как единичный пакет категории В, а все предшествующие или последующие пакеты – категории А.

Пакет категории В завершает связанную последовательность пакетов.

Пакеты категории А представляют вновь входящие пакеты, они заполнены с М-1 и D-0.

Только пакеты В могут иметь бит D, равный 1, для опознавания сквозной (end-to-end) связи.

Пакеты категории А и непосредственно следующий пакет В скомбинированы сетью в один пакет.

Пакеты В сами по себе содержат отдельные пакеты как отдельные сущности.

Комбинированные пакеты полезны, когда пакеты различны по размерам и проходят по одному маршруту, или же при взаимодействии различных сетей, когда подсети используют пакеты разных размеров.

Этот механизм позволяет пересылать пакеты как логическое целое. Именно в таких случаях бит М используется для указания принимающему ООД, что поток пакетов представляет связанную последовательность.

На рис. 9.21 показано, как Х.25 трактует биты М и D, посланные исходным ООД.

Целью битов М и D является комбинирование пакетов. Например, если поле данных принимающего ООД длиннее, чем поле передающего, то пакеты, составляющие полную последовательность, можно скомбинировать средством сети.

Обсудим поток пакетов с рис. 9.20. Пакеты 1, 2, 3 и 4 связаны: установка бита D в пакетах 1, 2 и 3 указывает, что они являются пакетами А. Пакет 4 относится к категории В, он завершает последовательность пакетов и тем самым позволяет сделать комбинацию из этих пакетов.

Пакеты 5, 6, и 7 принадлежат к другой последовательности, и пакет 7 (категории В) использует бит М, установленный в 0, для идентификации полной последовательности пакетов.

 

Бит Q.

 

Этот бит является опциональным и используется для различения данных пользователя и управляющей информации. Поскольку Х.25, использующий бит Q, является одним из стандартов СРП, обсуждение этого бита будет отложено до рассмотрения стандартов СРП.

 

Тема 6.8. Управление потоком и окна.

Стандарт Х.25 использует методы управления потоками и концепцию окон, которые в точности подобны методам и концепциям HDLC, LAPB и другим линейным протоколам.

Пакет данных совмещает два номера последовательности (посылки и приема) для координации потока пакетов между ООД и АКД (рис. 9.16).

Схема расширенной нумерации позволяет в поле номера последовательности наибольший номер, равный 127.

В интерфейсе ООД/АКД пакеты данных находятся под реальным управлением для каждого направления, основываясь на санкциях пользователя в форме номеров последовательности приема или же управляющими пакетами «готовность к приему» (ГПР) и «нет готовности к приему» (НГПР).

 

Поскольку стандарт Х.25 объединяет многих пользователей в один физический канал, выдача пакетов НГПР на уровне звена данных регулирует потоки для всех логических каналов, соединенных в цепь.

Управление потоками в сетях Х.25 допускает более избирательную регулировку. Более того, введение нумераций последовательностей в сетевых интерфейсах добавляет еще один уровень учета и секретности пользовательских данных.

 

Нумерация пакетов на третьем уровне проходит таким же образом, как это делается в стандартах второго уровня HDLC/LAPB. Номер последовательности пакета изменяется циклически в диапазоне от 0 до 7. Если используется схема по модулю 128, то номер изменяется циклически в диапазоне от 0 до 127.

Поток данных на рис. 9.19, организованный с учетом бита D, показывает, как номера посылающей и принимающей последовательностей координируются между собой.

Стандарт Х.25 использует окна, образованные схемой вычисления по модулю, для предотвращения переполнений пакетов.

Хотя в стандарте рекомендован стандартный размер окна 2 для каждого из направлений потока, сетям доступны другие размеры окон.

Значение 2 ограничивает движение пакетов, которые не выполнены когда-либо ранее. Это ограничение обязывает принимающее ООД/АКД быстрее опознавать пакеты.

Ограниченный размер окон также ограничивает количество пакетов, которые не получили разрешения в сети для любого момента времени.

 

Тема 6.9. Средства сетей Х.25.

 

Средства сетей Х.25 обеспечивают некоторые функции для оконечных пользователей, а некоторые рассматриваются как «существенные» для сетей.

Средства задаются с помощью специальных элементов в пакете запроса вызова.

Средства классифицированы следующим образом:

1. Международные средства (Рекомендация Х.2).

2. Средства ООД, определенные МККТТ.

3. Средства, представленные ранними сетями данных общего пользования.

4. Средства, представленные целевыми сетями данных общего пользования.

 

Регистрация средств.

Позволяет ООД в любой момент потребовать средство или получить параметры (значения) средств, как они восприняты АКД.

Диалог ООД/АКД выполняется посредством пакетов регистрации (рис. 9.10), и пакеты указывают на то, можно ли согласится со значениями этих параметров.

 

Расширенная нумерация средств.

Это средство обеспечивает нумерацию последовательностей по модулю 8 (т.е. номера 1-7).

 

Модификация D–бита.

Это средство, предназначенное для ООД, было разработано прежде, чем была введена в 1980 г. процедура с D–битом. Средство позволяет ООД осуществлять сквозное (end-to-end) опознавание пакетов.

 

Повторная передача пакетов.

ООД требует повторной передачи одного или нескольких пакетов данных от АКД, ООД определяет номер логического канала и значение в отвергнутом пакете.

Затем АКД снова посылает все пакеты, начиная с P(R) до того пакета, который должен быть послан в момент обнаружения.

Это средство подобно методу Go-Back-N, который использован линейными протоколами на втором уровне модели ВОС.

 

Исключение входящих пакетов. Исключение выходящих пакетов.

Эти два средства предотвращают доступ входящих пакетов в ООД и выходящих пакетов из АКД.

 

Одновременный выход логического канала. Одновременный вход логического канала.

Эти средства ограничивают канал только к передаче исходных вызовов или только к передаче приемных вызовов. Средства подобны предыдущим двум средствам, с тем отличием, что они применимы к отдельным каналам.

 

Нестандартные размеры пакетов по умолчанию.

Средство предназначено для выбора размеров пакетов по умолчанию. Могут использоваться пакеты регистрации для согласования размеров пакетов.

 

Нестандартные размеры окон по умолчанию.

Средство позволяет расширять размеры окон (P(R), P(S)) вне умалчиваемого размера 2 для всех вызовов.

 

Назначение классов пропускной способности по умолчанию.

Средство предназначено для выбора одного из следующих уровней пропускной способности (бит/с): 75, 150, 300, 1200, 2400, 4800, 9600, 19200, 48000. Другие значения должны согласовываться.

 

Соглашения о параметрах управления потоком.

Средство позволяет, чтобы размеры окна (P(R), P(S)) согласовывались на основе вызова. ООД предполагает размеры окна и пакета во время установления вызова. Некоторые сети требуют, чтобы эти параметры были одинаковы для обоих ООД.

 

Соглашения о классе пропускной способности.

Средство позволяет согласовывать пропускную способность на основе вызова.

 

Закрытие группы пользователей (ЗГП).

Набор средств позволяет пользователям образовать группу ООД, из которой доступ ограничен.

Средство ЗГП обеспечивает меру секретности/безопасности в сетях общего назначения.

Средство имеет несколько режимов, таких, как доступ только на вход или только на выход из группы.

Вызывающая станция определяет требуемую закрытую группу пользователей в специально выделенных полях пакета запроса на вызов.

Если вызываемая станция не является членом группы, вызов отвергается сетью.

 

Двусторонние замкнутые группы пользователей.

Это средство подобно средству ЗПГ, однако позволяет вводить ограничение доступа между парами замкнутых групп ООД.

 

Быстрый выбор. Прием быстрого выбора.

Эти два средства были обсуждены ранее.

 

Обращение издержек. Прием обращенных издержек.

Средства позволяют вменить в долг принимающему ООД все издержки пакетной сети. Средство может использоваться с виртуальными вызовами и быстрой выборкой. Это средство подобно оплате за счет вызываемого абонента на телефонной сети.

 

Предотвращение локальных издержек.

Средство разрешает АКД предотвратить установление вызовов, за которые подключаемое ООД вынуждено платить. Например, ООД может не воспринимать обратных издержек на свой счет от всех вызывающих ООД.

 

Идентификация пользовательской сети.

Средство позволяет передающему ООД предоставить АКД:

- информацию о затратах на связь,

- секретную и организационную информацию по вызову.

Если идентификация неверна, вызов отменяется.

 

Информация о затратах.

Средство позволяет АКД предоставить ООД информацию о пакетном сеансе, что касается затрат.

 

Группа отслеживания.

Средство распределяет входящие вызовы по требуемым группировкам интерфейсов ООД/АКД.

Это дает пользователям способность выбора множества портов на фронтальном процессоре или компьютере или же выбора различных фронтальных процессоров или компьютеров на станции пользователя.

Это средство очень ценно для организаций с большими вычислительными мощностями, которые требуют гибкости в управлении заданными, различными ресурсами.

Концептуально это подобно механизму выбора портов, который обслуживается в большинстве систем.

 

Перенаправление вызова.

Это средство, которое перенаправляет пакеты в случаях, когда целевое ООД вышло из строя, занято или само затребовало перенаправления вызова.

Оно позволяет перенаправить вызов дублирующему ООД, которое может обеспечивать важную функцию решения проблем и устранения неполадок изолированно от конечного пользователя.

 

Модифицированное указание адресов вызываемых линий.

В случаях, когда вызов перенаправлен, это средство информирует вызывающее ООД причину, почему адрес вызова в пакетах соединения вызова или указания очистки отличается от адреса в пакете на вызов, посланном вызывающим ООД.

 

Указание перенаправления вызова.

В случаях когда вызов перенаправлен, средство информирует об этом событии альтернативный ООД, а также сообщает ему причину перенаправления и адрес первоначально вызванного ООД.

 

Указание и выборка времени транзитной задержки.

Последнее средство позволяет ООД выбрать время транзитной задержки при проходе пакета через сеть. Средство весьма ценно для конечного пользователя тем, что предоставляет некоторые возможности управления временем реакции сети.

 

Все рассмотренные средства могут быть приведены в действие с помощью специальных полей в управляющих пакетах сетей Х.25. Рис. 9.16,в обеспечивает общий вид соотношений между этими полями в пакетах Х.25.

 

Тема 6.10. Стандарт сборки/разборки пакетов (СРП).

Поскольку Рекомендации Х.25 начали разрабатываться в 70-х годах, группы по стандартизации признавали, что большинство терминалов в работе являлись неинтеллектуальными, простыми асинхронными устройствами.

Был необходим интерфейс для подключения этих терминалов в пакетные сети.

Как следствие, были разработаны стандарты для преобразования протоколов и функций сборки/разборки пакетов (СРП) (packet assembly/disassembly) для асинхронных терминалов.

Общие преобразования протоколов поясняются на рис. 9.22.

После издания исходного проекта стандарта Х.25, последовало издание Рекомендаций по трем спецификациям, обеспечивающим работу Х.25 с асинхронными интерфейсами терминалов: Х.3, Х.28 и Х.29.

Целями СРП являются преобразования протоколов для устройств пользователей (ООД) при выходе в общие или частные сети и обратные преобразования на приемных окончаниях сетей.

 

Задачей является предоставить пользователю полную прозрачность обслуживания ООД.

 

Стандарты СРП предназначены для нескольких конфигураций.

На рис. 9.22,а показано соединение пакетного и непакетных ООД.

РСП Х.3 и Х.28 нужны только для асинхронных ООД. Рис. 9.22,б иллюстрирует другой общий пример, на котором два асинхронных ООД взаимодействуют между собой. Оба ООД используют Х.3 и Х.28.

Пример на рис. 9.22,в иллюстрирует СРП, расположенный вне сети. В этом случае СРП проявляется в сети как реальное устройство, соответствующее Х.25. Следует также заметить, что стандарт Х.25 используется для поддержки связи между СРП и ООД под Х.25 или же между двумя СРП.

Х.3. Версия Х.3 издания 1984 г. обеспечивает набор из 22 параметров, которые СРП использует для идентификации и обслуживании каждого терминала, который взаимодействует с СРП.

 

При организации соединения СРП с ООД параметры СРП используются для того, чтобы определить, как именно выполняется это соединение.

Пользователь имеет возможность изменять параметры после подключения к СРП.

Каждый из 22 параметров состоит из ссылочного номера и значения параметра. Эти параметры и их ссылки поясняются на рис. 9.23.

Интерпретация параметров не проста. Здесь представлено несколько примеров для того, чтобы пояснить, как можно использовать параметры СРП.

Параметр 3=0 Указание СРП к посылке только полных пакетов.

Параметр 3=2 Указание СРП к высылке пакета после того, как с терминала будет введен символ возврата каретки.

Параметр 6=1 Пользователь желает принять сигнал от сервисных средств СРП; весьма полезно при устранении неполадок.

Параметр 7=1 После приема символа прерывания с терминала СРП отправляет пакет прерывания принимающему ООД.

Х.28. Стандарт определяет процедуры для управления потоком данных между СРП и терминалом пользователя, который не ориентирован на пакетный режим.

 

После приема начального соединения от пользовательского ООД СРП организует соединение и обеспечивает обслуживание согласно стандарта Х.28.

Как показано на рис. 9.24, пользовательское ООД вызывает команды Х.28 к СРП, который запрашивает виртуальный вызов Х.25 к удаленному ООД. Далее СРП отвечает за передачу соответствующего пакета запроса на вызов в стандарте Х.25.

На рисунке сведены процедуры для:

- организации маршрута;

- инициализации средств обслуживания;

- обмена данными;

- обмена управляющей информацией.

 

Х.28 требует, чтобы СРП дал ответ, когда с терминала направляется команда (эти сигналы приведены на рис. 9.25).

Он также описывает два профиля, которые определяют виды обслуживания для пользовательских ООД.

Прозрачный профиль означает, что обслуживающий СРП прозрачен для обоих ООД, т.е. оба ООД считают, что между ними прямое виртуальное соединение. В этой ситуации удаленное ООД отвечает за некоторые функции СРП, такие, как проверка ошибок. Простой профиль использует полный стандарт Х.3 и функции параметров для выполнения требований ООД пользователя.

Рекомендация Х.3 обеспечивает пользователю гибкость для приспособления добавочных характеристик к конкретному терминалу.

Это выполняется с помощью сигнала команды PROF СПР (см. рис. 9.24). Команда PROF дает производителям пакетных систем дополнительную гибкость в приспособлении СРП к поддерживающим интерфейсам других протоколов, таких, как управление связью данных в BSC и SDLC.

 

Команда Х.28 и описания обслуживания выглядят следующим образом:

SET 3:0, 6:1

Это означает: установить параметры СРП 3 в 0 и 6 в 1.

Х.29. Этот стандарт обеспечивает направление для СРП и удаленной станции с целью обмена информацией управления на основе вызова Х.25.

 

В контексте стандарта Х.25 удаленной станцией считается либо СРП, либо Х.25 ООД.

Х.29 позволяет осуществить обмен информацией в любое время, как в фазе передачи данных, так и в любых других фазах вызова.

Q-бит последовательности управляет некоторыми функциями Х.29.

Q-бит (бит квалификации данных) содержится в головной метке пакета данных. Он используется удаленным ООД для различения пакетов, содержащих данные пользователя (Q=0), и пакетов, содержащих управляющую информацию СРП (Q=1).

Стандарт Х.29 полезен, когда центральному процессору нужно заменить действующие параметры Х.3 на терминале, который взаимодействует с этим процессором.

Посылая управляющий пакет Х.29 на СРП (S=1), центральный процессор может «реконфигурировать» подключенные рабочие станции.

Стандарт Х.29 определяет семь управляющих сообщений, которые являются сообщениями СРП.

Это следующие сообщения:

- установка: изменение значения Х.3;

- чтение: чтение значения Х.3;

- установка и чтение: изменение значения Х.3 и требование к СРП о подтверждении изменения;

- указание параметров: возврат значений в ответ на предыдущие команды;

- приглашение к очистке: позволяет очистку вызова Х.25 удаленным ООД; СРП очищается для локальных станций;

- указание прерывания: СРП указывает на терминал, который передал прерывание;

- ошибка: ответ на неправильное сообщение СРП.

 

Пакет СРП по формату подобен обычному формату пакета Х.25 (рис. 9.26). Обычно требуется 3-байтовая головная метка, за которой следует однобайтовое управляющее поле, а потом номера параметров СРП и их значения.

 

Тема 6.11. Транспортный уровень.

Четвертым уровнем в модели сетей ВОС является транспортный уровень. Он расположен непосредственно на сетевом уровне (рис. 3.7).

Международная организация по стандартизации (ISO) утвердила транспортный уровень 25 июля 1984 года (ISO 8073). МККТТ утвердил Рекомендацию Х.224, которая определяет общее кодирование и ряд процедур транспортного протокола, которые должны использоваться при различном качестве обслуживания.

 

Рекомендация Х.224 определяет:

а) пять классов процедур, ориентированных на соединение, для передачи данных и управляющей информации от одного транспортного объекта к другому равноуровневому транспортному объекту;

б) средства для согласования класса процедур, который должен использоваться транспортными объектами;

в) структуру и кодирование блоков данных транспортного протокола (ТБДП), используемых для передачи данных и управляющей информации.

 

Сетевые службы в зависимости от коэффициента ошибок и в связи с требованиями пользователя классифицируются следующим образом:

Тип А. Служба с приемлемыми коэффициентами необнаруживаемых и обнаруживаемых ошибок.

Тип В. Служба с приемлемым коэффициентом необнаруживаемых ошибок, но неприемлемым коэффициентом обнаруживаемых ошибок.

Тип С. Служба с неприемлемым коэффициентом необнаруживаемых ошибок.

Под обнаруживаемыми понимаются ошибки, сигнализируемые сетевым уровнем в виде сбросов или индикации разъединения.

Под необнаруженными – ошибки типа пропадания, переупорядочения и искажения данных.

Примером сети типа А является надежная сеть Х.25, в которой обеспечивается доставка данных при малом числе сетевых сбросов или разрывов сетевых соединений.

Сеть типа В также обеспечивает приемлемую надежность доставки, однако в ней неприемлемо велико число прерываний в передаче данных, требующих восстановления на более высоком уровне.

Сеть типа С – это фактически сеть дейтаграммного типа, либо локальная сеть без установления соединения, в которой не контролируется доставка данных.

Рекомендация Х.224 предполагает, что каждый транспортный объект осведомлен о качестве обслуживания, предоставляемого конкретными сетевыми соединениями.

 

При условии, что существуют разные виды сетей, транспортный уровень позволяет пользователю установить следующие параметры качества обслуживания (QOS):

- пропускную способность;

- точность;

- надежность;

- сквозную задержку;

- приоритеты;

- защиту;

- мультиплексирование;

- управление потоком;

- обнаружение ошибок;

- сегментирование.

 

Определение служб транспортного уровня использует примитивы для указания, какие именно виды сервиса должны быть обеспечены на транспортном и сетевом уровнях.

Параметры, связанные с каждым примитивным действием (рис. 9.27), обеспечивают специфические функции и события на каждом из уровней.

 

Во время фазы организации связей в сети характеристики соединения согласуются между конечным пользователем и транспортным уровнем.

Соглашение обеспечивается примитивами и параметрами примитивов.

Есть также вероятность, что соединение не будет выполнено, если сеть или конечный пользователь не могут обеспечить или же согласиться с требуемым качеством обслуживания.

 

После того как параметры восприняты двумя договаривающимися сторонами:

- с одной стороны, обеспечивается передача данных из транспортного уровня в физический канал,

- с другой стороны, данные проходят сквозь три нижних уровня в транспортный уровень.

Рис. 9.28 иллюстрирует использование примитивов транспортного уровня для установки и снятия сеанса на транспортном уровне.

 

Транспортный уровень отвечает за выбор соответствующего протокола для обеспечения качества обслуживания (QOS) с параметрами, установленными пользователем.

Так как транспортный уровень осведомлен о характеристиках сети (типа А, В или С), этот уровень может выбрать один из пяти классов процедур протоколов для обеспечения QOS, запрошенного пользователем:

· класс 0 – примитивный класс:

· класс 1 – базовый класс восстановления от ошибок;

· класс 2 – класс мультиплексирования;

· класс 3 – класс восстановления от ошибок;

· класс 4 – класс обнаружения ошибок и восстановления от ошибок.

 

Класс 0, имеющий только функции по установлению соединения и передаче данных, но не обеспечивающий восстановление после сбросов сетевого соединения, целесообразно использовать в сетях типа А.

Этот класс способен обнаруживать ошибки и сигнализировать о них.

Если сетевой уровень сигнализирует об ошибке транспортному уровню, транспортный уровень отсоединяется от сетевого уровня.

Конечный пользователь информируется об отключении.

 

Класс 2 имеет те же восстановительные возможности, что и класс 0, но включает функции мультиплексирования нескольких транспортных соединений в одном сеансе сети Х.25 и передачи срочных данных, вследствие чего в нем появляются функции управления потоком по каждому транспортному соединению в отдельности (в том числе функции нумерации блоков данных).

Класс 2 также используется в сетях типа А.

Он не обеспечивает обнаружения ошибок и восстановления от них.

Управление потоком использует известную концепцию окон.

В элементах запроса на соединение могут быть переданы пользовательские данные.

 

Класс 1 и 3 имеют функции по восстановлению потока данных после сбросов сетевого соединения или его разъединения.

Эти функции включают хранение блоков до подтверждения, повторную их передачу по запросу и прикрепление к новому сетевому соединению.

Различие между классами 1 и 3 заключается лишь в отсутствии мультиплексирования в классе 1.

Оба класса целесообразно использовать в сетях типа В.

 

Для сетей типа С используется класс 4, имеющий развитые функции контроля передачи блоков, не реагирующий на сетевые сбросы и разъединения и не требующий доставки данных по сетевому соединению с сохранением их последовательности.

Класс 4 используется, когда данные в сети могут портиться и теряться.

Он использует несколько сложных механизмов для проверки ошибок, решения проблем последовательных номеров и потерянных пакетов.

Поскольку этот класс сохраняет копию данных до получения подтверждения от приемника, транспортный уровень этого класса может восстанавливаться от сбоев и повреждений в сети.

 

На рис. 9.29 приведены данные о пяти классах процедур транспортного протокола.

 

Тема 6.12. Межсетевые взаимодействия. Х.75.

 

ЕСМА и МОС подразделяют сетевой уровень на три функциональные группы.

 

Наверху находится независимая функция сведения подсетей (SNICF), которая обеспечивает службы связи и маршрутизации для межсетевого взаимодействия.

Этот подуровень содержит протоколы взаимодействий для работы с данными и передач между сетями.

 

Средней группой является зависимая функция сведения подсетей (SNDCF), которую можно использовать для того, чтобы приблизить взаимодействующие сети до нужного уровня.

 

Низший уровень представлен функцией доступа подсети (SNAF), которая содержит служебные средства, подходящие к каждой из взаимодействующих сетей, например к сети Х.25.

 

На наиболее общем уровне межсетевые взаимодействия с помощью функции SNICF осуществляются посредством вентилей или ретрансляцией.

 

Согласно концепции вентилей:

- Управление межсетевыми взаимодействиями и маршрутизация/адресация данных выполняются и используются только конечными пользователями и вентилями.

- Соединяющиеся сети не обеспечивают эти данные; они проходят в прозрачном режиме через сети между оконечными пользователями.

- Сети интерпретируют эту информацию как данные пользователей.

- Вентили не беспокоятся о внутренней маршрутизации или организации в сетях более низкого уровня; эти сети прозрачны для вентилей.

- Вентили принимают решения о маршрутах и обладают необходимой логикой для нахождения необходимых каналов и возможных альтернативных сетей.

 

SNICF на основе ретрансляции более ограничены, чем SNICF на основе вентилей.

В этом протоколе взаимодействующие сети знают адреса управления и маршрутизации и обычно генерируют их.

Сети ответственны за знание глобальных адресов и взаимодействующих сетей.

SNICF на основе ретрансляции воспринимает запросы на маршрутизацию к адресам назначения в других сетях, которые определяются данной подсетью. Ретранслирующая SNICF затем направляет элемент данных в соответствии с указанным полным адресом.

 

Рекомендация Х.75.

Целью стандарта Х.75 являются межсетевые взаимодействия. Он обеспечивает средство передачи для общения одного пользователя с другим пользователем через множество других сетей. Стандарт Х.75 предполагает, что в сетях используются процедуры Х.25.

 

На рис. 9.30 показано, как действуют стандарты Х.25 и Х.75.

Сеть С узнает , что пользователь Х желает общаться с ООД Z в другой сети.

По предыдущему соглашению сеть С устанавливает логический сеанс с пользователем Z в сети В под стандартом Х.25.

Сеть В выполняет соединение между ООД Х и ООД Z, устанавливая сеанс в стандарте Х.25 с пользователем Z.

Х.75 остается прозрачным для команды пользователя; интерфейс СРП или ООД-АКД определен в Х.28 или Х.25 соответственно.

 

Стандарт Х.75 подобен Х.25. Он имеет свойства, описанные ранее в описании Х.25, такие, как коммутируемые виртуальные цепи, группы логических каналов, логические каналы, а также некоторые из управляющих пакетов, описанных на рис. 9.10.

 

Архитектура разделена на уровни:

- физический;

- связи;

- пакетный.

Причем Х.75 размещается над Х.25 в сетевом уровне.

 

Дополнительно Х.75 предполагает использование во взаимодействующих сетях следующих стандартов:

- Х.1: пользовательские классы;

- Х.92: логические связи А1, G1;

- Х.180: административные соглашения для замкнутых международных групп пользователей.

 

Стандарт Х.75 определяет функционирование международных средств на основе коммутации пакетов. Он описывает, как два терминала могут быть соединены логически по международной линии связи, в то время как каждый из них работает в своей сети.

 

Х.75 использует специфический термин для обозначения сетевого интерфейса – сигнальный терминальный обмен.

 

На рис. 9.31 показаны некоторые свойства стандарта Х.75.

 

СТО содержит две главные функции:

- процедуры сигнализации о пакетах;

- процедуры пересылки пакетов.

 

Сигнальные процедуры находятся на физическом уровне модели ВОС.

Подобно Х.25, физический уровень может быть реализован на основе стандарта Х.21 или соответствующих рекомендаций серии V (например, V.24).

Стандарт Х.75 требует, чтобы сигнализация проводилась на скорости 64 Кбит/сек (или, по желанию, на 48 Кбит/сек). Предполагается, что физическая связь представлена связью данных А1 или G1 в соответствии с рекомендациями Х.92.

 

СТО использует тот же формат пакета, который создается подсетью на основе Х.25.

СТО попросту идентифицирует номер логического канала для преобразования диалога СТО-СТО.

Затем СТО направляют поток между взаимосвязанными сетями.

СТО в Х.25 не выполняют заключения головной метки пакета Х.25; метка используется повторно.

Интерфейс СТО-СТО подобен интерфейсам ООД-АКД а Х.25 или ООД-СПР в Х.28: он имеет только местное значение.

Стандарт Х.75 добавляет поле служебных программ сетевого уровня к сеансу СТО/СТО и не использует указание пакета вызова, очистки и приема вызова, поскольку они имеют силу только для интерфейсов ООД-АКД.

 

Второй уровень Х.75 использует подмножество HDLC из LAPB (Х.75 не поддерживает LAP).

СТО использует ответ Неприема кадра (НПРК) для указания трех дополнительных ситуаций вне области обычного LAPB:

1) прием супервизора кадра LAPB с битом F, равным 1;

2) прием неожиданного, ненумерованного подтверждения (НП) или же ответа о фазе разъединения (ФРЗД);

3) прием неправильного поля N(S).

 

Уровни связи стандартов Х.25 и Х.75 также поддерживают многосвязную процедуру (MLP).

Эта процедура предназначена для использования множественных связей между СТО.

MLP устанавливает правила для передач по связям и восстановления последовательностей при посылке или получении данных по множественным связям.

Многосвязные действия позволяют использовать каналы параллельной связи между СТО таким образом, что они проявляются как один канал с большой емкостью.

Многосвязные действия предназначены также для обеспечения большей надежности, чем могут предоставить единичные каналы.

MLP посылает данные через единичную связь через MLP. Если связь вышла из строя или создает избыточные повторные передачи данных, то MLP может поместить поток по другой единичной связи в группе, относящийся к MLP. Они также могут передать множественные копии данных через несколько связей. Принимающее средство MLP снижает избыточные копии.

Многосвязные процедуры существуют на верхней части уровня связи данных (рис. 9.32).

Сетевой уровень Х.25 воспринимает то, что он подсоединен к единичной связи, а единичные связи LAPB действуют, как если бы они были подключены напрямую к сетевому уровню.

MLP отвечает за управление потоками между уровнями 2 и 3, а также за восстановление последовательностей элементов данных для доставки на сетевой уровень.

 

Команды и отклики из Х.75, ориентированные на HDLC, описаны в рис. 9.33.