Как стать победителем в гонке frame relay

Передача IP-пакетов по frame relay сопряжена со значительными накладными расходами. Данный краткий курс поможет вам оптимизировать использование полосы пропускания.

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

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

Традиционно локальные и глобальные сети имели совершенно различные архитектуры, как говорится, "гора с горой никогда не встретится". Такое разделение, еще более усиленное структурой и ограничениями, свойственными применяемым технологиям, обусловило неэффективность вложений в силу необходимости иметь две независимые технические службы.
На уровне глобальной сети многие сети состояли из прямых выделенных линий со скоростями передачи от 19,2 Кбит/с до 1,544 Мбит/с (T-1), а уровни данных выше простого форматирования линии обрабатывались разнообразными коммуникационными устройствами на обоих концах. Линии рассматривались как "пустые трубы".

Другой распространенной архитектурой глобальной сети была классическая среда типа шины (multidrop) в локальных сетях, в которой ряд географически удаленных друг от друга мест соединен в каскад через относительно медленные выделенные линии. При таком сценарии коммуникации обеспечиваются центральной системой, использующей нестандартный протокол на подобие основного коммуникационного протокола для ЭВМ компании IBM - SNA.

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

Одним из наиболее распространенных применений сервисов frame relay стало продолжение локальных сетей на базе TCP/IP в глобальные сети; в результате компания получает корпоративную сеть, во многом сохраняющую гибкость и функциональность локальной сети. Сеть frame relay предоставляет "трубы", поддерживающие IP-сеть.

ОСНОВЫ FRAME RELAY

Frame relay - это протокол уровня звена данных (уровень 2 в модели OSI), предоставляющий простой, ориентированный на соединение сервис по передаче кадров. Данный протокол используется в основном для замены глобальных сетей с частными линиями. Такие функции, как управление потоком и устранение ошибок, возлагаются на высокоуровневые протоколы в устройствах конечных пользователей (см. Рис. 1).

Реализовать frame relay можно в виде одной из трех базовых конфигураций:

· маршрутизатор со встроенными средствами frame relay;
· маршрутизатор с высокоскоростным последовательным портом, подсоединенным к CSU/DSU для frame relay;
· устройство доступа frame relay для относительно простых реализаций.

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

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

Мы изучим эту зависимость подробнее, когда будем рассматривать особенности frame relay в контексте вышележащей среды IP с двумя основными методами маршрутизации: протоколом маршрутной информации (Routing Information Protocol, RIP, маршрутный протокол на базе алгоритма длины векторов) и протокол предпочтения кратчайшего канала (Open Shortest Past First, OSPF, маршрутный протокол на базе алгоритма состояния каналов). Мы также коснемся того, какое влияние может оказать следующая версия IP.

УСТАНОВЛЕНИЕ СВЯЗИ

Сервисы frame relay предоставляются местными и междугородними телекоммуникационными компаниями при скоростях от 56 Кбит/с до 44,736 Мбит/с (DS-3). Одной из наиболее привлекательных черт frame relay является то, что стоимость определяется скоростью доступа и конфигурацией, а не расстоянием. Строго говоря, это не совсем так, но мы обсудим этот вопрос позднее. Frame relay предоставляет стандартный интерфейс в виде сетевого интерфейса пользователя (UNI) между разнообразным оборудованием внутри помещения и оборудованием сети frame relay. Данный стандарт определяет также интерфейс между двумя сетями frame relay (межсетевой интерфейс или NNI); обе из них могут относиться к различным организациям. Управляющий идентификатор канала передачи данных (DLCI, называемый также логическим портом) идентифицирует виртуальное соединение frame relay, или, иначе, постоянный виртуальный канал (PVC). DLCI может идентифицировать оба конца виртуального соединения UNI или NNI посредством указания объектов передачи информации кому и от кого. Маршрутизатор в помещении должен быть сконфигурирован таким образом, чтобы каждый IP-адрес порта соответствовал определенному DLCI.

В большинстве сетей соответствие между DLCI и портом назначения устанавливается заранее; таким образом, в этом случае мы имеем постоянный виртуальный канал, что упрощает процесс маршрутизации, поскольку маршрутизаторы должны только найти в своих таблицах маршрутов/соответствий нужный DLCI и направить трафик на порт в соответствии со значением идентификатора.

Ряд поставщиков планируют начать в этом году реализацию коммутируемых виртуальных каналов (SVC), благодаря которым соединение будет устанавливаться по требованию. Постоянные виртуальные каналы в настоящее время являются единственно возможным вариантом; поэтому в среде OSPF маршрутизатор не может выбрать альтернативный путь, если только администратор не предусмотрел возможность выбора альтернативного пути и не определил этот путь. Проблема в определении полностью ячеистой среды PVC, т.е. возможности использования всех достоинств OSPF, состоит в том, что такая среда значительно увеличивает общую стоимость сети.

Несмотря на то что frame relay отказывается от таких функций протокола третьего уровня, как адресация, идентификация адреса все же производится посредством конфигурации PVC вручную. Одной из фундаментальных функций frame relay является идентификация виртуального соединения. Стандарт frame relay рассматривает как PVC, так и SVC.

Прежде чем коммутируемые виртуальные каналы станут реальностью, надо разрешить несколько технических вопросов. В своей современной реализации устройства frame relay базируются на соединениях PVC, конфигурируемых вручную во многом так же, как статические маршруты, используемые при IP-маршрутизации. В IP-среде статические маршруты говорят маршрутизатору, что весь трафик, адресованный указанному объекту, должен идти по сконфигурированному вручную маршруту. Такой подход упрощает определение маршрута, а также снижает нагрузку на процессор и время задержки. Правда, при этом снижается и возможность маршрутного протокола (например OSPF) после выполнения высокоуровневых функций, в том числе в распределении нагрузки и выборе альтернативного пути. В обоих случаях при недоступности соединения новый маршрут или PVC должен быть сконфигурирован вручную. Если же IP использует статические маршруты и реализован поверх frame relay с предопределенными PVC, необходимо позаботиться о соответствии между статическими маршрутами и PVC.
Виртуальный канал является двунаправленным, поэтому каждому направлению может быть выделена разная полоса пропускания; иными словами, линия для запроса данных с хоста может быть сделана низкоскоростной, а линии передачи данных или файлов с хоста на запрашивающую станцию - высокоскоростной.

ПУТЕВОДНАЯ ЗВЕЗДА

Пользователи сети обмениваются трафиком frame relay по следующей схеме: от входящей линии к соответствующему соединению по исходящей линии через назначенное соединение. Маршрутизатор в помещении пользователя отвечает за создание кадра frame relay, помещение значения DLCI в заголовок кадра и доставку кадра через локальный интерфейс UNI на коммутатор frame relay из облака. Там, где вышележащим протоколом является IP, создание кадров сопряжено с фрагментацией дейтаграмм IP и инкапсуляцией дейтаграмм в кадры frame relay. Маршрутный протокол IP не ведает о том, что происходит, до тех пор, пока дейтаграммы не будут заново собраны принимающим устройством - точно так же, как герои "Звездного пути" не знают, что с ними происходит, пока их тела при помощи "передатчика" перемещаются из одного места в другое.

В случае frame relay и IP высокоуровневая коррекция ошибок обнаруживает их на принимающем конце и запрашивает повторную передачу. Если бы герои "Звездного пути" ("Star Trek") столкнулись с проблемами при фрагментации, то они не отделались бы так легко - отсутствующие части вряд ли бы нашлись, а значит, транспортируемого героя не удалось бы восстановить.

Сеть frame relay должна транслировать трафик на маршрутизатор на удаленном UNI. Отождествление и маршрутизация осуществляется через так называемые таблицы маршрутов, соответствий или перекрестных связей.
DLCI возможно управлять таким образом, что одни и те же числа могут быть повторно использованы другим маршрутизатором в сети. Этот подход, известный как локально значимый, позволяет создавать большее число виртуальных каналов в одной сети frame relay. При использовании данной возможности необходимо позаботиться о запрете раскрытия значений DLCI другим маршрутизатором в той же сети.

Альтернативой к вышеописанному подходу является глобальная адресация, при которой DLCI имеет одно и то же значение во всей сети. Присвоенные адресам номера указывают на одно и то же место назначения вне зависимости от маршрутизатора.
Для маршрутных протоколов типа RIP и OSPF не имеет значения, какое из соглашений используется для DLCI. Пока IP-адреса отождествляются с DLCI правильно, RIP принимает решение о маршруте на основе подсчета промежуточных маршрутизаторов, а OSPF - в соответствии с доступностью пути и скоростью передачи.

Идея глобальной адресации состоит в упрощении управления адресами, однако ограничение на заголовок кадра в два октета позволяет иметь только 922 идентификатора (1024 минус 32 зарезервированных DLCI). Таким образом, при глобальной адресации один и тот же идентификатор не может использоваться двумя портами. Использование DLCI для идентификации PVC возможно лишь тогда, когда он применяется только один раз во всей сети.

При определении PVC посредством DLCI должна быть задана еще одна переменная: фиксированная скорость передачи информации (Committed Information Rate, CIR). Данный элемент выполняет две основных функции, одна из них техническая, другая - коммерческая.

Техническая функция CIR состоит в определении доступной полосы пропускания для данного соединения, которую PVC может задействовать. Если загруженность PVC превышает CIR, то избыточные кадры маркируются для отбраковки. Однако они отбраковываются, только если облако начинает испытывать перегрузки. Важность правильной установки CIR очевидна, так как отбракованные кадры будут посылаться заново, в результате чего трафик и перегрузки возрастают, а конечные пользователи остаются недовольны работой сети.

Две основные величины имеют отношение к CIR: Bc и Be. Bc - это фиксированная скорость передачи пакетов в предопределенном интервале времени. Она обычно превосходит CIR на одну восьмую-одну четвертую, таким образом ее можно определить умножением CIR на 1,112 или 1,25.

Be характеризует максимальную скорость передачи для конкретной "трубы". Например, в случае линии на 56 Кбит/с Be будет соответствовать отводимой под передачу данных части "трубы", т.е. за исключением части, идущей на форматирование линии. Be имеет следующее ограничение в случае нескольких PVC: если один из них находится в состоянии передачи пакетов, то он занимает максимально возможную полосу пропускания трубы.

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

Задание значения CIR равным нулю предоставляет PVC всю полосу пропускания данной линии с обслуживанием в порядке очередности. Однако если данный PVC использует линию непрерывно, то он не даст доступа к ней другим пользователям.

ОБЛАКО В ШТАНАХ

До этого момента мы уделяли основное внимание взаимодействию между сетью frame relay, или облаком, и оборудованием внутри помещения. Внутри облака действуют те же правила, за тем исключением, что коммутаторам frame relay нет нужды поддерживать виртуальные каналы. Трафик может быть адресован посредством либо настроенных вручную DLCI, либо преобразования трафика в соответствии с протоколом IP, после чего он маршрутизуется динамически (см. Рис. 2). Кроме того, есть несколько менее распространенных нестандартизованных вариантов. Альтернативная конфигурация показана на Рис. 3.

Динамическую или адаптивную маршрутизацию между коммутаторами frame relay можно реализовать при помощи операций без установления соединения. Сеть должна гарантировать доставку кадра в обозначенный в DLCI порт, поэтому сеть присоединяет внутренний заголовок к кадру для адресации его при передаче по сети. В конечном коммутаторе frame relay этот сетевой заголовок удаляется, и конечному маршрутизатору передается стандартный кадр через интерфейс UNI.
Поставщики различаются по подходу к маршрутизации - фиксированной или динамической. Вне зависимости от метода он прозрачен для конечных устройств внутри помещения. В случае RIP промежуточными устройствами считаются только маршрутизаторы. Это означает, что система может выбрать путь, в котором на один маршрутизатор меньше, но на несколько коммутаторов больше.

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

В сети frame relay имеется два подхода к трансляции трафика между локальным и удаленным интерфейсами UNI. Первый из них использует DLCI, а второй - внутренний сетевой заголовок. Например, когда внутри облака frame relay используются DLCI, коммутатор frame relay может принимать кадры от физического порта с идентификаторами X и Y. Коммутатор затем обращается к своей маршрутной таблице и определяет, что кадр с адресом Х должен отправляться через порт 2, а кадр с адресом Y через порт 3. Маршрутизатор изменяет затем адресацию DLCI для каждого пакета и отправляет пакеты через соответствующие порты этот процесс продолжается до тех пор, пока кадры не достигнут конечных маршрутизаторов. Преимущество такого процесса в его быстроте.

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

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

На первый взгляд, может показаться, что решения о выборе пути, которые коммутаторы внутри облака должны принимать, снижает пропускную способность. Однако это не так. Небольшое увеличение времени задержки вследствие динамического определения канала несущественно, поскольку, как уже неоднократно говорилось выше, frame relay является протоколом второго уровня. Такой подход, однако, может усложнить определение межсетевого интерфейса с другими сетями.

РОЖДЕННЫЙ ДЛЯ КАДРОВ

Важным фактором для взаимодействующих протоколов является размер кадра или пакета. Стандарт frame relay не ограничивает размер кадров, однако сеть frame relay поддерживает чаще всего минимальный размер кадров в 262 октета, а наиболее распространенные реализации употребляют кадры от 1600 до 4096 октетов. Максимальный размер кадра определяется провайдером услуг связи в зависимости от возможностей оборудования.

Стандарт IP позволяет иметь дейтаграммы размером до 65535 октетов. Несмотря на то что на практике размер дейтаграммы, как правило, меньше, она обычно превосходит по размеру кадр. Это означает, что передающее устройство должно дробить дейтаграммы на приемлемые куски для инкапсуляции в кадры frame relay. Принимающее устройство отвечает за их сборку.
В большинстве случаев frame relay реализован вне рабочих станций или хостов конечных пользователей. Frame relay загружается на маршрутизатор или внешний процессор, что изолирует пользовательскую станцию от самого процесса, а значит, при установке frame relay программное и аппаратное обеспечение пользователя не нуждается в модификации.
В локальной сети сфера действия протоколов локальной сети распространяется до маршрутизатора. Маршрутизатор инкапсулирует заголовки и полезную нагрузку высокоуровневых протоколов (уровни с 3 по 7) в кадры frame relay. Эта информация затем передается по сети frame relay в место назначения, где ее получает маршрутизатор, который убирает заголовки и хвосты пакетов, собирает в случае необходимости фрагментированные компоненты, помещает трафик в кадр локальной сети и доставляет его станции назначения.

ПРАВИЛА RFC

RFC 1490, заменивший RFC 1294, определяет то, как протоколы инкапсулируются в кадр frame relay и как они передаются по сети. Идентификатор протоколов сетевого уровня (Network Level Protocol Identifier, NLPID) задает значения для отождествления распространенных отраслевых протоколов (например IP для Internet) в соответствии с определениями Международной организации по стандартизации и Международного союза по телекоммуникациям.

Назначение поля NLPID состоит в том, чтобы принимающее устройство знало, какой протокол содержится внутри кадра frame relay. Это поле игнорируется сетью frame relay и просматривается только конечным маршрутизатором. Примеры NLPID: 0X80 IEEE соответствует Subnetwork Address Protocol (SNAP), 0X80 ISO - Connectionless Network Protocol (CLNP) и 0XCC - IP. Некоторые протоколы не имеют соответствующих NLPID. В этом случае используется заголовок SNAP, а NLPID указывает на наличие заголовка SNAP.

Сеть frame relay передает протокольные блоки данных двух типов: маршрутные и мостовые. Для маршрутных блоков трафик, находящийся в поле данных кадра, идентифицируется либо по полю Ethertype как часть SNAP, либо по полю NLPID. Для мостовых блоков вслед за заголовком NLPID используется заголовок SNAP. Заголовок NLPID указывает также на сохранение (или несохранение) исходной контрольной последовательности кадра внутри мостового блока. Контрольная последовательность кадра использует уникальный код организации и присваивает значения для обозначения типа трафика: 802.3 (множественный доступ с контролем несущей и обнаружением коллизий, CSMA/CD), 802.4 (маркерная шина), 802.5 (Token Ring), 802.6 (Metropolitan Area Networks) или FDDI.

Информация протокола определения адреса (ARP) может быть извлечена из кадра и при помощи SNAP. Эта операция применяется с целью получения значения DLCI для пользовательской станции, а также с целью корреляции DLCI с адресом. Определение адреса в сети frame relay осуществляется во многом, как и в обычных средах. Вначале пользователь формирует сообщение с запросом ARP, при этом поля аппаратных адресов в запросе не определены, так как аппаратные адреса не используются. Затем адреса отправителя и получателя формируются, как обычно, в соответствии с протоколом. Предположим, например, что IP-адрес отправителя X, а получателя - Z. Когда пользователь C получает запрос ARP, то он инкапсулирован в кадр frame relay, содержащий локальное значение DLCI, равное 56 (помещенное в кадр сетью frame relay). Пользователь B извлекает это значение из заголовка и помещает его в поле аппаратного адреса отправителя приходящего сообщения c запросом ARP. В результате у пользователя B появляется возможность отождествить протокольный адрес A с DLCI 56.
Далее пользователь B формирует сообщение с ответом ARP (меняет местами значения отправителя и получателя в сообщении), но оставляет аппаратный адрес получателя неопределенным. Когда пользователь А получает этот кадр, то заголовок frame relay содержит DLCI 15. Таким образом, пользователь А извлекает это значение и помещает его в поле аппаратного адреса отправителя. Данная операция дает возможность пользователю А отождествить DLCI 15 с протокольным адресом C.

По мере развития стандартов frame relay возникают дополнительные вопросы по реализации (см. врезку "Будущее frame relay"). Однако маршрутные стандарты frame relay и IP в том виде, в каком они реализованы сегодня, работают вместе исключительно хорошо, по крайней мере до тех пор, пока задействованные устройства сконфигурированы с учетом взаимозависимости двух протоколов.

ВЫЗОВЕТ ЛИ ИЗМЕНЕНИЕ СТАНДАРТОВ НАРУШЕНИЕ РАВНОВЕСИЯ В ОТРАСЛИ?

Будущее frame relay

По мере того как все большее число вариантов стандартов frame relay воплощается в жизнь, появляются новые вопросы. Одна из потенциальных проблем - сочетание динамической среды и коммутируемых виртуальных каналов с "неименованными" адресами для IP. Если обе величины динамические, то как установить соответствие между ними?

А как воплотить концепцию фрагментации для новой версии IP - IPv6 (также обычно называемой IP следующего поколения или IPng) - когда путь в облаке может меняться? Важным моментом в этом случае является требование IPv6 по определению для пути максимального передаваемого блока (MTU), необходимого для задания оптимального для фрагментации размера дейтаграммы. Если путь через облако все время меняется, то MTU может и не быть постоянным, а это, возможно, приведет к сбою маршрута. Текущая версия стандарта IP, IPv4, предусматривает динамическую фрагментацию в каждой точке маршрута вдоль всего пути, поэтому задание MTU не имеет особого значения.