Почти Ethernet

История, главные черты и стандарты frame relay.

Tехнология frame relay была разработана специально для передачи неравномерного компьютерного трафика через «хорошие» каналы связи. До ее появления основная часть такого трафика передавалась на большие расстояния «почтенными» сетями X.25, происхождение которых теряется в далеких 60-х гг. прошлого века. Новые сети быстро прижились и получили повсеместное распространение.

Однако вытеснение сетей X.25 сетями frame relay (а также АТМ) произошло отнюдь не в угоду моде. Вследствие изменения наиболее типичных условий работы сетей передачи данных, они все чаще стали функционировать поверх качественных цифровых линий связи. А, следовательно, все мощные механизмы обнаружения и исправления ошибок сетей X.25, каковые были просто необходимы при работе на зашумленных выделенных и коммутируемых каналах, проходящих через аналоговые системы уплотнения телефонных сетей, оказались просто ненужными. И не только ненужными, но и вредными, потому что производимая вхолостую работа по отправке многочисленных квитанций о доставке данных засоряла сеть и существенно уменьшала ее полезную пропускную способность.

Сети X.25 вообще отличаются большой избыточностью стека протоколов, в них процедуры обнаружения и исправления ошибок, а также процедуры управления потоком данных предусмотрены и на канальном, и на сетевом уровнях. В результате вероятность битовой ошибки в каналах плохого качества понижается с 10^-3 до 10^-8. Между тем у современного цифрового канала вероятность 10^-8 обеспечивается его собственными средствами, так что острой необходимости в его улучшении нет. А те редкие кадры, которые все-таки не дошли до адресата или дошли в искаженном виде, эффективней восстановить с помощью протоколов верхних уровней, например транспортного (такого, как TCP) или прикладного.

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

Пользователь может согласовать с поставщиком услуг frame relay среднюю скорость, а также величину и продолжительность пульсации трафика данных при его передаче по определенному виртуальному каналу. Сети frame relay, как и сети X.25, работают на основе виртуальных каналов, но с каждым таким каналом теперь связываются не только параметры пути (метки), но и параметры QoS. Правда, технология frame relay может обеспечить не все параметры QoS, которые клиенту хотелось бы видеть в соглашении об уровне сервиса (Service Level Agreement, SLA) с провайдером. Так как изначально она предназначалась только для передачи компьютерного, нечувствительного к задержкам трафика, то гарантий на вносимые сетью задержки и их вариации пользователь не получает — в отличие от пользователя сети АТМ, у которого есть возможность, при необходимости, оговорить и их величины. Существующие сегодня варианты сетей frame relay могут представлять гарантии и по задержкам — за счет приоритезации критичного трафика, однако эти механизмы не обладают такой же продуманностью и стройностью, как соответствующие механизмы АТМ, которая с самого начала разрабатывалась как транспортная технология для трафика всех типов, в том числе голоса и видео.

Технология frame relay стандартизирована как служба сетей ISDN (однако популярность она получила в качестве самостоятельной технологии коммутации пакетов). В рекомендациях I.122, вышедших в свет в 1988 г., она входила в число дополнительных служб пакетного режима ISDN, но затем уже при пересмотре рекомендаций в 1992-93 гг. была названа службой frame relay и вошла в число служб режима передачи кадров наряду с frame switching. Последняя работает в режиме гарантированной доставки кадров с регулированием потока, но на практике такой режим не выдержал конкуренции с простым подходом frame relay. Собственно, название этой службы (relay — эстафетная передача, ретрансляция) хорошо отражает суть процесса передачи данных сетью — коммутаторы просто передают друг другу кадры данных в соответствии с проложенным виртуальным путем (техника таких путей описана в уроке «Пути-дороги через сеть», опубликованном в мартовском номере 2001 г. «Журнала сетевых решений/LAN») и отбрасывают кадры, если они оказываются искаженными (или нарушителями SLA, но об этом позже).

Технология frame relay сразу привлекла большое внимание ведущих телекоммуникационных компаний и организаций по стандартизации. В ее стандартизации помимо CCITT (ITU-T) активное участие принимают Frame Relay Forum и комитет T1S1 института ANSI.

Некоммерческая организация Frame Relay Forum была образована в 1990 г. компаниями Cisco Systems, StrataCom (сегодня — подразделение Cisco Systems), Northern Telecom и Digital Equipment Corporation для развития и конкретизации стандартов CCITT и ANSI. Спецификации Frame Relay Forum носят название FRF и имеют порядковые номера. Они часто стандартизируют те аспекты технологии frame relay, которые не нашли свое отражение в стандартах ITU-T и ANSI. Например, спецификация FRF.11 определяет режим передачи голоса по сетям frame relay.

Консорциум Frame Relay Forum разработал спецификацию, отвечающую требованиям базового протокола frame relay, принятого T1S1 и CCITT. Однако он расширил базовый протокол, включив дополнительные возможности по управлению сетью со стороны пользователя, что очень важно при использовании сетей frame relay в сложных составных корпоративных сетях. Эти дополнения называют обобщенно локальный интерфейс управления (Local Management Interface, LMI).

Стандарты ITU-T обычно отличаются высоким уровнем сложности и наличием многих, достаточно трудно воплотимых на практике возможностей. Спецификации Frame Relay Forum упрощают некоторые аспекты стандартов ITU-T или отбрасывают те или иные возможности. Так, технология frame switching не нашла своего отражения в спецификациях FRF, а процедуры создания коммутируемых виртуальных каналов появились в спецификациях FRF позже, чем в стандартах ITU-T, и оказались более простыми.

Стандарты frame relay, как ITU-T/ANSI, так и Frame Relay Forum, определяют два типа виртуальных каналов — постоянные (PVC) и коммутируемые (SVC). Это соответствует потребностям пользователей — так, для соединений, по которым трафик передается почти всегда, больше подходят постоянные каналы, а соединениям, необходимым только на несколько часов в месяц, достаточно коммутируемых каналов.

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

Стек протоколов FRAME RELAY

Для автоматического установления виртуальных соединений технология frame relay использует протокол третьего уровня Q.933, а по уже установленным виртуальным каналам данные передаются с помощью протокола Q.922/LAP-F, типичного представителя протоколов второго, канального, уровня (см. Рисунок 1). Такое построение стека протоколов значительно проще по сравнению с архитектурой сетей X.25, так как в последних протокол третьего уровня используется не только для прокладки виртуального пути, но и для передачи по нему пользовательских данных.

Рисунок 1. Стек протоколов frame relay.

Кроме того, протокол канального уровня LAP-F в сетях frame relay имеет два режима работы — основной (core) и управляющий (control). Пользовательские данные передаются в основном режиме, при котором кадры отправляются путем их простой ретрансляции.

Такой подход позволяет уменьшить накладные расходы при передаче пакетов локальных сетей, так как они помещаются сразу в кадры канального уровня, а не в пакеты сетевого уровня, как это происходит в сетях X.25.

Структура стека отражает тот факт, что технология frame relay ведет свое происхождение от технологии ISDN, так как сети frame relay заимствуют многое из стека протоколов ISDN, особенно в процедурах установления коммутируемого виртуального канала. Так, протокол LAP-F core — значительно упрощенная версия протокола LAP-D ISDN. Протокол LAP-F (стандарт Q.922 ITU-T) работает на любых каналах сети ISDN, а также на каналах T1/E1. Терминальное оборудование посылает в сеть кадры LAP-F core в любой момент времени в дейтаграммном режиме, считая, что виртуальный канал через сеть коммутаторов уже проложен. При использовании PVC оборудованию frame relay нужно поддерживать только протокол LAP-F core.

Протокол LAP-F contol является необязательной надстройкой над LAP-F core и выполняет функции контроля доставки кадров и управления потоком. С помощью LAP-F control сеть реализует службу frame switching.

Для организации коммутируемых виртуальных каналов стандарт ITU-T предлагает задействовать канал D пользовательского интерфейса. На нем по-прежнему работает протокол LAP-D, который в сетях ISDN применяется для надежной передачи кадров. Функционирующий поверх него протокол Q.931 или Q.933 (последний — упрощенная модификация протокола Q.931 ISDN) устанавливает виртуальное соединение на основе адресов конечных абонентов в стандарте E.164 или ISO 7498, а также номера виртуального соединения, который в технологии frame relay носит название идентификатора соединения канального уровня (Data Link Connection Identifier, DLCI).

После того как коммутируемый виртуальный канал в сети frame relay установлен посредством протоколов LAP-D и Q.931/933, кадры могут транслироваться по протоколу LAP-F — он коммутирует их с помощью таблиц коммутации портов, где используются локальные значения DLCI. По сравнению с LAP-D, протокол LAP-F core выполняет только часть функций канального уровня, поэтому ITU-T изображает его на пол-уровня ниже, чем протокол LAP-D, оставляя место для функций надежной передачи пакетов протоколу LAP-F control.

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

Кадры FRAME RELAY

Структура кадра протокола LAP-F приведена на Рисунке 2. За основу взят формат кадра HDLC, который используется во многих сетях, в том числе и X.25 (на канальном уровне). Однако поле адреса имеет существенно иной формат, а поле управления вообще отсутствует.

Рисунок 2. Формат кадра LAP-F.

Поле номера виртуального соединения (Data Link Connection Identifier, DLCI) состоит из 10 бит, что позволяет использовать до 1024 виртуальных соединений. Поле DLCI может занимать и большее число разрядов — его длиной управляют признаки EA0 и EA1 (Extended Address — расширенный адрес). Если бит в этом признаке задан равным нулю, то признак называется EA0 и означает, что в следующем байте имеется продолжение поля адреса, а если бит признака равен 1, то поле именуется EA1 и указывает на окончание поля адреса.

Десятиразрядный формат DLCI является основным, но при использовании для адресации 3 байт поле DLCI имеет длину 16 бит, а в случае 4 байт — 23 бит.

Стандарты frame relay (ANSI, ITU-T) распределяют адреса DLCI между пользователями и сетью следующим образом:

• 0 используется для виртуального канала локального управления (LMI);
• 1-15 зарезервированы на случай будущего применения;
• 16-991 задействуются абонентами для нумерации PVC и SVC;
• 992-1007 назначаются сетевой транспортной службой для внутрисетевых соединений;
• 1008-1022 зарезервированы на случай будущего применения;
• 1023 предназначены для управления канальным уровнем.

Таким образом, в любом интерфейсе frame relay для оконечных устройств пользователя отводится 976 адресов DLCI.

Поле C/R имеет обычный для протокола семейства HDLC смысл — это признак «команда/ответ». Поля DE, FECN и BECN используются протоколом для управления трафиком и поддержания заданного качества обслуживания виртуального канала.

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

Поддержка качества обслуживания

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

• CIR (Committed Information Rate) - согласованная информационная скорость передачи по сети данных пользователя.
• B_c (Committed Burst Size) - согласованный объем пульсации, т. е. максимальное количество байтов, которое сеть будет передавать от этого пользователя за интервал времени t.
• B_e (Excess Burst Size) - дополнительный объем пульсации, т. e. максимальное количество байтов, которое сеть будет пытаться передать сверх установленного значения B_c за интервал времени t.

Не все из этих параметров можно свободно выбирать ввиду наличия достаточно простой зависимости: t = B_c/CIR. Если задать B_c и CIR, то t вычисляется, а если задать значения CIR и t, то производной величиной станет объем пульсации трафика Bc. Соотношение между параметрами CIR, B_c, B_e и t иллюстрирует Рисунок 3.

Рисунок 3. Реакция сети на поведение пользователя: R — скорость канала доступа; f1-f4 — кадры.

При установлении постоянного виртуального канала вручную параметры QoS конфигурируются администратором на коммутаторах сети. Если же виртуальный канал организует автоматически с помощью протокола Q.933, то требуемые параметры CIR, B_c и B_e передаются в пакете запроса на установление соединения. Необходимо отметить, что автоматически обычно устанавливаются коммутируемые каналы, т. е. SVC, но можно по протоколу Q.933 автоматически установить и постоянный (точнее, полупостоянный) виртуальный канал, который в этом случае часто называют soft-PVC.

Скорость передачи данных должна измеряться на каком-то интервале времени. Интервал t и является таким контрольным интервалом, где проверяются условия соглашения. В общем случае за этот интервал пользовательские данные не должны передаваться в сеть со средней скоростью, превосходящей CIR. При нарушении соглашения сеть не гарантирует доставку кадра и помечает его признаком Discard Eligibility (DE), равным 1, т. е. как кадр, подлежащий удалению. Однако кадры, отмеченные таким признаком, удаляются из сети, только когда коммутаторы сети испытывают перегрузки. Если все в порядке, кадры с признаком DE=1 доставляются адресату.

Такое щадящее поведение сети соответствует случаю, когда общее количество данных, переданных пользователем в сеть за период t, не превышает объема B_c+B_e. Если же этот порог превышен, то кадр не помечается признаком DE, а немедленно удаляется из сети.

На Рисунке 3 изображен пример, когда за интервал времени t в сеть по виртуальному каналу поступило пять кадров. Средняя скорость поступления информации в сеть составила на этом интервале R бит/с, и она оказалась выше CIR. Кадры f₁, f₂ и f₃ доставили в сеть данные, суммарный объем которых не превысил порог Bc, поэтому эти кадры ушли дальше транзитом с признаком DE=0. Данные кадра f₄, прибавленные к данным кадров f₁, f₂ и f₃, уже превысили порог B_c, но еще не превысили порога B_c+B_e, поэтому кадр f₄ также отправлен дальше, но уже с признаком DE=1. Данные кадра f₅, прибавленные к данным предыдущих кадров, превысили порог B_c+B_e, поэтому этот кадр был удален из сети.

Для контроля соглашения о параметрах качества обслуживания все коммутаторы сети frame relay выполняют так называемый алгоритм «дырявого ведра» (Leaky Bucket). Алгоритм использует счетчик С поступивших от пользователя байт. Каждые t секунд этот счетчик уменьшается на величину B_c (или же сбрасывается в 0, если значение счетчика меньше, чем B_c). Все кадры, данные которых не привели к увеличению значения счетчика выше порога B_c, пропускаются в сеть со значением признака DE=0. Кадры, чьи данные привели к значению счетчика, большему B_c, но меньшему B_c+B_e, также передаются в сеть, но с признаком DE=1. И наконец, кадры, приведшие к значению счетчика, большему B_c+B_e, отбрасываются коммутатором.

Пользователь может договориться о включении лишь некоторых параметров качества обслуживания на данном виртуальном канале. Например, он может задать только параметры CIR и B_c. Этот вариант предоставляет более качественное обслуживание, так как кадры никогда не отбрасываются коммутатором сразу. Коммутатор только помечает кадры, для которых превышен порог B_c за время t, признаком DE=1. Если сеть не сталкивается с перегрузками, то кадры такого канала всегда доходят до конечного узла, даже если пользователь постоянно нарушает договор с сетью.

Популярностью пользуется еще одна комбинация параметров качества обслуживания, когда оговаривается только порог B_e, а скорость CIR полагается равной нулю. Все кадры такого канала сразу же отмечаются признаком DE=1, но отправляются в сеть, а при превышении порога Be они отбрасываются. Контрольный интервал времени t в этом случае вычисляется как B_e/R, где R — скорость канала доступа.

На Рисунке 4 приведен пример сети frame relay с пятью удаленными региональными отделениями некоей компании. Обычно доступ к сети осуществляется по каналам с большей пропускной способностью, чем CIR. Но при этом пользователь платит не за пропускную способность, а за заказанные величины CIR, B_c и B_e. Так, при использовании в качестве канала доступа канала T1 и заказа службы со скоростью CIR, равной 128 Кбит/с, пользователь будет платить только за скорость 128 Кбит/с, а скорость канала T1 в 1,544 Мбит/с будет определять верхнюю границу возможной пульсации B_c+B_e.

Параметры качества обслуживания могут быть различными для разных направлений виртуального канала. Так, на Рисунке 4 абонент 1 соединен с абонентом 2 виртуальным каналом с DLCI=136. В направлении от абонента 1 к абоненту 2 канал имеет среднюю скорость 128 Кбит/с с пульсациями B_c=256 Кбит (интервал t составил 1 с) и B_e=64 Кбит. А при передаче кадров в обратном направлении средняя скорость уже может достигать значения 256 Кбит/с с пульсациями B_c=512 Кбит и B_e=128 Кбит.

Механизм заказа средней пропускной способности и максимальной пульсации является основным при управлении потоками кадров в сетях frame relay. Соглашения должны заключаться таким образом, чтобы сумма средних скоростей виртуальных каналов не превосходила возможностей портов коммутаторов. При заказе постоянных каналов за это отвечает администратор, а при установлении коммутируемых виртуальных каналов — программное обеспечение коммутаторов. В случае превышения взятых на себя обязательств сеть борется с перегрузками путем удаления кадров с признаком DE=1 и кадров, для которых превышен порог B_c+B_e.

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

Бит Backward Explicit Congestion Bit (BECN) извещает о переполнении в сети передающую сторону и служит сигналом для немедленного снижения темпа передачи. Бит BECN обычно отрабатывается на уровне устройств доступа к сети frame relay — маршрутизаторов, мультиплексоров и устройств CSU/DSU. Протокол frame relay не требует от устройств, получивших кадры с установленными битами FECN и BECN, срочного прекращения передачи кадров в данном направлении, как это имеет место в случае кадров RNR в сетях X.25. Эти биты должны служить указанием для протоколов более высоких уровней (TCP, SPX, NCP и т. п.) о необходимости снижения темпа передачи пакетов. Так как регулирование потока инициируется в разных протоколах по-разному — как принимающей стороной, так и передающей, — то разработчики протоколов frame relay предусмотрели возможность снабжения предупреждающей информацией о переполнении сети в обоих направлениях.

В общем случае биты FECN и BECN могут игнорироваться. Но обычно устройства доступа к сети frame relay (Frame Relay Access Device, FRAD) отрабатывают по крайней мере признак BECN.

При создании коммутируемого виртуального канала параметры качества обслуживания передаются в сеть посредством протокола Q.931. Этот протокол отвечает за установление виртуального соединения с помощью нескольких служебных пакетов.

Если абонент сети frame relay хочет установить коммутируемое виртуальное соединение с другим абонентом, то он должен передать в сеть по каналу D сообщение SETUP, которое имеет несколько параметров, в том числе:

• DLCI;
• адрес назначения (в формате E.164, X.121 или ISO 7498);
• максимальный размер кадра в данном виртуальном соединении;
• запрашиваемое значение CIR для двух направлений;
• запрашиваемое значение B_c для двух направлений;
• запрашиваемое значение B_e для двух направлений.

Коммутатор, с которым соединен пользователь, сразу же передает пакет CALL PROCEEDING об обработке вызова. Затем он анализирует указанные в пакете параметры, и если коммутатор может их удовлетворить (с учетом, естественно, информации о том, какие виртуальные каналы на каждом порту он уже поддерживает), то пересылает сообщение SETUP следующему коммутатору, выбираемому по таблице маршрутизации. Протокол автоматического составления таблиц маршрутизации для технологии frame relay не определен, поэтому может использоваться фирменный протокол производителя оборудования или же составление таблицы вручную. Если все коммутаторы на пути к конечному узлу согласны принять запрос, то пакет SETUP передается в конечном счете вызываемому абоненту. Последний немедленно направляет в сеть пакет CALL PROCEEDING и начинает обрабатывать запрос. Если запрос принимается, то вызываемый абонент передает в сеть новый пакет — CONNECT, который проходит в обратном порядке по виртуальному пути. Все коммутаторы должны отметить, что данный виртуальный канал принят вызываемым абонентом. При поступлении сообщения CONNECT вызывающему абоненту он должен отправить в сеть пакет CONNECT ACKNOWLEDGE.

Сеть также должна передать вызываемому абоненту пакет CONNECT ACKNOWLEDGE, и на этом соединение считается установленным, после чего по новому виртуальному каналу могут передаваться данные.