RFC 1613 cisco Systems X.25 over TCP (XOT)

Перевод Игорь: Шеваров issh@onego.ru , 09.05.2003

Network Working Group Запрос на комментарий: 1613 Категория: информационный

J. Forster

G. Satz

G. Glick

cisco Systems, Inc.

R. Day

JANET

Май 1994

X.25 через TCP (XOT)

PDF

Статус данного документа

Данный документ предоставляет информацию для сообщества Internet. Этот документ не определяет стандарты Internet какого-либо вида. Распространение данного документа не ограничено.

Содержание

Исключено в версии HTML

1 Введение

В некоторых случаях необходимо транспортировать пакеты X.25 через IP сети. Пакетный уровень X.25 требует наличие надежного соединение канального уровня, который в большинстве случаев обеспечивает LAPB. Данный документ описывает метод пересылки пакетов X.25 через IP-сети с помощью инкапсуляции пакетного уровня X.25 в TCP пакеты.

ТСР предоставляет надежный байтовый поток. X. 25 требует, чтобы нижний уровень обеспечивал семантику сообщений, в частности граничу между пакетами. Для обеспечения такой возможности используется маленький заголовок ХОТ (4 байта), используемый для вставки меду пакетами ТСР и Х.25. Первичное содержание этого заголовка – поле длинны, которое используется для разделения пакетов в TCP потоке.

Вообще, обычно пакеты протокола Х.25 и правила передачи состояний (state transition rules) применяются к уровню Х.25 в ХОТ. Исключения будут специально отмечены.

2 Соглашения

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

  • ДОЛЖЕН или ОБЯЗАТЕЛЬНО – элемент абсолютных требований спецификации.
  • СЛЕДУЕТ или РЕКОМЕНДУЕТСЯ – элемент должен поддерживаться, за исключением особых обстоятельств.
  • МОЖЕТ или ОПЦИОНАЛЬНО – элемент является необязательным и может поддерживаться или быть пропущенным в каждой конкретной реализации.

Некоторые фрагменты этого документа могут быть помечены как «Пояснение». Эти фрагменты предназначены для того, что бы дать объяснение предшествующему тексту.

3 Отношения между Х.25 и ТСР.

Когда сетевое устройств (хост, маршрутизатор и т.п.) имеет ядро (engine) Х.25 (т.е. реализацию протокола), это ядро может быть присоединено к интерфейсу, работающему по LAPB, и/или к логическому интерфейсу работающему по LLC или XOT/TCP/IP. В общем, уровень ХОТ абсолютно не чувствителен к тому, какие типы пакетов Х.25 передает хост. Однако, чтобы повысить способность к взаимодействию между различными реализациями, данных документ в некоторых случаях определяет поведение ядра Х.25.

Стандарты Х.25 могут по-разному называть типы пакетов различными наименованиями в зависимости от того, какую роль выполняет интерфейс (DTE/DCE) от которого поступил пакет. ХОТ специально создан, чтобы быть нечувствительным к 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 пакет

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

4.1 Заголовок ХОТ.

Заголовок ХОТ имеет следующий формат:

 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 октета)

Номер версии протокола ХОТ кодируется двумя октетами. Номер версии ДОЛЖЕН быть 0. Другие значения поля зарезервированы для будущего использования. Если значение поля отличается от 0 ТСР соединение ДОЛЖНО быть закрыто.

Длина (2 октета)

Длина пакета Х.25 кодируется в двух вторых октетах. Значение должно быть длинной пакета. Если длина пакета имеет неправильное значение, ТСР соединение ДОЛЖНО быть закрыто.

5 ТСР соединение, номер порта и номер логического канала (LCN).

Для каждого виртуального соединения Х.25 ДОЛЖНО использоваться отдельное ТСР соединение. Все соединения ДОЛЖНЫ быть установлены на ТСР порт 1998. Этот порт зарегистрирован фирмой cisco Systems в IANA для использования ХОТ.

ТСР соединение ДОЛЖНО быть уставлено до того, как установлено виртуальное соединение. Виртуальное соединение может поддерживаться после того, как виртуальное соединение сброшено. Данные НЕ ДОЛЖНЫ передаваться с ТСР SYN пакетом.

Поле номера логического канала (Logical Channel Number – LCN) в заголовке Х.25 пакета не несет никакого значения и имеет произвольную величину. Как следствие, не важно, с какой стороны находится DTE или DCE.

ПОЯСНЕНИЕ

Рассмотрим три устройства А,В и С, где А и В связываются ХОТ сессиями с C. Возможно С может принять два вызова с одним LSN, если ядро протокола сможет разобраться, что пакеты получены с разных логических (ХОТ) интерфейсов. Здесь возникает опасность смешения вызовов (требуется правильное значение LCN на одном интерфейсе, которое может быть недопустимым на другом интерфейсе). Поэтому это необходимо для ядра протокола устройства С, чтобы проводить различие между двумя потоками, по чтобы сделать это, поля LCN не достаточно. The XOT protocol design decision was to expect the XOT layer to communicate the stream identification to the X.25 layer.

6 Пакеты ХОТ.

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

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

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

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

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

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

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

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

ПОЯСНЕНИЕ

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

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

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

6.2 Данные и контроль потока.

ПОЯСНЕНИЕ

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

Реализации ХОТ могут осуществлять как контроль потока точка-точка (end-to-end flow control), где пакеты DATA, RR и RNR посылаются через ТСР соединение так, как они получены с локального интерфейса, так и локальный контроль потока, где пакеты управления потоком (RR, RNR и если поддерживается REJ) посылаются по виртуальному соединению в соответствии с локальными критериями, законченная последовательность пакетов может быть фрагментирована или комбинирована, а нумерация пакетов данных может иметь локальное для DTE-DCE значение.

Существующие реализации ХОТ поддерживают контроль потока данных точка-точка. Данные и пакеты контроля потока данных просто пересылаются между двумя локальными интерфейсами по ТСР соединению, настраивая данные в заголовке Х.25 как требуется для работы со смешанным модулем (mixed modulo operation). Это не мешает реализации ХОТ осуществлять локальный контроль потока, но способность к взаимодействию требует, чтобы реализация ХОТ с локальным контролем потока выполняла сессию ХОТ таким образом, чтобы реализация ХОТ с контролем потока точка-точка могла принимать пакеты данных правильного размера и чтобы значения полей управления потоком данных принимали соответствующие значения P(S) и P(R).

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

Реализация XOT, которая осуществляет локальное управление потоком данных, ДОЛЖНА послать подтверждения пакетов данных через соединение TCP для пакетов DATA, которые она принимает через соединение TCP, используя полученные номера пакетов, и ДОЛЖНО соблюдать максимальные размеры пакета согласованные для подключения TCP.

Реализация ХОТ, НЕ ДОЛЖНА предполагать, что пакет RNR посланный через соединение ТСР будет останавливать поток пакетов DATA, идущих в другом направлении через соединение ТСР. Пакет RNR, полученный через соединение ТСР МОЖЕТ стать причиной для посылки пакета RNR через локальный интерфейс. Реализации ХОТ, использующие контроль за потоком данных точка-точка МОГУТ взаимодействовать через значения P(R) в пакеты RNR, полученные через соединение ТСР, посылая пакет RR в локальный интерфейс.

Реализации ХОТ, которые поддерживают соединения с разными модулями (mixed-modulo connections) и реализуют контроль за потоком данных точка-точка ДОЛЖНЫ вмешиваться в процесс установления размера окна, когда Call Request предполагает модуль 128 и размер окна 8 или больше на любом соединении ХОТ, которое обслуживает интерфейс с модулем 8. Это вмешательство должно состоять или в отказе на соединение или в понижении слишком большого размера окна до допустимого для интерфейса размера и указании конечного результата выбора размера окна в пакете Call Confirm, возвращаемого через ТСР соединение.

Для любых типов реализаций управления потоком, поддерживающих mixed modulo connections, оба взаимодействующие ХОТа ДОЛЖНЫ интерпретировать значения P(S) и P(R) полученные через ТСР соединение и выполнять любые операции по управлению потоком для обеспечения правильного функционирования протокола Х.25 на локальном интерфейсе. Реализации управления потоком точка-точка ДОЛЖНЫ выполнять преобразования между двумя модулями и создавать поля P(S) P(R) в аналогичные заголовках пакетов Х.25 DATA, RR и RNR.

Любая реализация ХОТ МОЖЕТ поддерживать две ХОТ ТСР сессии между собой. Если эта особенность поддерживается, ХОТ ДОЛЖЕН просто устанавливать две ТСР сессии без модификации переданных данных.

6.3 Пакеты Interrupt и Reset

Пакеты Interrupt, Interrupt Confirm, Reset и Reset Confirm передаются через ТСР соединение с использованием нормального формата пакетов Х.25 и изменения состояний (state transitions). Непрерывная природа сервисов Interrupt и Reset ДОЛЖНА поддерживаться для правильного функционирования Х.25.

6.4 Пакеты Restart, DTE Reject, Diagnostics, и Registration

Пакеты Х.25, которые имеют только локальное значение для интерфейса (Restart, DTE Reject, Diagnostics, и Registration) НЕ ДОЛЖНЫ передаваться через соединение ТСР. Если эти пакеты получены, то они ДОЛЖНЫ быть проигнорированы.

6.5 Установка PVC

Любая реализация ХОТ МОЖЕТ поддерживать установления PVC через ХОТ.

ПОЯСНЕНИЕ

PVC Х.25 являются виртуальными соединениями. Предполагается, что они должны быть доступны, когда доступен сервис Х.25 (то есть в состоянии R1). Установление PVC через ХОТ осложняется из-за отсутствия пакетов Call, Call Confirm, Clear или Clear Confirm которые передаются через Х.25 интерфейс – PVC просто доступны потому что они были созданы сетевым провайдером по договоренности с пользователями.

Поддержка PVC с использованием ХОТ требует от объектов ХОТ обмена данными не описанного стандартами Х.25 и должен поддерживаться ряд аварийных ситуаций.

Установка PVC между двумя объектами ХОТ выполняется с использованием обмена нестандартными пакетами Х.25 (инкапсулированными в заголовок ХОТ). Процесс обмена данными для установления PVC начинается сразу после установления сессии ТСР. Объект ХОТ установивший ТСР соединение называется инициатором, второй респондером.

Пакет 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 для того, чтобы отличаться от стандартных идентификаторов типов пакетов Х.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 Интерфейс назначения не поддерживает Х.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 назначения уже имеет активное соединение ХОТ PVC. Значение 0x19 «Неподдерживаемые значения параметров управления потоком» может быть возвращено в случае, когда значения управления потоком совпадают, но например, интерфейсом запрошен модуль 8 для установления PVC с размером окна более 7 или интерфейсом запрошено установление PVC с максимальным размером пакета размером пакета слишком большим для канального уровня.

ХОТ МОЖЕТ повторить неудачное установление PVC, если это реализовано, ХОТ ДОЛЖЕН сделать паузу между попытками (предлагается 5 мин.)

Каждое PVC на ХОТ конфигурируется идентично другому ХОТ (т.е. IP адрес, имя интерфейса для соединения, номер логического канала, значения параметров управления потоком). Данные представленные в пакете PVC setup проверяются удаленным ХОТ и подтверждаются как совместимые.

Поля имен интерфейсов являются ASCII именами двух интересов. Этим именам СЛЕДУЕТ быть не чувствительными к регистру и НЕ ДОЛЖНЫ содержать дополняющих или конечных нулевых октетов между или перед именами интерфейсов.

Значения управления потоком данных – это значения, которые зависят от локального интерфейса, реализации ХОТ, которая послала пакет PVC setup. Значение максимального размера пакета кодируется как в пакете size facility (т.е. два в степени размер пакета в октетах, так что значение 7 представляет собой максимальный размер пакета в 128 октетов). Если отвечающий ХОТ осуществляет управление потоком данных точка-точка, то он будет требовать совместимые значения управления потоком данных, так что возвращенный статус 0x18 будет индицировать значения, требуемые для отвечающего ХОТ (заметим, что входящее значение на одном локальном интерфейсе соответствует исходящему значению на подсоединенном к нему интерфейсу и наоборот).

После установления ТСР соединения, инициатор посылает пакет PVC setup, где значение статуса ДОЛЖНО быть 0x00, респондер будет отвечать ему своим пакетом PVC setup или закроет ТСР соединение. PVC ХОТ считается успешным, если респондер вернет статус 0x00. Однажды установленное соединение PVC ХОТ МОЖЕТ быть завершено процедурой Reset на локальном интерфейсе, так что если локальный интерфейс LCI в состоянии D1, пакет Reset может быть сгенерирован на обоих интерфейсах: на локальном и на интерфейсе ХОТ ТСР.

Соединение ХОТ PVC может быть прервано простым закрытием ТСР соединения. Пакеты Х.25, которые не являются правильными для PVC НЕ ДОЛЖНЫ передаваться через ХОТ PVC соединение. Когда локальный интерфейс подвергается процедуре Restart, XOT PVC соединение должно выполнить Reset или закрыть XOT PVC соединение.

ПОЯСНЕНИЕ

Реализации ХОТ СЛЕДУЕТ решить, как будет обрабатываться коллизия попыток установления соединения. Получение XOT PVC setup для PVC, которое само делает попытку к установке ХОТ соединения, может принять попытку установить соединение, и если ТСР ХОТ в результате просто использует одно соединение для посылки данных ХОТ (ХОТ НЕ ДОЛЖЕН посылать трафик через оба) и принимает трафик на другом, или может закрыть входящую попытку или может повторить попытку соединения через случайный промежуток времени. Если два соединения позволены для PVC, то при закрытии одного СЛЕДУЕТ закрыть другое.

7 Подтверждения

Грег Сатз (Greg Satz) –первоначальный проектировщик и implementor Х.25 через ТСР. Авива Гаретт (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.

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

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.