Статус данного документа
Данный документ предоставляет информацию для сообщества Internet. Этот документ не определяет стандарты Internet какого-либо вида. Распространение данного документа не ограничено.
Тезисы
В некоторые случаях необходимо транспортировать пакеты X.25 через IP сети. Пакетный уровень X.25 требует наличие надежного соединение канального уровня, который в большинстве случаев обеспечивает LAPB. Данный документ описывает метод пересылки пакетов X.25 через IP-сети с помощью инкапсуляции пакетного уровня X.25 в TCP пакеты.
Оглавление
- 1. Введение
- 2. Соглашения
- 3. Отношения между X.25 и TCP
- 4. Полный формат пакета
- 4.1. Заголовок XOT
- 5. TCP соединение, номер порта и номер логического канала (LCN)
- 6. Пакеты XOT
- 6.1. Установление и сброс виртуального соединения
- 6.2. Данные и контроль потока
- 6.3. Пакеты Interrupt и Reset
- 6.4. Пакеты Restart, DTE Reject, Diagnostics, и Registration
- 6.5. Установка PVC
- 7. Подтверждения
- 8. Соглашения по безопасности
- 9. Ссылки
- 10. Адреса авторов
1. Введение
TCP предоставляет надежный байтовый поток. X. 25 требует, чтобы нижний уровень обеспечивал семантику сообщений, в частности граничу между пакетами. Для обеспечения такой возможности используется маленький заголовок XOT (4 байта), используемый для вставки меду пакетами TCP и X.25. Первичное содержание этого заголовка — поле длинны, которое используется для разделения пакетов в TCP потоке.
Вообще, обычно пакеты протокола X.25 и правила передачи состояний (state transition rules) применяются к уровню X.25 в XOT. Исключения будут специально отмечены.
2. Соглашения
Следующие языковые соглашения будут использованы в элементах спецификаций этого документа.
- ДОЛЖЕН или ОБЯЗАТЕЛЬНО — элемент абсолютных требований спецификации.
- СЛЕДУЕТ или РЕКОМЕНДУЕТСЯ — элемент должен поддерживаться, за исключением особых обстоятельств.
- МОЖЕТ или ОПЦИОНАЛЬНО — элемент является необязательным и может поддерживаться или быть пропущенным в каждой конкретной реализации.
Некоторые фрагменты этого документа могут быть помечены как «Пояснение». Эти фрагменты предназначены для того, что бы дать объяснение предшествующему тексту.
3. Отношения между X.25 и TCP
Когда сетевое устройств (хост, маршрутизатор и т.п.) имеет ядро (engine) X.25 (т.е. реализацию протокола), это ядро может быть присоединено к интерфейсу, работающему по LAPB, и/или к логическому интерфейсу работающему по LLC или XOT/TCP/IP. В общем, уровень XOT абсолютно не чувствителен к тому, какие типы пакетов X.25 передает хост. Однако, чтобы повысить способность к взаимодействию между различными реализациями, данных документ в некоторых случаях определяет поведение ядра X.25.
Стандарты X.25 могут по-разному называть типы пакетов различными наименованиями в зависимости от того, какую роль выполняет интерфейс (DTE/DCE) от которого поступил пакет. XOT специально создан, чтобы быть нечувствительным к DTE/DCE роли интерфейса. Таким образом, в этом документе следующие термины будут эквивалентны, если не оговорено специально.
- Call, Call Request и Incoming Call
- Call Confirm, Call Accepted и Call Connected
- Clear, Clear Request и Clear Indication
- Clear Confirm, DTE Clear Confirmation and DCE Clear Confirmation
- Data, DTE Data and DCE Data
- Interrupt, DTE Interrupt и DCE Interrupt
- Interrupt Confirm, DTE Interrupt Confirmation и DCE Interrupt Confirmation
- RR, DTE RR и DCE RR
- RNR, DTE RNR и DCE RNR
- REJ, Reject и DTE REJ
- Reset, Reset Request и Reset Indication
- Reset Confirm, DTE Reset Confirmation и DCE Reset Confirmation
- Restart, Restart Request и Restart Indication
- Restart Confirm, DTE Restart Confirmation и DCE Restart Confirmation
4. Полный формат пакета
Инкапсулированный пакет имеет следующий формат:
--------------------------------- | | | IP заголовок | | | --------------------------------- | | | TCP заголовок | | | --------------------------------- | | | XOT заголовок | | | --------------------------------- | | | X.25 пакет | | | ---------------------------------
Пакет представлен в графическом виде, где данные, посланные раньше, находятся выше. Такое представление будет и дальше использоваться в этом документе, поэтому мы обращаем Ваше внимание на то, что X.25 транспортируется через TCP, и вследствие этого часть пакета для X.25 нарисована ниже части пакета TCP.
4.1. Заголовок XOT
Заголовок XOT имеет следующий формат:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Версия (2 октета)
- Номер версии протокола XOT кодируется двумя октетами. Номер версии ДОЛЖЕН быть 0. Другие значения поля зарезервированы для будущего использования. Если значение поля отличается от 0 TCP соединение ДОЛЖНО быть закрыто.
- Длина (2 октета)
- Длина пакета X.25 кодируется в двух вторых октетах. Значение должно быть длинной пакета. Если длина пакета имеет неправильное значение, TCP соединение ДОЛЖНО быть закрыто.
5. TCP соединение, номер порта и номер логического канала (LCN)
Для каждого виртуального соединения X.25 ДОЛЖНО использоваться отдельное TCP соединение. Все соединения ДОЛЖНЫ быть установлены на TCP порт 1998. Этот порт зарегистрирован фирмой cisco Systems в IANA для использования XOT.
TCP соединение ДОЛЖНО быть уставлено до того, как установлено виртуальное соединение. Виртуальное соединение может поддерживаться после того, как виртуальное соединение сброшено. Данные НЕ ДОЛЖНЫ передаваться с TCP SYN пакетом.
Поле номера логического канала (Logical Channel Number - LCN) в заголовке X.25 пакета не несет никакого значения и имеет произвольную величину. Как следствие, не важно, с какой стороны находится DTE или DCE.
Рассмотрим три устройства А,В и С, где А и В связываются XOT сессиями с C. Возможно С может принять два вызова с одним LSN, если ядро протокола сможет разобраться, что пакеты получены с разных логических (XOT) интерфейсов. Здесь возникает опасность смешения вызовов (требуется правильное значение LCN на одном интерфейсе, которое может быть недопустимым на другом интерфейсе). Поэтому это необходимо для ядра протокола устройства С, чтобы проводить различие между двумя потоками, по чтобы сделать это, поля LCN не достаточно. The XOT protocol design decision was to expect the XOT layer to communicate the stream identification to the X.25 layer.
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 ДОЛЖНЫ быть отвергнуты.
6.2. Данные и контроль потока
Контроль потока трафика в протоколе X.25 является локальной задачей, но различные реализации могут затрагивать поведение XOT.
Реализации XOT могут осуществлять как контроль потока точка-точка (end-to-end flow control), где пакеты DATA, RR и RNR посылаются через TCP соединение так, как они получены с локального интерфейса, так и локальный контроль потока, где пакеты управления потоком (RR, RNR и если поддерживается REJ) посылаются по виртуальному соединению в соответствии с локальными критериями, законченная последовательность пакетов может быть фрагментирована или комбинирована, а нумерация пакетов данных может иметь локальное для DTE-DCE значение.
Существующие реализации XOT поддерживают контроль потока данных точка-точка. Данные и пакеты контроля потока данных просто пересылаются между двумя локальными интерфейсами по TCP соединению, настраивая данные в заголовке X.25 как требуется для работы со смешанным модулем (mixed modulo operation). Это не мешает реализации XOT осуществлять локальный контроль потока, но способность к взаимодействию требует, чтобы реализация XOT с локальным контролем потока выполняла сессию XOT таким образом, чтобы реализация XOT с контролем потока точка-точка могла принимать пакеты данных правильного размера и чтобы значения полей управления потоком данных принимали соответствующие значения P(S) и P(R).
Реализация X.25, которые осуществляют локальный контроль потока данных, может установить соединение между двумя локальными интерфейсами, где каждый логический интерфейс может иметь собственный размер пакета и размер пакетного окна и пакеты данных могут быть фрагментированы или агрегированы между интерфейсами и каждый интерфейс обслуживает нумерацию пакетов данных. Функционирование XOT просто расширение такого режима работы, где виртуальное соединение устанавливается между локальным интерфейсом и виртуальным интерфейсом XOT/TCP, где каждый имеет собственный размер пакета и пакетного окна.
Реализация XOT, которая осуществляет локальное управление потоком данных, ДОЛЖНА послать подтверждения пакетов данных через соединение TCP для пакетов DATA, которые она принимает через соединение TCP, используя полученные номера пакетов, и ДОЛЖНО соблюдать максимальные размеры пакета согласованные для подключения TCP.
Реализация XOT, НЕ ДОЛЖНА предполагать, что пакет RNR посланный через соединение TCP будет останавливать поток пакетов DATA, идущих в другом направлении через соединение TCP. Пакет RNR, полученный через соединение TCP МОЖЕТ стать причиной для посылки пакета RNR через локальный интерфейс. Реализации XOT, использующие контроль за потоком данных точка-точка МОГУТ взаимодействовать через значения P(R) в пакеты RNR, полученные через соединение TCP, посылая пакет RR в локальный интерфейс.
Реализации XOT, которые поддерживают соединения с разными модулями (mixed-modulo connections) и реализуют контроль за потоком данных точка-точка ДОЛЖНЫ вмешиваться в процесс установления размера окна, когда Call Request предполагает модуль 128 и размер окна 8 или больше на любом соединении XOT, которое обслуживает интерфейс с модулем 8. Это вмешательство должно состоять или в отказе на соединение или в понижении слишком большого размера окна до допустимого для интерфейса размера и указании конечного результата выбора размера окна в пакете Call Confirm, возвращаемого через TCP соединение.
Для любых типов реализаций управления потоком, поддерживающих mixed modulo connections, оба взаимодействующие XOTа ДОЛЖНЫ интерпретировать значения P(S) и P(R) полученные через TCP соединение и выполнять любые операции по управлению потоком для обеспечения правильного функционирования протокола X.25 на локальном интерфейсе. Реализации управления потоком точка-точка ДОЛЖНЫ выполнять преобразования между двумя модулями и создавать поля P(S) P(R) в аналогичные заголовках пакетов X.25 DATA, RR и RNR.
Любая реализация XOT МОЖЕТ поддерживать две XOT TCP сессии между собой. Если эта особенность поддерживается, XOT ДОЛЖЕН просто устанавливать две TCP сессии без модификации переданных данных.
6.3. Пакеты Interrupt и Reset
Пакеты Interrupt, Interrupt Confirm, Reset и Reset Confirm передаются через TCP соединение с использованием нормального формата пакетов X.25 и изменения состояний (state transitions). Непрерывная природа сервисов Interrupt и Reset ДОЛЖНА поддерживаться для правильного функционирования X.25.
6.4. Пакеты Restart, DTE Reject, Diagnostics, и Registration
Пакеты X.25, которые имеют только локальное значение для интерфейса (Restart, DTE Reject, Diagnostics, и Registration) НЕ ДОЛЖНЫ передаваться через соединение TCP. Если эти пакеты получены, то они ДОЛЖНЫ быть проигнорированы.
6.5. Установка PVC
Любая реализация XOT МОЖЕТ поддерживать установления PVC через XOT.
PVC X.25 являются виртуальными соединениями. Предполагается, что они должны быть доступны, когда доступен сервис X.25 (то есть в состоянии R1). Установление PVC через XOT осложняется из-за отсутствия пакетов Call, Call Confirm, Clear или Clear Confirm которые передаются через X.25 интерфейс — PVC просто доступны потому что они были созданы сетевым провайдером по договоренности с пользователями.
Поддержка PVC с использованием XOT требует от объектов XOT обмена данными не описанного стандартами X.25 и должен поддерживаться ряд аварийных ситуаций.
Установка PVC между двумя объектами XOT выполняется с использованием обмена нестандартными пакетами X.25 (инкапсулированными в заголовок XOT). Процесс обмена данными для установления PVC начинается сразу после установления сессии TCP. Объект XOT установивший TCP соединение называется инициатором, второй респондером.
Пакет PVC Setup включает поля General Format Identifier, LCN и Packet Type Identifier, следующие за дополнительными данными. Этот нестандартный пакет имеет следующую структуру:
+--+--+--+--+--+--+--+--+--+ | X.25 GFI | X.25 LCN | +--+--+--+--+ + | | +--+--+--+--+--+--+--+--+--+ | X.25 PTI | PVC setup PTI (= 0xF5) +--+--+--+--+--+--+--+--+--+ | | version (= 0x81) +--+--+--+--+--+--+--+--+--+ | | status +--+--+--+--+--+--+--+--+--+ | | initiator interface name length (N) +--+--+--+--+--+--+--+--+--+ | | initiator LCN (high octet) +--+--+--+--+--+--+--+--+--+ | | initiator LCN (low octet) +--+--+--+--+--+--+--+--+--+ | | responder interface name length (M) +--+--+--+--+--+--+--+--+--+ | | responder LCN (high octet) +--+--+--+--+--+--+--+--+--+ | | responder LCN (low octet) +--+--+--+--+--+--+--+--+--+ | | sender incoming window +--+--+--+--+--+--+--+--+--+ | | sender outgoing window +--+--+--+--+--+--+--+--+--+ | | sender incoming max. packet size +--+--+--+--+--+--+--+--+--+ | | sender outgoing max. packet size +--+--+--+--+--+--+--+--+--+ | | initiator interface name (N octets) | | +--+--+--+--+--+--+--+--+--+ | | responder interface name (M octets) | | +--+--+--+--+--+--+--+--+--+
PVC пакет установки был разработан так, чтобы responder мог просто изменять несколько полей полученного пакета и посылать это назад инициатору.
Packet Type Identifier выбран из неиспользуемых значений X.25 PTI для того чтобы отличаться от стандартных идентификаторов типов пакетов X.25.
Значение PVC setup version было выбрано для предотвращения соединений с предыдущими экспериментальными реализациями.
Поле PVC status может принимать следующие предопределенные значения:
| Статус | Значение |
| 0x00 | Ожидание соединения |
| 0x08 | Адресат разъединен |
| 0x09 | PVC/TCP соединение отвергнуто |
| 0x0A | Ошибка маршрутизации PVC/TCP |
| 0x0B | PVC/TCP таймаут соединения |
| 0x10 | Попытка соединения через TCP |
| 0x11 | Ожидание ответа PVC-SETUP |
| 0x12 | Соединено |
| 0x13 | Не существует интерфейс назначения |
| 0x14 | Интерфейс назначения не работает |
| 0x15 | Интерфейс назначения не поддерживает X.25 |
| 0x16 | Не существует PVC назначения |
| 0x17 | Несовпадение параметров конфигурации PVC |
| 0x18 | Несовпадение параметров управления потоком |
| 0x19 | Неподдерживаемые значения параметров управления потоком |
| 0x1A | Ошибка протокола установления PVC |
Не все значения статуса PVC соответствуют пакету PVC setup; эти значения представляют собой частичную реализацию, в которой выбраны три группы для присвоения значений, которые соответствуют короткому таймеру (short timer) для попытки соединения (0x00 - 0x07), длинному таймеру (long timer) для попытки соединения (0x08 - 0x0F), а также отсутствию попытки установления соединения (начиная с 0x0F). Значения соответствующие пакету PVC setup : 0x00 и больше 0x12.
Большинство значений ошибок статуса PVC, за несколькими исключениями, могут быть найдены в пакете установки соединения. Значение 0x17 «Несовпадение параметров конфигурации PVC» может быть возвращено с случае если PVC назначения уже имеет активное соединение XOT PVC. Значение 0x19 «Неподдерживаемые значения параметров управления потоком» может быть возвращено в случае, когда значения управления потоком совпадают, но например, интерфейсом запрошен модуль 8 для установления PVC с размером окна более 7 или интерфейсом запрошено установление PVC с максимальным размером пакета размером пакета слишком большим для канального уровня.
XОТ МОЖЕТ повторить неудачное установление PVC, если это реализовано, XOT ДОЛЖЕН сделать паузу между попытками (предлагается 5 мин.)
Каждое PVC на XOT конфигурируется идентично другому XOT (т.е. IP адрес, имя интерфейса для соединения, номер логического канала, значения параметров управления потоком). Данные представленные в пакете PVC setup проверяются удаленным XOT и подтверждаются как совместимые.
Поля имен интерфейсов являются ASCII именами двух интересов. Этим именам СЛЕДУЕТ быть не чувствительными к регистру и НЕ ДОЛЖНЫ содержать дополняющих или конечных нулевых октетов между или перед именами интерфейсов.
Значения управления потоком данных — это значения, которые зависят от локального интерфейса, реализации XOT, которая послала пакет PVC setup. Значение максимального размера пакета кодируется как в пакете size facility (т.е. два в степени размер пакета в октетах, так что значение 7 представляет собой максимальный размер пакета в 128 октетов). Если отвечающий XOT осуществляет управление потоком данных точка-точка, то он будет требовать совместимые значения управления потоком данных, так что возвращенный статус 0x18 будет индицировать значения, требуемые для отвечающего XOT (заметим, что входящее значение на одном локальном интерфейсе соответствует исходящему значению на подсоединенном к нему интерфейсу и наоборот).
После установления TCP соединения, инициатор посылает пакет PVC setup, где значение статуса ДОЛЖНО быть 0x00, респондер будет отвечать ему своим пакетом PVC setup или закроет TCP соединение. PVC XOT считается успешным, если респондер вернет статус 0x00. Однажды установленное соединение PVC XOT МОЖЕТ быть завершено процедурой Reset на локальном интерфейсе, так что если локальный интерфейс LCI в состоянии D1, пакет Reset может быть сгенерирован на обоих интерфейсах: на локальном и на интерфейсе XOT TCP.
Соединение XOT PVC может быть прервано простым закрытием TCP соединения. Пакеты X.25, которые не являются правильными для PVC НЕ ДОЛЖНЫ передаваться через XOT PVC соединение. Когда локальный интерфейс подвергается процедуре Restart, XOT PVC соединение должно выполнить Reset или закрыть XOT PVC соединение.
Реализации XOT СЛЕДУЕТ решить, как будет обрабатываться коллизия попыток установления соединения. Получение XOT PVC setup для PVC, которое само делает попытку к установке XOT соединения, может принять попытку установить соединение, и если TCP XOT в результате просто использует одно соединение для посылки данных XOT (XOT НЕ ДОЛЖЕН посылать трафик через оба) и принимает трафик на другом, или может закрыть входящую попытку или может повторить попытку соединения через случайный промежуток времени. Если два соединения позволены для PVC, то при закрытии одного СЛЕДУЕТ закрыть другое.
7. Подтверждения
Грег Сатз (Greg Satz) — первоначальный проектировщик и implementor X.25 через TCP. Авива Гаретт (Aviva Garrett) из cisco Systems рассмотрел технические условия и внес много редакционных исправлений.
8. Соглашения по безопасности
Проблемы безопасности не рассматриваются в этом документе.
9. Ссылки
| [1] | Reynolds, J., and J. Postel, «Assigned Numbers», STD 2, RFC 1340, USC/Information Sciences Institute, Июль 1992. |
| [2] | CCITT, Blue Book Volume VIII--Fascicle VIII.2, «Data Communication Networks: Services and Facilities, Interfaces»; Recommendation X.25, «Interface Between Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode and Connected to Public Data Networks by Dedicated Circuit», 1989, Geneva. |
10. Адреса авторов
James R. Forster
Engineering Dept.
cisco Systems
1525 O'Brien Dr.
Menlo Park. CA. 94025
Phone: 1.415.688.8245
Fax: 1.415.688.8282
EMail: moc.ocsic@retsrof
Greg Satz
Engineering Dept.
cisco Systems
1525 O'Brien Dr.
Menlo Park. CA. 94025
Phone: 1.415.688.8245
Fax: 1.415.688.8282
EMail: moc.ocsic@ztas
Gilbert Glick
Engineering Dept.
cisco Systems
1525 O'Brien Dr.
Menlo Park. CA. 94025
Phone: 1.415.688.8245
Fax: 1.415.688.8282
EMail: moc.ocsic@kcilgg
Bob Day
Joint Network Team
c/o Rutherford Appleton Laboratory
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Phone: 44.235.44.5163
Fax: 44.235.44.6251
EMail: ku.ca.tnj@yad.r