Для начала немного лирики. Уж не знаю почему, но к Frame Relay я всегда имел какие-то теплые чувства (если их вообще можно иметь к протоколу передачи данных... коллеги меня поймут, надеюсь). Впервые я узнал о нем давным давно, когда ещё готовился к CCNA. Тогда Frame Relay произвел на меня достаточно большое впечатление, хотя бы потому что это был не Ethernet. Это было что-то новое, что я не знал тогда. С тех пор, я почти не видел его имплементаций в жизни. Зато в цисковских экзаменах его до недавнего времени было просто завались... Давайте попробуем разобраться, что же в нем такого...

Причины возникновения

После лирики самое время перейти к истории. Frame Relay появился в эру ISDN. Возникла надобность как-то организовать передачу данных по сети, для этого изначально была и разработана технология Frame Relay. Довольно редко встречающаяся в наши дни технология, однако не так уж редкая, как многие думают. Основным применением технологии был, так называемый, корпоративный сектор. В то время, для обеспечения канала связи между двумя офисами, применялись point-to-point serial линки. Штука простая и удобная, но не масштабируемая. Если нам нужно соединить 3 устройства через ISDN сеть, от каждого устройства понадобится прокладывать два serial линка. А если устройств 100?.. Эту проблему был призван решить Frame Relay. Он способен объединить все эти офисы чуть более эффективным методом. Понадобится всего один линк для соединения каждого устройства с Frame Relay облаком. Картина ниже иллюстрирует подход.

Frame Relay - это NBMA (non-broadcast multiple access ) сеть. Это означает, что одно устройство в сети может взаимодействовать с множеством других, но делается это не средствами посылки broadrcast сообщений. В этом основной прикол Frame Relay, который накладывает отпечаток на многие аспекты связанные с этим протоколом. Например, работа протоколов маршрутизации через такую сеть имеет некоторые особенности.

Frame Relay - работает на втором уровне OSI, поверх которого можно передавать множество L3 технологий. Конечно же, основная из них - IP. Именно про IP over Frame Relay и пойдет речь дальше.

Frame Relay вводит пару терминов, которые особой сложности не несут, но иногда могут завести в заблуждение.

• DTE (data terminal equipment) - оборудование, которое использует сервис Frame Relay. По сути это CPE.

• DCE (data circuit-terminating equipment ) - оборудование, которое предоставляет сервис Frame Relay. Это Frame Relay Switch, который стоит на стороне провайдера.

Базовый принцип

Итак, теперь когда мы более или менее определились что такое Frame Relay, пора глянуть на то как он работает. Если говорить в терминах Frame Relay, то на схеме ниже у нас три устройства, которые подключены к Frame Relay облаку. Это DTE1, DTE2 и DTE3. Каждое их этих устройств подключено к провайдерскому устройству (DCE), которых на схеме тоже три.

Так же на схеме можно заметить некие VC . Их тут три и это основополагающий концепт во Frame Relay. Устройства в сети Frame Relay соединенны средствами Virtual Circuit , которые прокладываются поверх физических линков. Так, к примеру, DTE1 подключено к DTE2 и DTE3 двумя такими секитами, VC12 и VC31 соответственно.
Строго говоря, VC бывают двух типов:

• SVC (Switched Virtual Circuit)- такой канал сигнализируется DTE каждый раз, когда нужно передать данные.

• PVC (Permanent Virtual Circuit) - этот тип секита всегда присутствует в сети и настроен на узлах. DTE к нему всего лишь подключаются, но не сигнализируют.

В любом случае, каждый такой секит определяется с помощью DLCI (Data-link connection identifier). DLCI в сетях Frame Relay это что-то вроде MAC адреса в Ethernet, но не совсем. Это некий L2 идентификатор в сети. Но, в отличие от MAC, DLCI это локальное значение, которое должно быть уникально только в пределах линка. Если посмотреть на картинку выше, то вполне нормально использовать один DLCI на все устройства. Но обычно используется другой подход, который называется Global Addressing. В таком случае, DLCI уникален в пределах сети. Так привычней и проще.

Перейдем к тому как кадры передаются через такую сеть. Допустим, устройство DTE1 (192.168.0.1/24) хочет отправить какие-то данные устройству DTE2 с адресом 192.168.0.2/24.

1. Роутер DTE1 инкапсулирует IP пакет в Frame Relay кадр, вставляет DLCI=102 в заголовок и отправляет получившийся сверток в сторону DTE2.
2. В нашем случае, кадр попадает на DCE1. Внутри Frame Relay облака, перво наперво, проверяется заголовок Frame Relay, там находится идентификатор DLCI=102, это это часть секита VC12, DLCI в кадре меняется на 101 и отправляется в сторону DTE2.
3. DTE2 так же смотрит заголовок Frame Relay, находит там DLCI 101 по которому он понимает, что данные пришли от DTE1. Далее заголовок отбрасывается и начинается работа с IP пакетом.

LMI (Local Management Interface)

Для взаимодействия между DTE и DCE существует специальный протокол LMI, который в сетях Frame Relay выполняет две важные функции.

1. Keepalive. Если от соседа не приходит никаких сообщений, то такой линк считается умершим. Обычно это 3 не пришедших сообщения, интервал между которыми равен 10 секунд.
2. Сигнализация состояния. Как только роутер (DTE) появляется в сети, он шлет сообщение LMI Status Enquiry в сторону DCE. Тот отвечает ему сообщением LMI Status , в котором рассказывает какие DLCI сейчас настроены на этом VC и в каком они статусе.

Таким образом, после настройки линка наш DTE автоматически узнает о том, какие DLCI используются . Проблема только в том, что мы не знаем какой IP какому DLCI соответсвует . "ARP" - воскликнет читатель. "Почти" - отвечу я.

Inverse ARP

После того, как мы подключили устройство к сети Frame Relay, ближайший свитч расскажет нам какие DLCI настроены в канале. Для того, чтобы узнать какие L3 адреса (IP, короче говоря) за ними сидят нам нужно что-то вроде ARP в Ethernet, но наоборот. В Ethernet мы знаем L3, но не знаем какой MAC, т.е. L2 адрес, ему соответствует. Тут же мы знаем L2 адрес (DLCI), а вот IP нет.

Как только наш роутер DTE получит сообщение LMI Status с перечислением DLCI, он сразу же отправит Inverse ARP сообщение в сеть, в котором расскажет свой DLCI и свой L3 адрес. Таким образом, другие участники сети узнают, с каким DLCI нужно слать кадры для достижения этого роутера .

Конечно, Inverse ARP можно отключить, отключив LMI, кстати говоря. В таком случае, всю настройку вы берете на себя. Нужно статически настроить DLCI на интерфейсах и записать каким DLCI на удаленных сторонах сети какие адреса соответсвуют.

Топологии

Стоит пару слов сказать про L3. Вы вольны как угодно строить дизайн L3 поверх Frame Relay облака. Можно одну подсеть "размазать" по всей сети, что я и сделал в своем примере (картинка ниже слева). Можно использовать логику точка-точка и на каждый VC выделить свою подсеть (справа).

Тип интерфейса

От типа интерфейса зависит то, как себя будет вести Frame Relay, и как будут вести себя протоколы динамической маршрутизации поверх него, кстати говоря. Сейчас рассмотрим немного исковерканную топологию из моего примера, у которой по какой-то причине убрали один линк между DTE1 и DTE3.

Для примера возьмем Cisco, где нам предлагаетя возможность настроить Frame Relay на:

• Физическом интерфейсе . Хороший вариант, но не очень масштабируемый. В нашем примере выше, всю топологию можно настроить на физических интерфейсах. Прописываем инкапсуляцию frame-relay и IP адрес, всю остальную работу за нас сделают LMI и InARP. А вот если бы мы выбрали для реализации подход с предыдущего рисунка, когда для каждого VC нам понадобилась бы своя подсеть, настроить Frame Relay на физическом уровне уже не получится. Нужно было бы прописать две подсети на один физический интерфейс.
• Сабинтерфейсе . Можно сказать, что это Best Practises. Но в таком случае, нам нужно выбрать тип интерфейса, коих у нас два:
• Point-to-Point . В таком случае, InverseARP нам не нужен, потому как сама логика PtP предполагает, что на другом конце только одно устройство. Роутер просто считает, что вся подсеть, которая прописана на локалном интерфейсе доступна через DLCI соседа. Например, если настроить VC12 как PtP сабинтерфейс на DTE1, то роутер просто решит, что вся подсеть 192.168.0.0/24 доступна через VC12 и слать трафик в неё нужно с DLCI 102. Такой DLCI рассказал нам DTE2 на другом конце средствами LMI. Напомню, InverseARP для маппинга L2 в L3 не используется в таком случае. Для нашего примера, линк на DTE3 тоже можно настроить как PtP.
• Multipoint . А вот на DTE2 такая логика неприменима, ведь через один линк должно ходить несколько VC. В нашем случае, здесь потребуется настроить multipoint сабинтерфейс.

Если прикинуть, как будет ходить трафик в такой топологии, то получится примерно следующее. Допустим, в облаке уже все настроено и вы включили свои настроенные устройства.

1. Первым делом отправится LMI Status Enquiry в сторону свичей в облаке.
2. Свичи ответят нашим DTE сообщением LMI Status какие DLCI настроены в VC. А именно, DTE1 и DTE3 узнают про DLCI 102, который принадлежит DTE2. DTE2 узнает про DLCI 101 и 102, которые принадлежат DTE1 и DTE2 соотвествнно.
3. Как только придет LMI Status на наши DTE, они отправят InARP сообщения. DTE1 расскажет, что его IP 192.168.0.1/24 и DLCI 101. DTE2 расскажет соседям, что его аддрес 192.168.0.2/24 и DLCI 102. DTE3 тоже всё всем расскажет.
4. Когда на DTE1 появится интерсующий нас трафик для отправки в сторону DTE3, он просто возьмет IP пакет, завернет его в Frame Relay кадр, запишет в него DLCI 102 . Смотреть на InARP он не будет, он просто знает, что все из сети 192.168.0.0/24 нужно отправлять с DLCI 102. Почему? Потому что у нас натсроен point-to-point интерфейс.
5. Пройдя через Frame Relay облако, наш заголовок трансформируется и уже будет иметь DLCI 101 .
6. Такой вот кадр с DLCI 101 и придет на DTE2. DTE2 поймет, что трафик этот не предназначается ему, потому что у него нет нужного IP на интерфейсах. Он взглянет на свой маппинг, который он составил по результатам LMI и InARP и поймет, что трафик этот предназначается DTE3 и должен быть отправлен в его сторону с DLCI 103.
7. DTE2 инкапсулирует трафик в новый FR заголовок и ставит в него DLCI 103 .
8. По пути DLCI в заголовоке опять магическим образом поменяется с 103 на 102 .
9. Наконец-то DTE3 получил трафик, отбросил заголовок второго уровня (Frame relay), глянул в L3 заголовок (IP) и понял, что это для него. Далее трафик будет каким-либо образом обработан.
10. В случае, если DTE3 сформирует какой-то ответный трафик в сторону DTE1, ситуация повторится с пункта 1, но в обратном направлении.

Для наглядности я накидал UML диаграммку, зря я что ли писал как это делать в своем посте про UML ?..

На картинке выше изображен первый случай .

• DTE1 отправляет некий трафик обернутый заголовком Frame Relay, в котором помимо DLCI находятся два бита - FECN и BECN. Роутер DTE1 отправляет их равными нулю, потому что он ни про какие перегрузки в канале не знает (ещё пока).

• DCE1 получает трафик и обрабатывает его, все как обычно. Однако он замечает, что в линке до DCE2 есть заторчик. Он запоминает VC, в котором к нему пришли данные и ставит бит FECN равным 1 в заголовке кадра в сторону соседа DCE2. Что означает, что в канале произошла перегрузка. Делает он это, по сути, в надежде, что кто-то на него-таки взглянет. Спойлер - не в этот раз...

• Кадр приходит на DCE2. Для него это самый обычный трафик, который он отправляет на DTE2.

• DTE2, получив трафик, начинает его как-то обрабатывать и, скорее всего, шлет некий обратный трафик. Он в этом примере про перегрузку канала ничего не знает, поэтому в его обратном кадре FECN и BECN тоже нулевые.

• Когда DCE1 получит такой трафик, он узнает VC и поставит бит BECN равный 1, для того, чтобы сказать источнику трафика (DTE1), что на канале есть проблемы и ему надо немного охладить свой пыл.

Втором примере на картинке выше.

В этом случае, DTE2 настроен на реакцию на бит FECN и сам проставит BECN = 1, для того чтобы уведомить DTE1 о перегрузке. DCE1 в этом случае ничего менять не будет. В этот раз, DCE1 не зря ставил FECN = 1, все таки хоть кому-то он пригодился и DTE2 взглянул на него.

FECN бит в нормальном сети меняют только DCE, а вот BECN могут менять как DCE, так и DTE.

Зачем же нужен бит DE ? Когда обнаружиться перегрузка, на DCE, рано или поздно, переполнится очередь на отправку и он будет вынужден начать процесс сбрасывания кадров с её конца. Он понятия не имеет какой трафик важный, а какой нет. Но ему можно попытаться рассказать об этом... Есть возможность помечать некий "неважный" трафик при отправке с DTE битом DE. В этом случае, наши свитчи в ядре (DCE) смогут понять какой трафик стоит отбрасывать в первую очередь, инспектируя значение этого бита в заголовке Frame Relay.

Наверное, пока хватит. Наконец-то я описал Frame Relay в своем блоге. Теперь я буду спать спокойно.

Как бы "залабить" все это?..

Сети Х.25 являются на сегодняшний день самыми популярными сетями с коммутацией пакетов в основном из-за того, что долгое время они были единственными доступными сетями такого типа, а также из-за того, что они хорошо работают на ненадежных линиях. Стандарт X.25 "Интерфейс между оконечным оборудованием данных и аппаратурой передачи данных для терминалов, работающих в пакетном режиме в сетях передачи данных общего пользования" был разработан комитетом МККТТ для предоставления терминалам доступа к многочисленным удаленным мейнфреймам через сеть коммутации пакетов. Поэтому этот стандарт наилучшим образом подходит для передачи трафика низкой интенсивности, характерного для терминалов, и в меньшей степени соответствует более высоким требованиям трафика локальных сетей.

Сеть коммутации пакетов состоит из центров коммутации пакетов (ЦКП), расположенных в различных географических точках и соединенных высокоскоростными каналами обмена (рисунок 17.7).

Рис. 17.7. Сеть коммутации пакетов X. 25

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

Этот стандарт основан на синхронной передаче данных. Асинхронные старт-стопные терминалы подключаются к сети через так называемые пакетные адаптеры данных (ПАД). Они могут быть встроенными или удаленными. Встроенный ПАД обычно расположен в стойке ЦКП. Удаленный ПАД представляет собой небольшое автономное устройство, подключенное к ЦКП через один канал связи X.25. Один ПАД обычно обеспечивает доступ для 8, 16 или 24 асинхронных терминалов.

К основным функциям ПАД относятся:

Сборка символов, полученных от асинхронных терминалов, в пакеты,

Разборка полей данных в пакетах и вывод данных на асинхронные терминалы,

Управление процедурами установления соединения и разъединения, сброса и прерывания,

Передача символов, включающих стартстопные сигналы и биты проверки на четность. по требованию асинхронного терминала,

Продвижение пакетов при наличии соответствующих условий, таких как заполнение пакета, истечение времени ожидания и др.

На физическом уровне определены протоколы X.21 и X.21bis. Протокол физического уровня X.21 определяет интерфейс между компьютером и цифровым каналом связи, а X.21bis - между компьютером и аналоговым каналом (с использованием модемов).

На канальном уровне используется подмножество протокола HDLC. обеспечивающее возможность автоматической передачи в случае возникновения ошибок в линии. Предусмотрена возможность выбора из двух процедур доступа к каналу: LAP или LAPB.

На сетевом уровне определен протокол X.25/3 обмена пакетами между оконечным оборудованием и сетью передачи данных.

Сетевой уровень реализуется с использованием 14 различных типов пакетов. Так как надежную передачу данных обеспечивает уже упомянутый протокол LAP-B, то протокол X.25/3 выполняет функции маршрутизации пакетов и управления потоком пакетов.

Прежде, чем пакет будет передан через сеть, необходимо установить соединение между исходными ООД - терминалами и компьютерами. Существует два типа соединений - коммутируемый виртуальный канал (SVC - Switched Virtual Channel) и постоянный виртуальный канал (PVC - Permament Virual Channel). SVC можно сравнить с коммутируемым каналом телефонной сети общего пользования. Для установления соединения необходимо знать сетевой номер - адрес пользователя. Рекомендация X. 121 МККТТ определяет международную систему нумерации адресов для сетей передачи данных общего пользования.

Постоянный виртуальный канал подобен выделенному каналу в том, что не требуется устанавливать соединение или разъединение. Обмен пакетами по PVC может происходить в любой момент времени. PVC формируется системой управления сетью. Отличие PVC от выделенной линии типа 64 Кб/с в том, что пользователь не имеет никаких гарантий относительно действительной пропускной способности PVC. Поэтому использование PVC обычно намного дешевле, чем аренда выделенной линии.

Маршрутизация на основе виртуальных каналов - это обычный прием, используемый в глобальных сетях. Кроме сетей X.25, такая техника применяется в сетях frame relay и АТМ. Суть такой маршрутизации показана на рисунке 17.8. При установлении соединения между конечными узлами используется специальный тип пакета - запрос на установление соединения - который содержит длинный адрес узла-адресата, а также номер виртуального соединения, присвоенного данному виртуальному соединению в узле-отправителе, например, 15. Адрес назначения используется для маршрутизации пакета на основании таблиц маршрутизации, аналогичных тем, которые использовались при описании протоколов RIP или OSPF. В приведенном примере оказалось необходимым передать пакет с порта 1 на порт 0. Одновременно с передачей пакета маршрутизатор изменяет у пакета номер виртуального соединения - он присваивает пакету первый неиспользованный номер виртуального канала для данного коммутатора. Каждый конечный узел и каждый коммутатор ведет свой список использованных и свободных номеров виртуальных соединений. В таблице коммутации входного порта маршрутизатор отмечает, что в дальнейшем пакеты, прибывшие на этот порт с номером 15, должны передаваться на порт 0, причем номер виртуального канала должен быть изменен на 10, Одновременно делается и соответствующая запись в таблице коммутации порта 0 - пакеты с номером 10 нужно передавать на порт с номером 1, меняя номер виртуального канала на 15.

Рис. 17.8. Коммутация в сетях с виртуальными соединениями.

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

За уменьшение служебного заголовка приходится платить невозможностью баланса трафика внутри виртуального соединения. При отказе какого-либо канала соединение приходится также устанавливать заново.

Протокол X.25 допускает использование следующих максимальных значений длины поля данных: 16, 32, 64, 128, 256, 512 и 1024 байта. Предпочтительной является длина 128 байтов. Пакеты данных циклически нумеруются от 0 до 7 или от 0 до 127. В заголовке пакета помещаются два номера: порядковый номер передачи и порядковый номер приема. Порядковый номер передачи необходим для обеспечения последовательной транспортировки данных по виртуальному каналу, обнаружения потерь пакетов и для управления интенсивностью поступления пакетов в сеть передачи данных.

Услуги по стандарту Х.25 предоставляются многими общественными сетями передачи данных - в США Sprint/Telenet, BT/Tymnet, Infonet и другими, в России - "Исток-К". "Спринт Сеть", ИАСНЕТ, РОСПАК, ИНФОТЕЛ, Релком и другими. Сети Х.25 часто являются единственной возможностью для создания международной сети, так как почти во всех странах имеются сети данного типа. Можно построить и свою собственную сеть Х.25, купив коммутационное оборудование Х.25 и арендовав выделенные линии.

Сети frame relay - сравнительно новые сети, которые гораздо лучше подходят для передачи трафика локальных сетей по сравнению с сетями X.25. Преимущество сетей frame relay заключается в их низкой избыточности, высокой емкости при низких задержках и надежности передачи данных по существующим общественным сетям. Они специально разработаны как общественные сети для соединения частных локальных сетей. Сети frame relay стандартизованы подкомитетом СС1ТТ 1.122. Они обеспечивают скорость передачи данных до 2 Мб/с и позволяют потребителю наращивать требуемую пропускную способность частями по 56 Кб/с.

Сети frame relay обеспечивают высокую пропускную способность и низкие задержки за счет исключения избыточных операций по коррекции ошибок, так как они рассчитаны на использование надежных цифровых и волоконно-оптических линий связи. Протокол frame relay занимается обнаружением ошибок только на первых двух уровнях модели OSI. в то время как в протоколе X.25 этим занимаются три уровня. Протокол frame relay, так как он работает только на первых двух уровнях модели OSI, является независимым от верхних уровней стека протокола, из-за чего его легко встраивать в сети. Существует спецификация RFC 1490, определяющая методы инкапсуляции в трафик frame relay трафика SNA и локальных сетей.

Протокол frame relay подразумевает, что коммуникационное оборудование конечных пользователей (а, точнее, протоколы сетевого и транспортного уровней, подобные IP и TCP) будут обнаруживать и корректировать ошибки за счет повторной передачи пакетов сетевого или более высоких уровней. Это требует некоторой степени интеллектуальности от конечного оборудования, что по большей части справедливо для современных локальных сетей.

Frame relay предлагает независимую адресацию пакетов. Сети frame relay, как и сети X.25, позволяют устанавливать частные виртуальные каналы между локальными сетями без добавления задержки между узлами. После установления виртуального соединения кадры frame relay маршрутизируются (транслируются, передаются, если более точно следовать переводу глагола relay) через коммутаторы сети. Стандарт frame relay определяет как постоянные виртуальные каналы (PVC), так и коммутируемые (SVC), но в большинстве коммерческих сетей frame relay реализованы в основном сервисы постоянных коммутируемых каналов.

Поле номера виртуального соединения (DLCI) состоит из 11 битов и называется идентификатором связи данных. Это поле содержит номер виртуального канала, соответствующий определенному порту сетевого моста или маршрутизатора. Посылающее устройство помещает этот адрес в кадр (фрейм) и передает кадр в сеть для перемещения к приемному устройству.

Поле данных может иметь размер до 4056 байтов.

В сетях frame relay предусмотрена процедура заказа качества обслуживания, отсутствующая в сетях Х.25. Для каждого виртуального соединения определяются несколько параметров, Два параметра определяют среднюю скорость соединения:

CIR (Committed Information Rate) - средняя скорость, с которой сеть согласна передавать данные пользователя,

CBS (Committed Burst Size) - максимальное количество битов, которое сеть согласна передать от этого пользователя за интервал времени Т.

Если эти величины определены, то время Т определяется формулой

На рисунке 17.9 приведен пример использования сети frame relay пятью удаленными региональными отделениями корпорации. Обычно доступ к сети осуществляется каналами с большей пропускной способностью, чем CIR - пропускная способность канала должна быть равна по крайней мере величине CBS/T. Но при этом пользователь платит не за пропускную способность канала, а за заказанные величины CIR и CBS.

Для управления потоком кадров в сетях frame relay используются механизмы оповещения конечных пользователей о том, что в коммутаторах сети возникли перегрузки (переполнение необработанными кадрами). Бит FECN

Рис. 17.9. Пример использования сети frame relay

(Forward Explicit Congestion Bit) кадра извещает об этом принимающую сторону. На основании значения этого бита принимающая сторона должна с помощью протоколов более высоких уровней (TCP/IP. SPX и т.п.) известить передающую сторону о том, что та должна снизить интенсивность отправки пакетов в сеть.

Бит BECN (Backward Explicit Congestion Bit) извещает о переполнении в сети передающую сторону и является рекомендацией немедленно снизить темп передачи. Бит BECN обычно отрабатывается на уровне устройств доступа к сети frame relay - маршрутизаторов, мультиплексоров и устройств CSU/DSU.

В общем случае биты FECN и BECN могут игнорироваться. Но если конечный пользователь нарушает условия, определяемые параметрами его соединения CIR и CBS, то сеть может просто отбрасывать (не передавать) "избыточные кадры" пользователя, выходящие за рамки договоренностей. Для этого в кадре имеется бит DE (Discard Eligible) -"удаление желательно", который устанавливается при превышения конечным узлом максимальной интенсивности трафика. И если в коммутаторе сети возникает перегрузка, то он может отбрасывать кадры с установленным битом DE.

Сервис frame relay обычно предоставляют те же операторы, которые эксплуатируют сети X.25. Большая часть производителей выпускает сейчас коммутаторы, которые могут работать как по протоколам Х.25, так и по протоколам frame relay.

Маршрутизаторы обычно маршрутизируют трафик между подсетями. Чтобы маршрутизировать трафик между подсетями, которые не находятся поблизости одна от другой, маршрутизатор использует соединение, которое обеспечивает телефонная компания. Т.о. телефонная компания позволяет обеспечить установку соединения через каналы глобальной сети, также называемые выделенными каналами , выделенными линиями или каналами типа «точка-точка».

Телефонная компания так или иначе передает биты по внутренней сети телефонной компании, а конечный результат состоит в том, что для маршрутизаторов выделенный канал представляется эквивалентным кабелю с 4-мя проводами, проложенному между ними, по которому они могут посылать и получать данные в любой момент времени.

На каждой площадке установлен маршрутизатор, а также внутренний или внешний модуль CSU/DSC (устройство последовательного интерфейса маршрутизатора, которое кроме всего обеспечивает настройку последовательного канала на нужную скорость передачи). Модуль CSU/DSU конфигурируется со скоростью канала, кратной наименьшей скорости 64 Кбит/с.

Чтобы передавать трафик по каналу глобальной сети, используется протокол канального уровня. Наиболее популярные – HDLC (High-level Data Link Control) и PPP (Point to Point Protocol). Протоколы HDLC и PPP инкапсулируют пакет, помещая его между заголовком и концевиком. Они также имеют поле контрольной сумы в концевике. Поскольку любые данные, пересылаемы по выделенному каналу типа «точка-точка», предназначены для устройства, находящегося на другом конце – в заголовке (размером 1 байт) редко содержится информация об получателе, а есть лишь концевик с FCS (контрольной суммой для проверки на предмет ошибок). Поэтому отпадает необходимость использования протокола преобразования имён в IP-адреса (ARP). Независимо от того какой протокол используется, маршрутизатор инкапсулирует пакет во фрейм – или фрейм HDLC, или фрейм PPP.

Маршрутизаторы обычно маршрутизируют трафик между различными подсетями. Чтобы перенаправлять трафик между подсетями, которые не находятся в одном месте, маршрутизатор использует соединение, которое обеспечивает телефонная компания.

Технология Frame Relay позволяет избежать прокладки большого количества «выделенных линий» в случае необходимости объединения более 2-х площадок. Концепция службы аналогична концепции большого коммутатора Ethernet. Маршрутизаторы соединяются с сетью Frame Relay, используя выделенный канал, простирающийся от маршрутизатора до коммутатора Frame Relay, установленного в местной АТС. При пересылке фреймов Frame Relay по этому каналу доступа к ближайшему коммутатору, последний смотрит на заголовки фрейма и пересылает его, руководствуясь значением DLCI в заголовке. DLCI (Data-Link Connection Indetifier) – 10-разрядное число от 0 до 1023, которое идентифицирует отдельный постоянный виртуальный канал PVC (Permanent Virtual Circuit).

PVC – постоянный виртуальный канал, означает способность передавать фреймы Frame Relay между двумя устройствами, подключенными к одной сети Frame Relay, если провайдер заранее предусмотрел такую возможность. CIR (Committed Information Rate) — гарантированная скорость передачи.

Чтобы технология работала, каждый маршрутизатор должен быть физически подключен кабелем с коммутатором Frame Relay в местной АТС. Коммутатор Frame Relay – это оборудование которое «понимает» Frame Relay и может передавать трафик, основанный на протоколах Frame Relay. Набор коммутаторов Frame Relay провайдера, наряду с другим оборудованием, установленным между ними, формирует сеть Frame Relay . Услуга, которую предлагает провайдер – это возможность для маршрутизатора посылать фреймы Frame Relay и получать их от других маршрутизаторов, связанных с этой сетью.

Frame Relay – это набор протоколов, каждый из которых выполняет функции, соответствующие канальному уровню 2 модели OSI. Для выполнения функций уровня 1, т.к. обустройство кабельной системы и фактическая передача битов, Frame Relay использует те же стандарты, что и последовательные каналы. Физический последовательный канал между маршрутизатором и коммутатором Frame Relay называют каналом доступа (access link).

Чтобы послать фрейм, маршрутизатор должен поместить в заголовок нужный адрес. Каждый заголовок Frame Relay содержит поле адреса, именуемое идентификатором канала связи (DLCI).

Если маршрутизатору R1 необходимо послать пакет маршрутизатору R2, через сеть Frame Relay, маршрутизатор физически использует последовательный интерфейс и логически использует PVC с необходимым DLCI (для площадки в Киеве это например 102). Маршрутизатор выполняет инкапсуляцию Frame Relay, как это делают и другие протоколы канального уровня. Маршрутизатор R1 знает исходящий исходящий интерфейс и IP-адрес следующего перехода, но он не знает, какой DLCI нужно использовать. Для решения этой проблемы используется инверсный протокол ARP (Inverse ARP). Как только начинает работать постоянный виртуальный канал (PVC), R2 объявляет свой IP-адрес маршрутизатору R1, используя виртуальный канал (VC) между этими двумя маршрутизаторами. R1 также объявляет свой IP-адрес маршрутизатору R2.

Технология Frame relay (FR) изложена в § 4.3. Сети Frame relay (ретрансля­ция кадров) также являются сетями пакетной коммутации, но отличаются от сетей Х.25: на канальном уровне не выполняется контроль ошибок. Контроль за пра­вильностью передачи данных от отправителя должен осуществляться на бо­лее высоком уровне иерархии протоколов; мультиплексирование (маршрутизация) осуществляется на канальном (ап­паратном) уровне. Управление потоком отсутствует. В основном применяются постоянные виртуальные каналы. На рис. 10.12 представлена структура сети Frame relay. Так как в FR применены виртуальные каналы (статическое мультиплекси­рование), то абонент (маршрутизатор) имеет возможность в течение некото­рого времени передавать данные со скоростью выше той, которая ему гаран­тируется. В связи с этим главной причиной потери передаваемых данных в

сетях ретрансляции кадров является перегрузка (congestion) узлов коммута­ции. Управление трафиком организовано так, что абонент по своему выбору ведет передачу либо в гарантированном режиме, либо с превышением заранее согласованной скорости, что, естественно, сопряжено с риском потери инфор­мации и с повтором передачи искаженных кадров. Пропускная способность сети FR, выделяемая виртуальному каналу, харак­теризуется следующими параметрами. гарантированная скорость передачи данных, т. е. обеспечиваемая абонен­ту постоянно (committed information rate, CIR); учетный период - промежуток времени (секунды), для которого опреде­лен максимальный объем данных (биты), передаваемых сетью с удовлетвори­тельной вероятностью (committed rate measurement interval, T c). гарантированный объем передачи - максимальный объем данных (биты), транспортировка которых в течение учетного периода Т с обеспечена с высокой вероятностью (committed burst size, В с). дополнительный объем передачи - максимальный объем данных (биты), доставка которых в течение учетного периода Т с (в дополнение к объему В с) возможна, но с меньшей вероятностью (excess burst size, В е). максимальная скорость передачи данных (excess information rate, EIR), которая определяется как EIR = (В с + В е)/Т с. Другое название этого параметра - пропускная способность порта (port speed). Из приведенных определений понятно, что CIR, В с и Т с должны удовлетво­рять следующему отношению: CIR = В с /Т с. Пользователь выбирает (и оплачи­вает) пропускную способность порта (EIR) и гарантированную скорость пере­дачи данных (CIR) для каждого виртуального канала, проходящего через порт.

Скорость передачи данных вычисляется узлом доступа к сети FR путем измерения объема, переданного за время Т с. При этом выполняются следую­щие действия: 1. Если полученное значение скорости не превосходит CIR, кадры переда­ются без изменения. 2. Если скорость больше CIR, но меньше EIR, то в кадрах устанавливается бит DE (Discard Eligibility), разрешающий их удаление (при возникновении пере­грузки сети такие кадры отбрасываются в первую очередь). Бит DE может устанавливаться и оборудованием пользователя, которое, таким образом, вы­бирает, какими кадрами пожертвовать прежде всего. 3. В случае, когда скорость превосходит ЕГО., поступающие кадры удаляют­ся независимо от каких-либо условий. Некоторые поставщики услуг предлагают значительные скидки за переда­чу кадров с битом DE. При наличии в сети достаточного запаса пропускной способности абонент может снизить свои финансовые затраты (иногда больше 50 %), положив CIR = 0 (в этом случае DE = 1 во всех передаваемых кадрах). Таким образом, в сетях FR допускается передача данных со скоростью выше гарантированной вплоть до пропускной способности порта, но при этом некото­рые кадры могут быть потеряны и для их восстановления требуется повторная передача. Российские абоненты могут воспользоваться некоторыми международны­ми службами: Global Managed Data Service (английская компания Cable&Wireless PLC), SITA (английская компания SITA Group), Datanet (финская компания Telecom Finland). Есть и отечественные сети, предоставляющие услуги Frame relay: Маком- нет, Метроком, Роском, СОВАМ-телепорт, Спринт и др. Диапазон параметра пропускной способности порта EIR составляет от 56 - 64 кбит/с до 1,544 Мбит/с с шагом 64 кбит/с, а СШ. - 4, 8,16, 32, 56, 64 кбит/с и далее до 1,544 Мбит/с с шагом 64 кбит/с. Основными преимуществами сетей Frame relay являются: высокая скорость передачи. В настоящее время сети Frame relay обеспе­чивают скорость передачи 56 кбит/с и 1,544 Мбит/с; малая сетевая задержка при активизации виртуального канала; хорошая связность для звездной и ячеистой топологии; эффективное использование полосы пропускания. В то же время можно отметить следующие недостатки Frame relay: для подключения к сети Frame relay пользователю необходимо арендо­вать или иметь собственную выделенную линию; для эффективной работы сети требуется высокая надежность каналов свя­зи. Поэтому для построения сетей Frame relay используются дорогие спутни­ковые, оптоволоконные, цифровые каналы связи; сети Frame relay не рассчитаны на передачу больших файлов данных (по­рядка 100 Мбайт), данных мультимедиа и на обслуживание ровного трафика (например, при коллективной разработке ПО). Сети Frame relay предназначены, прежде всего, для приложений со случай­ными сильными всплесками трафика, которые, например, имеют место в сетях электронной почты, автоматизированного проектирования, а также в системах клиент/сервер.

Сети Frame Relay относятся к сетям с коммутацией пакетов, которые основаны на реализации цифровых каналов связи со скоростью передачи пакетов до 2 Мбит/с. Технология сети реализована с помощью физического и канального уровней OSI. Интерфейс пользователя UNI — синхронный порт с номинальной скоростью 9,6 — 64 кбит/с. Межсетевой интерфейс NNI реализует высокопроизводительные цифровые линии.

Сеть разрешает транспортировать пакеты в пункты назначения по адресному полю. Список разрешимых путей рассылки создается провайдером услуг сети. Сеть поддерживает готовые соединения постоянны/коммутируемых виртуальных сетей — PVC, SVC. Сеть Frame Relay не гарантирует надежную доставку пакета. Также возможна потеря целостности и контроля пакетов. Это следствие того, что сеть реализует большую скорость коммутации без промежуточной буферизации.

Сеть реализует синхронный формат HDLC с длиной поля данных до 4 кбайт и полем CRC — 2 байт. Мультиплексирование кадров реализуется по 2-4 байтам заголовка, следующего за флагом-разделителем начала пакета. Формат заголовка показан на рис.1. Пакеты передаются по одной или более виртуальных цепей, который определяются по идентификатору DLCI. DLCI — 10 битное поле. Каждый DLCI имеет настроенный маршрут коммутации к определенному получателю.

Рисунок — 1, а- байты 1-2, б — байты 3 и 4

Флаг C/R (команда/ответ) используется по усмотрению приложения. Контроль потока не предусмотрен, однако при заказе линии (56 кбит/с или Т1) указывается допустимая скорость транспортировки CIR для каждого DLCI. Такую скорость сеть поддерживает при нормальных условиях. Если транспортировать пакеты с большей скоростью, то те кадры которые помечены флагом DE (кандидат на отбрасывания) при перегрузках будут отброшены первыми.Сеть предупреждает о начале перегрузки с помощью флагов FECN и BECN (перегрузка в прямом и обратном направлениях). С помощью них интерфейс может уменьшить скорость транспортировки до того, как начнут пропадать кадры.

Оборудование в таких сетях CPE периодически опрашивает коммутатор для анализа состояния сети и соединений DLCI. Приблизительно каждые 10 секунд реализуется обмен пакетами, которые передают данные о исправности соединения. Приблизительно раз в минуту реализован обмен пакетами FS (полное состояние), они дают данные о настроенных и активных DLCI.