RFC: 1613
Оригинал: X.25 over TCP (XOT)
Категория: Информационный
Дата публикации:
Авторы: , , ,
Перевод: Игорь Шеваров

RFC 1613, Страница 5 из 9

6. Пакеты XOT

Перед тем как отправить пакет, полученный через TCP соединение, в локальный интерфейс, любая реализация XOT ДОЛЖНА выставить в пакете номер логического канала, который использовался на другом интерфейсе. Для целей преследуемых данным документом, под номером логического канала следует понимать 12-битное поле, которое в стандарте X.25 определяется, как последовательность из старших 4 бит «номера группы логических каналов» и младших 8 бит «логического номера канала», где последняя фраза относится как 12 битной последовательности в целом, так и к младшим 8 битам.

Любой реализации XOT НЕ СЛЕДУЕТ модифицировать заголовки пакетов X.25, полученные из локального интерфейса для отправки через TCP соединение.

Любая реализация XOT ДОЛЖНА модифицировать заголовки пакетов X.25, полученных из соединения TCP для передачи на локальный интерфейс, как это требует правильное функционирование протокола X.25.

Любая реализация XOT МОЖЕТ поддерживать соединение между двумя интерфейсами, использующими разный модуль управления потоком (flow control modulos). Если эта возможность поддерживается, XOT ДОЛЖЕН модифицировать общий идентификатор формата (General Format Identifier) во всех пакетах полученных через TCP соединение, чтобы выставить правильный идентификатор модуля.

6.1. Установление и сброс виртуального соединения

Как только устанавливается TCP соединение, XOT посылается пакет X.25 Call, которой инициализировал это соединение. В конечном счете, приходят пакеты Call Confirm или Clear или происходят таймауты Т11\Т12 или соединение XOT TCP сбрасывается. Обычно при этом приходит изменение состояния X.25.

Любые услуги X.25 из семейства протоколов X.25 (включая, но не ограничиваясь рекомендациями CCITT X.25 1980, 1984 и 1988 г. МОГУТ быть включены в пакеты Call, Call Confirm и Clear). Получение неизвестной или неподдерживаемой услуги через соединение TCP ДОЛЖНО быть проигнорировано (т.е. не добавляться в пакет, посылаемый в локальный интерфейс) или обработано как ошибка, как определено реализацией стандарта X.25.

Чтобы упростить управление потоком данных точка-точка, размер пакета и размер окна должны быть явно посланы в пакете Call как услуги. Пакет Call ДОЛЖЕН содержать размер пакета и размер пакетного окна. Пакет Call Confirm МОЖЕТ содержать эти услуги. Обработка пакета Call, полученного через соединение XOT, которое кодирует одну или обе услуги управления потоком локальная задача — если XOT принимает такие пакеты Call, он ДОЛЖЕН кодировать пропущенные услуги управления потоком данных, которые возвращаются в пакете Call Confirm.

Интерфейсы X.25 как правило имеют общие для всей сети значения по умолчанию для пакетного окна и размера пакетов. Думается, что при соединении разных узлов X.25 через сеть TCP/IP это трудно достижимо. Если такие значение по умолчанию не определены, то каждый пакет Call должен объявить явно размер пакета и пакетного окна. Это является причиной для необходимости таких услуг, как размер пакета и пакетного окна. Ожидается, что это может быть достигнуто или самим уровнем XOT или конфигурированием ядра протокола X.25, например отказом от значений по умолчанию.

После отправки пакета Clear, TCP соединение МОЖЕТ быть сброшено немедленно, без ожидания пакета Clear Confirm. Clear Confirm, полученный по TCP МОЖЕТ быть отвергнут.

Пакеты X.25 с неправильным идентификатором типа пакета (Packet Type Identifier (PTI)) полученные через TCP соединение перед получением пакета Call, то есть в состоянии Р1 ДОЛЖНЫ быть отвергнуты.

2007 - 2018 © Русские переводы RFC, IETF, ISOC.