Сети и телекоммуникации

431

тановления соединения. Он включается в сообщения «Установка параметров»,

передаваемых в обоих направлениях («ООД абонента - АКД сети», «АКД сети -

ООД абонента»). На рис. 30.14 представлен формат этого элемента.

В информационный элемент входят (рис. 30.14):

тип номера, который указывает тип нумерации (международная — «001», национальная — «010», абонентская — «100», специальная — «011» и сокращенная — «110»);

идентификатор системы нумерации (ISDN/E.164 — «0001», Х.121 — «0011», «Телекс»/F.69 — «0100» и частная — «1001»);

значение номера кодируется IA5 (Международный алфавит №5 — International Alphabet 5) символами.

Рис. 2.14. Формат информационного элемента «Адрес вызываемой стороны»

«Субадрес вызываемой стороны». Этот информационный элемент включается в сообщение «Установка параметров» в направлении «ООД абонента -

АКД сети» только тогда, когда пользователь хочет вызвать абонента, имеющего субадрес, а в направлении «АКД сети - ООД абонента» этот элемент включается вызывающим абонентом. Формат элемента аналогичен формату информационного элемента «Субадрес вызывающей стороны» (рис. 30.13), за исключением идентификатора — «01110001».

«Совместимость нижнего уровня». Этот информационный элемент включается в сообщение «Установка параметров» в направлении «ООД абонента - АКД сети» только тогда, когда пользователь хочет передать информацию о совместимости нижнего уровня вызываемому абоненту, а в направлении

433

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

кодировано как «01» (наличие адреса), это означает, что имеют место протоколы канального уровня Х.25, Х.75 и HDLC, если – «10» (кадр ло-

гического управления), то имеет место IEEE 802.2/ISO 8802.2;

информация ООД пользователя о протоколе 3-го уровня. Это поле со-

держит служебную информацию о протоколе 3-го уровня, которая пере-

дается внутри FR кадра. Кодирование поля включает: Х.25, Х.223, ISO 8208 и ISO 8473;

необязательная информация о протоколе 3-го уровня. Это дополнитель-

ное поле предназначено специально для ООД абонента и служит для об-

мена специфической информацией между пользователями. Кодирование поля включает: Х.25, Х.223, ISO 8208, ISO 8473 и ISO Т.70.

Рис. 30.16. Информационные элементы, входящие в сообщение «Подтверждение вызова»

б) Фаза установления соединения (подтверждение вызова и соединения)

В ответ на сообщение «Установка параметров» сеть ответит сообщени-

ем «Подтверждение вызова», в котором подтвердит наличие соединения и укажет на то, что требуемые параметры при установлении соединения обеспе-

чены. На рис. 30.16 представлены информационные элементы, входящие в со-

общение «Подтверждение вызова». Последнее включает DLCI, указывающее номер КВК, входящий в информационный элемент сообщения «Установка па-

раметров» (рис. 30.11). Однако значение DLCI может не соответствовать зна-

чению DLCI, указанному в информационном элементе сообщения «Установка параметров».

434

Финальным сообщением, используемым в течение фазы установления со-

единения, является сообщение «Подтверждение соединения». Оно передается как ООД вызываемого абонента в направлении АКД сети, так и АКД сети в на-

правлении ООД вызывающего абонента. На рис. 30.17 представлены информа-

ционные элементы, входящие в сообщение «Подтверждение соединения». По-

следнее включает DLCI, указывающее номер КВК, входящий в информацион-

ные элементы сообщений «Установка параметров», «Подтверждение вызова»

(рис. 30.11). Рассмотренная выше фаза установления соединения относится к

«успешной процедуре вызова». Рекомендация ITU-T Q.933 содержит описание ошибочных ситуаций и действий в случае их возникновения.

Рис. 30.17. Информационные элементы, входящие в сообщение «Подтверждение соединения»

в) Фаза разъединения

В этой фазе происходит разъединение ранее установленного КВК. Про-

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

следовательность служебных сообщений при разъединении КВК. На этой схеме показаны действия (по разъединению) всех участников (сторон) информацион-

ного обмена.

В фазе разъединения используются три сообщения: «Запрос разъедине-

ния», «Согласие на разъединение» и «Подтверждение разъединения».

Сообщение «Запрос разъединения» может быть передано либо ООД або-

нента в направлении АКД сети с требованием разъединения КВК, либо АКД сети с целью индикации начала процедуры разъединения. Сообщение «Запрос

435

разъединения» содержит только один информационный элемент «Причина разъединения», формат заголовка которого показан на рис. 30.19.

Этот элемент предназначен только для указания причины разъединения.

Кодирование полей информационного элемента «Причина разъединения» пред-

ставлено на рис. 30.20.

Рис. 30.18. Последовательность передачи сообщений при разъединении

Рис. 30.19. Информационные элементы, входящие в сообщение «Запрос разъединения»

Параметры, содержащиеся в информационном элементе:

стандарт кодирования ITU-Т;

местонахождение непосредственного инициатора разъединения («0001»

— местный пользователь, обслуживаемый частной FR-сетью, «0010» —

местный пользователь, обслуживаемый FR-сетью общего пользования, «0011» — транзитная FR-сеть, «0101» — удаленный пользователь, об-

служиваемый частной FR-сетью, «0100» — удаленный пользователь, об-

436

служиваемый FR-сетью общего пользования, «0001» — международная

сеть);

код причины разъединения. Возможные причины разъединения стандар-

тизированы в Рекомендациях ITU-T Q.933 и Q.931 и имеют свое уникаль-

ное кодирование. Кодовая комбинация «16» означает нормальное разъе-

динение. Необходимо заметить, что для указания причины разъединения не рекомендуется использование кодовой комбинации «00000000» с це-

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

Рис. 30.20. Информационный элемент «Причина разъединения»

В ответ на сообщение «Запрос разъединения» пользователь посылает

«Согласие на разъединение» (рис. 30.18), в котором «сообщает» сети, что ООД разрывает КВК и чтобы последняя информировала об этом вызывающую сто-

рону. Сеть отвечает на это сообщением «Подтверждение разъединения», кото-

рое подтверждает разъединение КВК и служит для индикации того, что DLCI

свободен для следующего использования.

Рис. 30.21. Информационные элементы, входящие в сообщения «Согласие на разъединение» и «Подтверждение разъединения»

437

Форматы сообщений «Согласие на разъединение» и «Подтверждение разъединения» одинаковы, и они содержат (помимо заголовка) один информа-

ционный элемент «Причина разъединения» (рис. 30.21). Этот элемент иденти-

чен тому, который используется в первоначальном сообщении «Запрос разъе-

динения».

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

торого мог быть (в том числе) разрыв межабонентской цепи. В этом случае АКД сети передает сообщение «Согласие на разъединение» (а не «Запрос разъ-

единения») каждому индивидуальному ООД абонента, после чего ожидает со-

ответствующий ответ «Подтверждение разъединения».

Глава 31 Интеграция различных СПД на основе FR-сети

Обычно любой протокол управления высокого уровня (от сетевого уров-

ня и выше) функционирует на основе базового протокола ретрансляции кадров.

В настоящее время имеется несколько стандартов сетевых протоколов, т.е. су-

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

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

FR + сетевой протокол В

Рис. 31.1. Взаимодействие протоколов сетевого уровня

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

Понимая это, АNSI предложил пакет проектов стандартов протоколов и интер-

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

модействовать с высокоуровневыми (сетевыми и выше) протоколами, включая стандарты ISO 8208, 8802.2 и IP-протокол. Тем не менее, являясь международ-

439

ной организацией по стандартизации, АNSI не издает стандарты протоколов де факто, а направляет последние на рассмотрение FRF, которая является между-

народной организацией потребителей (т.е. организацией фирм-производителей,

реализующих стандарты протоколов в своих коммуникационных программно-

аппаратных комплексах).

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

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

который «вкладывается» пакет сетевого протокола) является то, что сетевые протоколы имеют возможность достаточно простого построения (конфигура-

ции) распределенной СПД на основе «простых физических» FR-соединений.

Для достижения этой простоты необходимо иметь некоторый уникальный ме-

ханизм в рамках FR-протокола (дополнение к процедурной и логической харак-

теристикам FR-протокола) для идентификации сетевого протокола при переда-

че пакета, «вкладываемого» в FR-кадр. Главной целью такого механизма явля-

ется обеспечение корректной доставки сообщения пользователя адресату. Рас-

смотрим основные положения проекта международного стандарта, разработан-

ного ANSI (Т1.617, Приложение F).

Сущность способа идентификации сетевого протокола при передаче па-

кета, «вкладываемого» в FR-кадр, заключается в использовании стандартного формата FR-кадра, в котором имеется специальное поле идентификатора про-

токола 3-го уровня в поле данных (рис. 31.2). В дальнейшем такой FR-кадр бу-

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

адресное поле. Имеет стандартный размер — 2 октета, но может быть увеличено при необходимости до 3 или 4 октетов;

440

идентификатор ненумерованного информационного кадра (ИНИК). Это поле кодируется в соответствии с Рекомендацией ITU-T Q.922 (использу-

ется так же, как и в кадре LMI);

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

также для «выравнивания», если это необходимо, размера кадра. Если это поле (либо несколько октетов) используется, то оно должно иметь только нулевое заполнение;

идентификатор протокола сетевого уровня (ИПCУ). Это поле содержит код сетевого протокола, в соответствии с процедурной характеристикой которого осуществляется передача пакета. Кодирование этого поля осу-

ществляется в соответствии со стандартами ANSI и ITU-T, при условии того, что все фирмы-производители примут единую систему идентифика-

ции.

Если некоторый сетевой протокол не имеет ИПСУ, определенного стан-

дартами ANSI/ITU-T, в этом случае может быть использован специальный код

(шестнадцатеричная «08»), который определен в Рекомендации ITU-T Q.933.

Если для ИПСУ используется 4-октетное поле, то оно служит для идентифика-