Группа разработки сетей J. Forster Запрос за Коментариями: 1613 G. Satz Категория: Информация G. Glick cisco Systems, Inc. R. Day JANET Май 1994 Cisco Systems X.25 по TCP (XOT) Статус этого документа Этот документ предоставляет информацию для интернет сообщества. Этот документ не определяет интернет стандарты любого сорта. Распростра- нение этого документа неограниченно. Содержание 1. Введение........................................................Х 2. Соглашения......................................................Х 3. Родство между XOT and X.25......................................Х 4. Специальный формат пакетов......................................Х 4.1 XOT заголовок.................................................Х 5. TCP соединение, номер порта, и номера Логического Канала (LCNs).Х 6. XOT пакеты......................................................Х 6.1 Установление Виртуальной Цепи (VC) и Завершение...............Х 6.2 Контроль данных и потока......................................Х 6.3 Прерывания, и сбрасывающие (Reset) пакеты.....................Х 6.4 Рестарт, DTE отвержение, Диагностика, и Регистрация...........Х 6.5 Установление Постоянной Виртуальной Цепи (PVC Setup)..........Х 7. Согласования...................................................ХХ 8. Обсуждение безопасности........................................ХХ 9. Ссылки.........................................................ХХ 10. Адреса авторов.................................................ХХ 1. Введение Иногда необходимо передовать X.25 пакеты по IP сетям. Пакетный уровень X.25 требует чтобы более низкий уровень (по модели OSI) обеспечивал надежную доставку данных, обычно для этого используеться LAPB. Этот документ описывает метод посылки X.25 пакетов по IP сетям используя инкапсуляцию пакетного уровня X.25 в TCP пакеты. Протокол TCP обеспечивает надежную доставку данных. Пакетный уровень X.25 требует, чтоб уровень ниже его обеспечивал семантику сообщений, в частности границу между пакетами. Для обеспечения этого, небольшой (4-х байтовый) XOT заголовок используеться между TCP и X.25 протоколами. Основное содержание этого заголовка, это поле длинны, Forster, Satz, Glick & Day [Стр. 1] RFC 1613 X.25 по TCP (XOT) Май 1994 которое используеться для разделения X.25 пакетов внутри TCP потока. В основном, обычные форматы X.25 пакетов и состояния правил передачи применимы к X.25 уровню в XOT. Исключения из этого будут описанны. 2. Соглашения Следующие языковые соглашения используються в этом документе: o ДОЛЖЕН, БУДЕТ, или ОБЯЗАТНЛЬНО -- Это абсолютное требование спецификации. o НУЖНО или РЕКОМЕНДУЕТЬСЯ -- Это то, что в общем случае должно быть справедливо, но возможны исключения. o МОЖЕТ или по ВЫБОРУ -- Это требование спецификации действите- льно может быть либо использовано, либо проигнорированно, в зависимости от требований внедряющего. В некоторых местах этого документа дан вводный материал обозначенный "ДИСКУССИЯ". Этот материал предназначен для того, чтобы полностью прояснить и дать правильное толкование предшествовавшему тексту. 3. Родство между XOT и X.25 Когда сетевое устройство (ХОСТ, РОУТЕР, итп.) имеет X.25 движок (напр. протокольное исполнение), то этот движок может быть соединен с итерфейсом(-ами) который использует LAPB, и/или к логическому интерфейсу(-ам) использующему LLC или XOT/TCP/IP. В основе, XOT слой сам по себе, не ко всему чувствительный, некоторые виды пакетов X.25, движок пропускает. Однако, для улучшения взаимодействия между разли- чными исполнениями, этот документ в некоторых случаях, должен описать специальные свойства X.25 движка. В целом этот документ обсуждает XOT как перспективу переключения (switching) X.25 трафика(напр. соединение X.25, Виртуальной Цепью, локальных X.25 интерфейсов 2-х сетевых устройств), Это не отвергает использования XOT для X.25 соединений. Различные X.25 стандарты могут называть заданный тип пакета разными именами, связанными с назначением DTE/DCE роли того интерфейса, которым порожден пакет. XOT намеренно не чувствителен к DTE/DCE роли локального интерфейса, то есть что того, что другого конца в XOT TCP соединении, также, для этого документа, следующие определения чере- дуються, если не указанно иначе: Forster, Satz, Glick & Day [Стр. 2] RFC 1613 X.25 по TCP (XOT) Май 1994 o Вызов(Call), Запрос Вызова и Входящий Вызов o Подтверждение Вызова, Вызов принят и Вызов соединен o Завершение(Clear), Запрос на Завершение и Индикатор Завершения o Подтверждение Завешения, Подтверждение DTE завершения и Подтверждение DCE завершения o Данные, DTE Данные и DCE Данные o Прерывание(Interrupt), DTE Прерывание и DCE Прерывание o Подтверждение Прерывания, DTE Подтверждение Прерывания и DCE Подтверждение Прерывания o RR, DTE RR и DCE RR o RNR, DTE RNR и DCE RNR o REJ, Отвержение(Reject) и DTE REJ o Сброс(Reset), Запрос на Сброс и Индикатор Сброса o Подтверждение Сброса, DTE Подтверждение Сброса и DCE Подтверждение Сброса o Рестарт (Restart), Запрос на Рестарт и Рестарт Индикатор o Подтверждение Ресарта, DTE Подтверждение Ресарта и DCE Подтверждение Ресарта 4. Специальный формат пакетов Полный инкапсулированный пакет имеет следующий формат: --------------------------------- | | | IP заголовок | | | --------------------------------- | | | TCP заголовок | | | --------------------------------- | | | XOT заголовок | | | --------------------------------- | | | X.25 пакет | | | --------------------------------- RFC соглашение таково, что формат пакета представлен графически таким образом, чтоб данные посылались с верху вниз. Этому соглашению следует и этот документ, и кроме того, везде, пока мы описываем посылку Х.25 по TCP, мы рисуем формат пакета с Х.25 части пакета, которая ниже чем TCP часть. Forster, Satz, Glick & Day [Стр. 3] RFC 1613 X.25 по TCP (XOT) Май 1994 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Версия | Длинна | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Версия (2 байта) Номер версии XOT протокола зашифрован в первых 2-х байтах. Номер версии ДОЛЖЕН быть 0. Другие значения этих полей зарезервированны для использования в будущем. Если значение отличное от 0 полученно, тогда TCP соединение ДОЛЖНО быть закрыто. Длинна (2 байта) Длинна X.25 пакета зашифрованна в следующих 2-х байтах, ее значение должно быть равно размеру X.25 пакета. Если поле длинны имеет неверное значение, тогда TCP соединение ДОЛЖНО быть закрыто. 5. TCP Соединение, Номер Порта, и Номер Логического Канала(LCNs) Различные TCP соединения ДОЛЖНЫ быть использованны для каждой X.25 Виртуальной Цепи. Все соединения ДОЛЖНЫ быть сделаны на TCP порт с номером 1998. Этот номер порта являеться IANA зарегистрированным, он зарегистрирован cisco Systems; cisco зарезервировало его для XOT. TCP соединение ДОЛЖНО быть создано перед установлением Виртуальной Цепи. TCP соединение МОЖЕТ поддерживаться после завершения Виртуаль- ной Цепи. Данные НЕ ДОЛЖНЫ приходить вместе с TCP SYN пакетом. Поле Логического Номера Канала(LCN) в X.25 заголовке не имеет значения и может быть произвольным. Обьясняеться это тем, что не имеет значения с какой стороны пришел вызов, DTE или DCE. ДИСКУССИЯ Рассмотрим три устройства A, B и C, когда A и B оба имеют XOT сессии с C. Возможно то, что C получит два вызова с одинаковыми LCN и, если X.25 движок не может сказать, что они полученны с 2-х разных логических (XOT) интерфейсов, тогда возможна коллизия вызова(в самом деле, правильный LCN на одном интерфейсе Forster, Satz, Glick & Day [Стр. 4] RFC 1613 X.25 по TCP (XOT) Май 1994 может не быть правильным на другом). Однако разделение необходимо для C-того X.25 движка, но LCN поля для этого не достаточно. XOT протокол был разработан, с учетом решения этой проблемы, то есть XOT уровень ожидает соединения и идентифицирует потоки X.25. 6. XOT Пакеты Для каждого X.25 пакета полученного от TCP соединения, который необходимо послать дальше локального интерфейса, XOT исполнение ДОЛЖНО установить Логический Номер Канала (LCN) соответствующий удаленому итерфейсу. LCN, это 12 битное поле, определенное X.25 рекомендацией таким образом: старшие 4 бита это "Групповой Номер Логического Канала", младшие 8 бит - "Номер Логического Канала", оба они обьединены в 12 битное поле LCN. XOT исполнению НЕ НУЖНО модифицировать информацию в заголовке Х.25 пакета полученного на локальный интерфейс для того чтоб передать по TCP содинению. XOT исполнение ДОЛЖНО модифицировать информацию в заголовке X.25 пакета, как требуеться для присущих X.25 протоколу операций, для пакетов полученных через TCP соединеия, для передачи их через локальный интерфейс. XOT исполнение МОЖЕТ поддерживать соединение между интерфейсами которые используют различные модули контроля потока. Если эта особенность поддерживаеться, XOT ДОЛЖЕН модифицировать Общий Идентификатор Формата (GFI) пакета, для всех пакетов полученных по TCP соединению, для установки свойственного модулю идентификатора. 6.1 Установление Виртуального Круга (VC) и Завершение(Clear). Как только TCP соединение будет установленно, X.25 пакет Вызова пошлет тот XOT, который инициировал TCP соединение. Со временем будет полчуен пакет Подтверждения вызова или Завершения вызова, или произойдет X.25 T11/T21 таймаут или XOT TCP соединение закроеться, иначе обычные X.25 состояния передачи последуют. Любые правильные X.25 Свойства(facilities) из семейства X.25 протоколов (включая, но не ограничеваясь рекомендациями CCITT X.25 за 1980, 1984 и 1988 года) МОГУТ быть включенны в Вызов, Подтверждение Вызова и Завершение пакеты. Получение неизвестных или не поддерживаемых X.25 Свойств, полученных из TCP соединения, ВОЗМОЖНО будут игнорированны (например не присутствовать в пакете посылаемом с локального интерфейса) или обрабатывать как ошибку определенную в исполнении X.25 стандарта. Forster, Satz, Glick & Day [Стр. 5] RFC 1613 X.25 по TCP (XOT) Май 1994 Для упрощения контроля потока "Конец-Конец", размер пакета и размер окна всегда посылаються явно, как Свойство в пакете Вызова. Пакет Вызова ДОЛЖЕН содержать оба, Размер Пакета и Размер Окна Свойства. Пакет Подтверждения Вызова МОЖЕТ содержать эти свойства. Вызов полученный через TCP соединение, не закодированный одной или обоими свойствами контроля потока -- если XOT принимает такой Вызов, он ДОЛЖЕН закодировать отсутствующие свойства контроля потока приемлемыми значениями, которые возвращаються в пакете Подтверждения Вызова. ДИСКУССИЯ X.25 интерфейсы обычно имеют, в зависимости от сети, значения по умолчанию для размера пакета и размера окна. Но когда соединяються разнообразные участки по TCP/IP сети, то эта концепция будет сложной для достижения на практике. Если нет в сети умолчаний, тогда, для каждого вызова должны быть заявленны размер пакета и размер окна. Это достижимо либо самим слоем Х.25 либо через конфигурирование Х.25 движка. После посылки Завершения, TCP соединение МОЖЕТ быть закрыто немедленно, без ожидания Подтверждения Завершения. Пакет Подтверждения Завершения, полученный через TCP соединение, МОЖЕТ быть тихо уничтожен. Пакет с неправильным X.25 Идентификатором типа пакета (PTI) полученный по TCP соединению перед получением Вызова (например в P1 состоянии) ДОЛЖЕН быть тихо уничтожен. 6.2 Контроль данных и потока ДИСКУССИЯ Исполнение X.25 контроля потока, это предмет текущего обсуждения, но различные исполнения подверженны своим особенностям. XOT исполнение может поддерживать другой "Конец-Конец" контроль потока, когда DATA, RR и RNR пакеты посылаються по TCP соединению как будьто они полученны по другому локальному интерфейсу, или локальный контроль потока, когда пакеты контроля потока (RR, RNR и, если поддерживаеться, REJ) посылаються на Виртуальное кольцо (VC) согласно локальному критерию, в заключении, последовательность DATA пакетов может быть фрагментированна, или скомбинирова, а пакеты с данными нумеруються обычно, используя только локальное DTE-DCE значения. Существующие исполнение XOT предоставляет "Конец-Конец" контроль потока. Пакеты контроля потока и данных просто передаються между Forster, Satz, Glick & Day [Стр. 6] RFC 1613 X.25 по TCP (XOT) Май 1994 двумя локальными интерфейсами через TCP соединение, эта передача регулируеться данными X.25 заголовка как необходимо для смешанных modulo операций. Это не мешает XOT исполнению, что предоставляет локальный контроль потока, но для межвзаимодействия требуеться чтоб исполнение локального контроля потока вело XOT сессию так, чтоб соединение с исполнением "Конец-Конец" контроля потока, получало ДАТА пакеты с присущим ему размером, и полями контроля потока с присвоенными P(S) и P(R) значениями. X.25 исполнение предоставляющее локальный контроль потока похожим образом может устанавливать Вызов между двумя локальными интерфейсами, где каждый логический канал имеет свои собственные размеры пакета и окна, и ДАТА пакеты должны быть фрагментированны или собранны между интерфейсами и каждый интерфейс управляет своими номерами пакетной последовательности; XOT операции простые, в расширении этих операций Виртуальной Цепью так же может быть соединение между локальным интерфейсом и XOT/TCP виртуальным интерфейсом, каждый из которых имеет индивидуальные размеры окна и пакета. XOT, который осуществляет локальный контроль потока ДОЛЖЕН послать пакеты Подтверждения через TCP соединение для пакетов с данными которые полученны через это соединение, используя полученные номера пакетов, и ДОЛЖЕН соблюсти чтоб максимальные размеры пакета были соглассованы для передачи через TCP соединение. XOT исполнение НЕ ДОЛЖНО предполагать что RNR пакеты посланные через TCP соединение будут останавливать поток пакетов с данными в другом направлении. RNR пакеты полученные через TCP соединение МОГУТ быть причиной RNR пакета который будет послан на локальный интерфейс; "Конец-Конец" исполнение контроля потока МОЖЕТ передать P(R) в RNR пакет полученный через TCP соединение, посылкой RR пакета на локальный интерфейс. XOT исполнение которое допускает смешанные-modulo соединения и исполнение "Конц-Конец" контроля потока ДОЛЖНО вмешиаться в процесс переговоров о размере окна, когда modulo 128 Запрос Вызова предлагает размер окна 8 или больше для XOT соединения, который обслуживает modulo 8 интерфейс. Вмешательство ДОЛЖНО заключаться в том чтоб либо завершить соединение, либо понижать очень большие размер(ы) окна значением пригодным для интерфейса и известить об окончательном результате размера окна переговорному процессу в пакете Подтверждения Вызова, который возвращаеться по TCP соединению. Для любого типа исполнения контроля потока, который поддерживает смешанные modulo соединения, оба сотрудничающих ХOTа ДОЛЖНЫ интерпретировать P(S) и P(R) значения полученные из TCP соединения и предоставлять любые операции контроля потока необходимые для правильных X.25 операций на локальном интерфейсе. Исполнение "Конец-Конец" контроля потока ДОЛЖНО транслироваться между двумя modulos и создавать в X.25 заголовке аналогичные P(S) и P(R) поля для DATA, RR и RNR пакетов. Forster, Satz, Glick & Day [Стр. 7] RFC 1613 X.25 по TCP (XOT) Май 1994 XOT исполнение МОЖЕТ поддерживать соединение двух ХОT TCP сессий. Если это свойство поддерживаеться, ХОТ ДОЛЖЕН просто соединить две TCP сессии без изменения проходящих данных. 6.3 Прерывания, и сбрасывающие(RESET) пакеты Прерывание, Подтверждение Прерывания, Сброс и Подтверждение Сброса пакеты посылаемые по TCP соединению используют обычные X.25 форматы пакетов и состояния передачи. "Конец-Конец" характер обоих Прерывания и Сброса сервисов ДОЛЖЕН поддерживаться для правильных X.25 операций. 6.4 Рестарт, DTE Отвержение(Reject), Диагностика, и Регистрация X.25 пакеты имеющие только локальное DTE/DCE интерфейсное значение (Рестарт, Рестарт Подтверждение, DTE отвержение, диагностика, Запрос на Регистрацию и подтверждение регистрации) НЕ ДОЛЖНЫ быть посланны по TCP соединению. Если один из этих пакетов получен, тогда он ДОЛЖЕН быть тихо уничтожен. 6.5 Установка постоянной виртуальной цепи(PVC) XOT исполнение МОЖЕТ поддерживать PVC соединение через XOT. ДИССКУСИЯ X.25 PVC это Виртуальные Цепи которые доступны, когда X.25 сервис свободен (то есть, в R1 сосотянии). Соединение PVC через XOT сложно, потому что нет Вызова, Подтверждения Вызова, Завершение или Подтверждения Завершения пакетов передающихся (или доступных) через X.25 интерфейс--обычные PVC легко доступны, потому что их соединения обеспечиваються сетевым провайдером по контракту с пользователем. Поддержка PVC, используя ХOT, требует обмен данными между различными XOT, что вне области X.25 стандартов, и необходимость поддержки номеров ошибочных состояний. Установка PVC между двумя XOTами осуществляеться обменом нестандартными типами X.25 пакетов (инкапсулированными в XOT заголовок); PVC установочный обмен происходит немедленно после того как произошла установка нового TCP XOT соединения. XOT исполнение которое инициировало TCP соединение это ИНИЦИАТОР; другой XOT это ОТВЕТЧИК. Forster, Satz, Glick & Day [Стр. 8] RFC 1613 X.25 по TCP (XOT) Май 1994 PVC пакет установки включает X.25 Идентификатор Общего Формата(GFI), LCN и Идентификатор Типа Пакета(PTI) поля следующие за дополнительными данными. Эти нестандартные типы пакетов имееют следующию форму: +--+--+--+--+--+--+--+--+--+ | X.25 GFI | X.25 LCN | +--+--+--+--+ + | | +--+--+--+--+--+--+--+--+--+ | X.25 PTI | PTI, Установка PVC (= 0xF5) +--+--+--+--+--+--+--+--+--+ | | Версия (= 0x81) +--+--+--+--+--+--+--+--+--+ | | Статус +--+--+--+--+--+--+--+--+--+ | | Длина имени интерфейса Инициатора (N) +--+--+--+--+--+--+--+--+--+ | | Инициатор LCN (верхние байты) +--+--+--+--+--+--+--+--+--+ | | Инициатор LCN (нижние байты) +--+--+--+--+--+--+--+--+--+ | | Длина имени интерфейса Ответчика (M) +--+--+--+--+--+--+--+--+--+ | | Ответчик LCN (верхние байты) +--+--+--+--+--+--+--+--+--+ | | Ответчик LCN (нижние байты) +--+--+--+--+--+--+--+--+--+ | | посылаемое входящее окно +--+--+--+--+--+--+--+--+--+ | | посылаемое выходящее окно +--+--+--+--+--+--+--+--+--+ | | посылаемый максимальный размер входящего пакета +--+--+--+--+--+--+--+--+--+ | | посылаемый максимальный размер выходящего пакета +--+--+--+--+--+--+--+--+--+ | | Имя интерфейса Инициатора (N байт) | | +--+--+--+--+--+--+--+--+--+ | | Имя интерфейса Ответчика (M байт) | | +--+--+--+--+--+--+--+--+--+ ДИССКУСИЯ PVC установочный пакет был разработан так чтобы Ответчик мог просто модифицировать несколько полей полученного пакета и отослать его обратно. Forster, Satz, Glick & Day [Стр. 9] RFC 1613 X.25 по TCP (XOT) Май 1994 PTI был выбран из не используемых X.25 PTI значений, так что это индивидуальный, от стандарта X.25, PTI. Значение версии PVC установки, было выбрано чтоб предотвратить соединения с предшествующими экспериментальными исполнениями. В PVC поле статуса определены следующие значения: Статус Значение ------ -------------------------------------- 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 пакетов установки; эти значения представляют особое исполнение которое было выбрано для определения значений в три группы, которые соответствуют короткому таймеру для попытки соединения (0x00 до 0x07), длинный таймер (0x08 до 0x0F) и нет попытки соединения (больше чем 0x0F). Значения которые предназначенны для PVC установочных пакетов это 0x00 и другие значения больше чем 0x12. Многие PVC статус значения ошибок, которые могут быть найденны в установочном сообщении ясны(самоочевидны), с некоторыми исключениями. Значение 0x17, "Ошибка конфигурации PVC назначения" может возвратиться в случае, когда PVC к которому идет соединение уже имеет активное XOT PVC соединение. Значение 0x19, "Не поддерживаемые значения контроля потока", может быть возвращенно когда значения контроля потока совпадают, но, в случае, интерфейса modulo 8, это запрос к установке PVC с размером окна больше чем 7, или интерфейс запрошен установить PVC с максимальным размером Forster, Satz, Glick & Day [Стр. 10] RFC 1613 X.25 по TCP (XOT) Май 1994 пакета слишком большим для транспортировки по этому data link слою. XOT МОЖЕТ повторить неудачную установку PVC; в этом случае XOT исполнению НУЖНО ждать между попытками (5 минут предлагаеться). Каждый XOT PVC сконфигурирован с идентификацией другого XOT (напр, IP адрес), имя интерфейса для соединения, LCN на этот интерфейс и значения контроля потока для использования. Эти данные представленны в PVC установочных пакетах и отвечающий XOT проверяет конфигурацию на совместимость. Поля с именем интерфейса это ASCII имена двух соединяющихся интерфейсов. Эти имена ПРЕДПОЛАГАЮТЬСЯ не чувствительными к регистру. Они НЕ ДОЛЖНЫ быть "многословными" или содержать нулевые байты между или после имен интерфейсов. Значения контроля потока это значения наилучшие для локального интерфейса, которые посылаються XOT в установочном пакете PVC. Значения максимального размера пакета закодированны в свойстве Размер Пакета, (то есть, base-2 log размера в октетах, также 7 представляет максимальный размер пакета 128 октетов). Если отвечающие XOT исполнение поддерживает "Конец-Конец" контроль потока, оно требует чтоб были настроенны значения контроля потока, в дополнении, также возвращаеться статус 0х18, что показывает значения требуемые отвечающему XOT(учтите что входящие значения одного локального интерфейса передаються в выходящих значениях соединененному локальному интерфейсу, и vice-versa). После установления TCP соединения Инициатор посылает PVC установочный пакет, значения статуса ДОЛЖНО быть 0x00; Ответчик должен ответить своим PVC установочным пакетом или закрыть TCP соединение. XOT PVC установка успешна, если ответчик возвращает статус 0x00. Если успешно установленно XOT PVC соединение, каждый XOT ДОЛЖЕН завершить Процедуру Сброса(Reset procedure) на локальном интерфейсе, также если каждый локальный интерфейс LCI в состоянии D1, Пакет Сброса(Reset packet) должен быть создан обоими, локальным интерфейсом и XOT TCP соединением. XOT PVC соединение разрываеться простым закрытием TCP соединения; X.25 пакеты которые неправильны для PVCs НЕ ДОЛЖНЫ быть переданны через XOT PVC соединения. Когда локальный интерфейс подвергаеться Restart процедуре, XOT PVC соединения ДОЛЖНЫ быть также Сброшены (Reset) (что происходит если интерфейс возвращаеться в состояние R1) или XOT PVC соединение закрыто. Forster, Satz, Glick & Day [Стр. 11] RFC 1613 X.25 по TCP (XOT) Май 1994 ДИССКУСИЯ XOT исполнение ДОЛЖНО также рассмотреть, как коллизия PVC установки будет обработана. Получение XOT PVC установки для PVC, который самостоятельно делает попытку к установке XOT связи, можно или принимать (допустимую) попытку установки и, если результат два TCP XOT подключения, просто используйте одно подключение, чтобы послать XOT данные (XOT, НЕ ДОЛЖЕН посылать трафик по обоим) и принимать XOT данные на другом, или это может закрывать входящую попытку и, если нет результатов подключений, повторять подключение после случайного интервала ожидания. Если два подключения позволяются для PVC, закрытие одного НЕОТВРАТИМО приводит к закрытию другого. 7. Согласования Greg Satz это настоящий разработчик и внедритель 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, July 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. Forster, Satz, Glick & Day [Стр. 12] RFC 1613 X.25 по TCP (XOT) Май 1994 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: forster@cisco.com 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: satz@cisco.com 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: gglick@cisco.com 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: R.Day@jnt.ac.uk Переведенно Free_Hunter-ом. найти меня можно на EFNet, #x25rus