Сети имеют глобальный характер и реализованы на коммутации пакетов между последними узлами. Сети х.25 работают на трех нижних уровнях модели OSI. Структура сети показана на рис.1, где видно:

  • DCE — телекоммуникационное оборудование (модемы), реализующие доступ к сети
  • DTE — аппаратура транспортировки данных
  • PSE — коммутаторы пакетов, реализующие облако глобальной сети

Для терминалов, которые не поддерживают X.25 полностью, есть простые устройства PAD — сборщики разборщики пакетов. Они содержат один или более асинхронных портов, к которые присоединяются обычные терминалы и один синхронный порт х.25. Весь трафик их асинхронных портов собирается в буфер памяти PAD и по заполнению пакета он отправляется в сеть. Разборка реализована таким же образом.

Физический уровень определяет использование любого родственного последовательного синхронного интерфейса: и G.703. Для реализации таких интерфейсов нужно что бы цепи, DTR,RTS,DSR,CTS были в положении включено , иначе работать не будут. На физическом уровне нету контроля управления и достоверности потоком — эти задачи реализуются сетевым и канальным уровнем.

Канальный уровень реализует гарантированную доставку, контроль потока и целостность данных, при этом задержка всего лишь сотни миллисекунд. Протокол LAP-B реализует канальный уровень. Связь реализуется между парой устройств DTE по запросу инициатора. После установки соединения пара может вести полнодуплексный обмен данными. Логическое соединение, которое поддерживает надежных двухсторонний обмен между парой устройств называют виртуальной цепью . Физическая виртуальная цепь может проходить через несколько PSE. Виртуальные цепи могут быть постоянные и коммутируемые. Коммутируемые виртуальные цепи SVC — используются для нерегулярного обмена информацией и нуждаются в поддержании, установки и завершении сеанса каждый раз при нужды в сеансе. Постоянные виртуальные цепи PVC — не нуждаются в установки сеанса, и DTE может обмениваться данными в любой момент.

Сетевой уровень Х.25 реализуется с помощью протокола PLP. Этот протокол управляет обменом кадрами через виртуальные цепи. Пакеты PLP ложатся в поле данных кадра LAPB. Протокол PLP может работать и через LLC2, ISDN (LAPD) и он определяет 5 режимов:

  • Call setup — установка соединения, реализуется для организации коммутируемой виртуальной цепи между DTEб реализуя адресацию х.121. Режим относится к каждой виртуальное цепи, которое подключено через физическое соединение
  • Data-transfer mode — Режим транспортировки информации реализуется при обмене информацией через виртуальные сети. Этот режим выполняет сегментацию, заполнение недостающих бит, управление потоком и контроль ошибок. Используется и PVC и SVC
  • Idle mode — режим паузы, нужен тогда, когда виртуальная коммутируемая цепь уже установлена, но обмен информацией не происходит. Для PVC не нужен
  • Call-clearing mode — сброс соединения, нужен для разрыва сеанса
  • Restarting mode — режим рестарта, нужен для синхронизации транспортировки между локальным DCE и DTE.

Поле данных в пакете может иметь длину до 4096 байт (стандарт — 128). Адресация узлов DTE реализуется относительно х.121, что дает единое пространство адресов на земле. Есть 3 варианта адресации:

  • Полный международный телефонный номер: адрес начинается с префикса 9, за которым идет трехзначный код страны, а затем телефонный номер в стране (11 цифр)
  • Полный международный сетевой адрес: начинается с префикса 0, после которого идет трехзначный код страны а затем номер сети в стране и номер узла
  • Внутренний сетевой адрес: начинается с номера сети в стране, а потом идет номер узла

Сети х.25 отлично применяются для обмена данными между пользователями, подключения терминальных узлов, построение систем клиент-сервер. Протокол х.25 поддерживают разные маршрутизаторы и мосты. Протокол стандартизирован и четко вписывается в модель OSI. Недостатком такой сети является то, что присутствует значительная задержка передачи пакетов.

Уважаемые хабровчане, я хочу рассказать вам о сетях пакетной коммутации, построенных на основе протокола передачи данных ITU-T X.25. Мне посчастливилось заниматься сопровождением и развитием одной корпоративной сети X.25 на протяжении нескольких лет.

Протокол X.25

Протокол X.25 был разработан на смену протоколу ISDN, который для передачи данных обладает существенными недостатками (отсутсвие статистического мультиплексирования). Первая редакция стандарта была утверждена в 1976 году. В основу протокла легли следующие основные идеи:
- Контроль передачи между двумя узлами сети
- Контроль передачи между конечными абонентами
- Маршрутизация в момент установления соединения
- Коммутация пакетов по установленному маршруту

Во многих источниках говорится, что X.25 - протокол канального уровня. Это не так. X.25 создавался до разработки семиуровневой модели OSI. В канальный уровень его «записывают» только из-за широко применяемой инкапсуляции протокола IP в X.25. На самом деле протокол имеет все признаки сетевого уровня (маршрутизация между сетями) и обеспечивает контроль передачи между конечными абонентами, т.е. выходит транспортный уровень.

Основным преимуществом протокола является высокая эффективность в сетях, построенных на каналах связи с высоким уровнем ошибок. Основными недостатками - ограниченная производительность, не приспособленность к передаче real time данных.

Сеть X.25

Все абоненты сети X.25 делятся на синхронных и асинхронных. Синхронные имеют встроенные интерфейсы X.25, а асинхронные для передачи данных используют устройства под названием PAD (Packet Assembler-Disassembler). PAD принимает асинхронные потоки со своих портов и передает их в коммутируемом соединении через интерфейс X.25.

Основу сети составляют пакетные коммутаторы. Они соединяются между собой синхронными каналами связи (преимущественно X.21 через синхронные модемы по каналам ТЧ или радиоканалам). Синхронные абоненты сети подключаются непосредственно к пакетным коммутаторам. Также к коммутаторам подключаются PADы.

В сети используется адресация по стандарту X.121. Она чем-то напоминает IP адресацию, но без точек и с десятичной маской. Маска в явном виде никогда не указывается, просто длина адреса может варьироваться от 10 до 15 десятичных символов.

Адрес X.121 имеет вид:
DDDDNNNPPPP
где
DDDD - DNIC (Номер сети, аналог автономной системы в IP)
NNN - Node (Номер узла)
PPPP - Port (Номер порта)
SSSSS - Subadress (Субадрес)

Каждый пакетный коммутатор имеет свою таблицу маршрутизации. Таблица указывает в какой порт маршрутизировать соединение, осуществляемое на указанный адрес. Адрес отправителя обычно не анализируется.

Важный момент - маршрутизация происходит в момент установления логического соединения (SVC), после установления соединения происходит только коммутация. Для этого на каждом порту создаются логические каналы (LCI). Количество доступных LCI на интерфейсе ограничивает доступное количество логических соединений через него.

Если на маршруте установленного соединения произойдет сбой, то после таймаута и переповторов абоненты переустановят соединение.

Сеть, с которой мне пришлось иметь дело, вначале использовалась для работы асинхронных терминалов, которые по zmodem осуществляли передачу файлов на файловый коммутатор («вертушка»). Позже появились синхронные терминалы, обменивающиеся информацией с сервером и маршрутизаторы IP. Все работало очень медленно и очень надежно. Скорость на магистральных каналах ТЧ была не выше 19200, а в глубинке было и по 2400 «за счастье», что не мешало передавать данные.

Позже стали появляться каналы FR, которые использовались для X.25 over FR. Когда появились качественные каналы IP, постепенно начали внедрять XOT (X.25 over IP).

Важный момент - обе технологии предполагают туннелирование X.25 через неродные для него протоколы. Иногда удобно «затерминировать» протокол X.25 на интерфейсе, на который он приходит через туннель. Протокл этого не предусматривает, терминирование протокола возможно только на интерфейсах с чистым X.25 (over LAP-B), а туннелирование можно применять только внутри сети для коммутации между узлами.

Case Communications

Сеть, с которой я работал, была построена на оборудовании английской компании Case Communications . Эта компания часто меняла собственников и названия, в одно время называлась Cray Communications. Начинали они с пакетных коммутаторов, также у них были и Ethernet продкуты, маршрутизаторы. Подразделение, которое производило маршрутизаторы было выкуплено Intel, в результате чего появились достаточно известные модели Intel Express Router 9100 и иже с ним. В настоящее время компания занимается разработкой и производством linux маршрутизатров.

Линейка пакетных коммутаторов Case состояла из узлов (Packet Switch Exchange - PSE), коммутаторов X.25/Frame-Relay Assembler-Disassembler - XFRAD) и PAD. Особенность PSE была в том, что между ними можно было делать транковые соединения, которые не адресовались как обычные порты, но использовались для связи между узлами сети. С сетью поставлялась система управления на платформе Sun с графическим интерфейсом под Х11.

Самой продвинутой моделью был модульный PSE8525. Это 13 юнитовое шасси для стойки 19" на 16 модулей интерфейсов и модуль управления, в шасси устанавливалось до 5 блоков питания. Архитектура этой штуковины заслуживает особого внимания.

Основой являлась вертикальная плата backplane. Активных элементов на ней обнаружено не было (!) - просто набор шин. Backplane делила шасси на две части - спереди платы с контроллерами и процессорами, сзади - платы с интерфейсами, всего 17 слотов. В первые 16 слотов можно было установить платы портов X.25 или платы PAD. В последнем слоте - плата manager.

Все остальные платы состояли из двух частей - платы контроллеров и платы процессора. Процессорные платы (UPM) были для всех плат одинаковые, контроллер портов X.25 (SP-XIM) и менеджер были разными.

Система загружалась поэтапно. После включения питания с дискеты А загружался менеджер. После загрузки он считывал конфигурацию с дискеты В и по одной загружал платы интерфейсов. PADы загружались сами по себе, как только появлялось питание. После загрузки всех плат, они могли работать независимо, каждую из них можно было перезагружать отдельно. Менеджер в системе был нужен только при изменении конфигурации или перезагрузке.

Все платы можно было вынимать и переустанавливать «на ходу». Известны случаи, когда шасси работало без менеджера более месяца. Сравните это с вытаскиванием супервизора из Cisco7600! ;)

Заключение

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

Развитие систем связи привело к тому, что протокол X.25 перестал удовлетворять требованиям современных приложений к скорости передачи данных, а наличие высокоскоростных каналов связи с низким уровнем ошибок позволяет решать современные задачи с помощью протоколов семейства TCP/IP.

Основы, заложенные в архитектуру протокола и сетей X.25 иллюстрируют рациональный подход к решению поставленной задачи, и являются отличным учебным материалом. Возможно, некоторые из идей, заложенных в X.25, еще вернутся но на более высоких уровнях. В частности, технология MPLS TE (Traffic Engineering) в чем-то сходна с X.25 в отношении построения логических каналов.

Я рекомендую всем, кто собирается стать специалистом в области сетей и коммуникаций, изучить основы работы протокола X.25, не смотря на то, что его знание не является обязательным для работы во многих предприятиях связи. При его изучении, рекомендую делать акцент не на том, как реализована та или иная функция, а на том, с какой целью, она была включена в протокол.