CC BY
247
Процедуры и временные характеристики оперативного управления трафиком в транспортной сети специального назначения пакетной коммутации
В настоящее время в транспортной сети пакетной коммутации специального назначения актуальна задача оперативного управления трафиком. Для решения данной задачи необходимо провести обоснованный выбор требований к оперативному управлению трафиком, для чего необходимо уточнить процедуры приложений MPLS. К ним относятся процедуры инжиниринга трафика, включая механизм быстрой ремаршрутизации, сигнализации и резервирования ресурсов для MPLS, организации виртуальных частных сетей. Подробно рассмотрены процедуры приложений MPLS. Для решения задач инжиниринга трафика технология MPLS использует расширения протоколов маршрутизации, работающих на основе алгоритма состояния связей. Сегодня такие расширения стандартизованы для протоколов OSPF и IS-IS. Данные протоколы, в отличие от дистанционно-векторных протоколов, дают маршрутизатору полную топологическую информацию о сети. Их объявления содержат информацию о маршрутизаторах и сетях, а также о физических связях между ними. Каждая связь характеризуется текущим состоянием работоспособности и метрикой, в качестве которой используется величина, обратная пропускной способности канала. Первой из двух функций, возложенных на RSVP технологией MPLS, является распределение меток. Вторая, традиционная для RSVP роль заключается в поддержании QoS в сети MPLS. В MPLS-VPN рассмотрены два основных потока трафика: поток управления, который включает маршрутную информацию между РЕ и СЕ и между маршрутизаторами РЕ, а также информацию, необходимую для создания LSP между маршрутизаторами и поток данных, т.е. поток информации пользователей. На основе примеров показано, что сочетание технологий для организации VPN является эффективным и позволяет построить сеть, поддерживающую множество взятых из VPN дополнительных услуг и реализующую гарантированное качество обслуживания на основе MPLS.
Ключевые слова: управление трафиком, резервирование ресурсов, виртуальные частные сети, маршрутизатор, инжиниринг.
Легков К.Е,
научный сотрудник СевероКавказского
филиала МТУСИ, к.т.н.,
consll@mail.ru
Для решения задачи обоснованного выбора требований к оперативному управлению трафиком в транспортной сети пакетной коммутации специального назначения необходимо уточнить процедуры приложений MPLS. К ним в настоящее время можно отнести следующие процедуры:
— инжиниринга трафика (MPLS-TE), включая механизм быстрой ремаршрутизации (MPLS-FRR);
— сигнализации и резервирования ресурсов для MPLS (RSVP-ТЕ);
— организации виртуальньх частньх сетей (MPLS-VPN).
MPLS TE. Для решения задач инжиниринга трафика (TrafficEngineering, TE) технология MPLS использует расширения протоколов маршрутизации, работающих на основе алгоритма состояния связей. Сегодня такие расширения стандартизованы для протоколов OSPF и IS-IS. Данные протоколы, в отличие от дистанционно-векторных протоколов, к которым относится, например, RIF, дают маршрутизатору полную топологическую информацию о сети.
Их объявления содержат информацию о маршрутизаторах и сетях, а также о физических связях между ними. Каждая связь характеризуется текущим состоянием работоспособности и метрикой, в качестве которой используется величина, обратная пропускной способности канала.
Для решения задачи инжиниринга трафика в протоколы О5РР и 15-15 включены новые типы объявлений для распространения по сети информации о номинальной и незарезервированной (доступной для потоков ТЕ) пропускной способности каждой связи. Таким образом, ребра результирующего графа сети, создаваемого в топологической базе каждого маршрутизатора, будут маркированы этими двумя дополнительными параметрами. Располагая таким графом, а также параметрами потоков, для которых нужно определить пути ТЕ, маршрутизатор может найти рациональное решение, удовлетворяющее, например, одному из сформулированных выше ограничений на коэффициенты использования ресурсов сети, обеспечив тем самым ее сбалансированную загрузку. В производимом сегодня оборудовании применяется вариант МР15-ТЕ с последовательным рассмотрением потоков. Он проще в реализации и ближе к стандартным для протокола О5РР процедурам нахождения кратчайшего пути для одной сети назначения. При этом
в качестве ограничения выступает суммарная загрузка каждого ресурса сети. Обычно считается, что внутренней производительности маршрутизатора достаточно (в среднем) для обслуживания любого трафика, который способны принять интерфейсы маршрутизатора. Поэтому в качестве ограничений выступают только максимально допустимые значения коэффициентов загрузки каналов связи, устанавливаемые индивидуально или же имеющее общее значение. Процедура определения маршрута с учетом ограничений получило название Constrained-based Routing, а протокол OSPF с соответствующими расширениями — Constrained SPF, или CSPF
Доказано, что поиск путей TE по очереди снижает качество решения, при одновременном рассмотрении всех потоков можно найти более рациональную загрузку ресурсов. В качестве примера варианты загрузки сети приведены на рис. 1, ограничением является максимально допустимое значение коэффициента использования ресурсов, равное 0,65.
Решение 1 найдено при очередности рассмотрения потоков 1 -> 2 -> 3. Для первого потока был выбран путь A-B-C, так как в этом случае он, с одной стороны, удовлетворяет ограничению (все ресурсы вдоль пути — каналы AB, A-C и соответствующие интерфейсы маршрутизаторов оказываются загруженными на
0,5/1,5 = 0,33), а с другой — обладает минимальной метрикой (65 + 65 = 130). Для второго потока также был выбран путь A-B-C, так как ограничение также удовлетворяется — результирующий коэффициент использования оказывается равным (0,5 + 0,4)/1,5 = 0,6. Третий поток направляется по пути A-D-E-C и загружает ресурсы каналов A-D, D-E и E-C на 0,3. Решение 1 можно назвать удовлетворительным, так как коэффициент использования любого ресурса в сети не превышает 0,6.
Решение 2 показывает лучший вариант. Здесь по верхнему пути A-B-C были направлены потоки 2 и 3, а поток 1 — по нижнему пути A-D-E-C. Ресурсы верхнего пути загружены на 0,46, а нижнего — на 0,5, т. е. загрузка ресурсов более равномерная, а максимальный коэффициент использования по всем ресурсам сети не превышает 0,5. Этот вариант получен при одновременном рассмотрении всех трех потоков с учетом ограничения min (maxKi) или же при рассмотрении потоков по очереди в последовательности 2 -> 3 -> 1.
Функция Fast Re Route (FRR) позволяет восстанавливать прерванную по причине аварии на звене или узле передачу данных по LSP в пределах десятков миллисекунд, путем направления трафика на временный обходной маршрут. Она основывается на TE-туннелях, которые при проектировании сети прокладываются по разным маршрутам. Для определения времени переключения на резервный канал разработан комплекс механизмов по улучшению конвергенции протоколов OSPF/IS-IS, которые позволяют гарантировать время восстановления сервиса на уровне 100-150 мс вне зависимости от топологии сети. Пример такого протокола — Bidirectional Fault Detection (BFD). Он работает независимо от OSPF и может гарантировать доступность информации об аварии в течение 100-150 мс.
В технологии MPLS-TE информация о найденном рациональном пути используется полностью, при этом запоминается не только первый транзитный узел, как в основном режиме маршрутизации IP, а все промежуточные узлы пути, т. е. маршрутизация производится от источника. Поэтому достаточно, чтобы поиском путей занимались только пограничные LSR сети, а внутренние — лишь поставляли им информацию о текущем состоянии сети, которая необходима для принятия решений. Такой подход обладает несколькими преимуществами по сравнению с распределенной моделью поиска пути, лежащей в основе стандартных протоколов маршрутизации IP:
существует возможность использовать "внешние" решения, когда пути находятся дру-
Рис.1. Варианты загрузки ресурсов
гой системой оптимизации сети в автономном режиме, а потом прокладываются в сети;
каждый из пограничных 1.51? может работать по собственной версии алгоритма, в то время как при распределенном поиске на всех 1.51? необходим идентичный алгоритм, что усложняет построение сети с оборудованием разных производителей;
внутренние маршрутизаторы разгружаются от работы по поиску путей.
После нахождения пути, независимо от того, найден он был пограничным LSR или внешней системой, его необходимо установить. Для этого в MPLS-TE используется специальный протокол сигнализации, который умеет распространять по сети информацию о явном маршруте. В качестве такого протокола предлагается использовать RSVP с расширениями TE.
RSVP-ТЕ для MPLS. Первой из двух функций, возложенных на RSVP технологией MPLS, явля-
Рис. 2. Процедура распределения меток с помощью протокола RSVP
ется распределение меток. Вторая, традиционная для RSVP роль заключается в поддержании QoS в сети MPLS.
Использовать метки MPLS намного проще, чем распределить их по маршрутизаторам, составляющим тракт LSR Основными средствами распределения меток являются протокол LDP и расширения протокола резервирования ресурсов RSVP На рис. 2 представлена процедура назначения и распределения меток с использованием расширенного протокола RSVP-ТЕ.
Запрос резервирования RSVP включает в себя две опции, одна из которых описывает способ резервирования (Reservations), а другая
— выбор отправителей (SenderSelection), определяющих направление потоков (flows). В одних случаях каждому отправителю ставится в соответствие определенная спецификация фильтра, в других случаях таких спецификаций не требуется вовсе.
В общем случае протокол RSVP определяет три стиля резервирования:
— раздельное, с фиксированным фильтром
— стиль FixedFilter (FF),
— совместное явное — стиль SharedExplicit (SE),
— совместное, с произвольной фильтрацией — стиль WildcardFilter (WF).
Из этих трех стилей для обслуживания неоднородного мультисервисного трафика, проходящего через узлы сети MPLS, интерес представляют стили резервирования SE и FF
Стиль FF (Fixed-Filter) соответствует опциям раздельного (distinct) резервирования и явного (explicit) выбора отправителя. Таким образом, запрос резервирования стиля FF создает резервный ресурс для информационных пакетов, идущих от определенного отправителя, без совместного с другими отправителями использования этого ресурса в пределах одного и того же сеанса. При этом каждый отправитель использует уникальную метку, а сам идентифицируется на основе IP-адреса и LSP-ID. Для каждой пары отправитель/получатель создается LSP "точка-точка". При резервировании FF полоса пропускания резервируется для каждого отправителя данных индивидуально. Резервные ресурсы и метки не используются совместно потоками разных отправителей и, следовательно, резервированная полоса пропускания через узел представляет собой сумму индивидуальных резервных полос пропускания.
Стиль SE (Shared Explicit) соответствует опциям совместного (shared) резервирования и явного (explicit) выбора отправителя. Таким образом, стиль SE формирует резервный ресурс, который используется совместно несколькими отправителями. В отличие от стиля WF, стиль SE
позволяет получателю непосредственно специфицировать набор отправителей, и так как пользователи перечислены в сообщении Resv, разным пользователям могут быть присвоены различные метки, и для них могут быть созданы разные LSR Если в сообщениях Path отсутствовали объекты ERO или если эти объекты были одинаковыми для всех пользователей, то может быть создан LSP "группа точек-точка". Раздельное резервирование SE пригодно для вещательных приложений, где несколько отправителей данных редко ведут передачу одновременно. Примером раздельного резервирования может служить случай с пакетной передачей речи. Каждый получатель может направить запрос резервирования WF или SE для удвоения полосы пропускания, отводимой одному отправителю, что позволяет говорить обоим партнерам одновременно. С другой стороны, стиль FF, который предусматривает резервирование для потоков отдельных отправителей, подходит для передачи видеосигналов.
Из двух названных выше стилей резервирования FF более прост, но он не позволяет нескольким потокам использовать резервированную полосу пропускания совместно. При использовании стиля резервирования SE объединение отправителей в группу, использующую общий ресурс резервирования, производится по усмотрению получателя. Однако для разных отправителей данных могут назначаться разные метки, и поэтому для каждого отправителя может существовать отличный от других тракт LSP
Процедура резервирования ресурсов позволяет приложениям заранее определить, есть ли в сети возможность доставить многоадресный трафик всем адресатам в полном объеме, и, возможно, принять решение о доставке отдельным получателям усеченных версий потоков. Иначе говоря, RSVP — это протокол сигнализации, который обеспечивает резервирование ресурсов, управляет ими с целью предоставления интегрированных услуг и эмулирует
тем самым выделенные каналы в IP-сетях. Протокол RSVP позволяет запрашивать, например, гарантированную пропускную способность, предсказуемую задержку, максимальный уровень потерь. Но само резервирование, разумеется, выполняется только в том случае, если в наличии имеются требующиеся для этого ресурсы.
Процедура резервирования ресурсов по протоколу RSVP в сети MPLS показана на рис. 3.
Отправитель данных передает по уникальному или по групповому адресу получателя (или получателей) специальное сообщение Path, в котором он указывает параметры, рекомендуемые для обслуживания трафика с нужным качеством: верхнюю и нижнюю границу полосы пропускания, задержку и вариацию задержки. Сообщение Path передается маршрутизаторами сети по направлению к получателю либо с использованием таблиц маршрутизации в узлах сети, либо по явно заданному маршруту (эта опция доступна только при реализации RSVP-TE).
Каждый маршрутизатор, поддерживающий RSVP, получив сообщение Path, фиксирует "состояние процесса создания маршрута", которое включает в себя адрес предыдущего маршрутизатора. В сети образуется фиксированный маршрут передачи сообщений в рамках сеанса RSVP. Сообщение Path должно нести в себе шаблон отправителя (Sender Template), который описывает тип передаваемых отправителем данных. Этот шаблон представляет собой спецификацию фильтра, который может использоваться для того, чтобы отделять пакеты определенного отправителя от других пакетов в пределах сеанса. Шаблоны отправителя имеют тот же формат, что и спецификации фильтра, которые используются в сообщениях Resv. Следовательно, шаблон отправителя может специфицировать только его IP-адрес и (как опция) UDP/TCP порт с учетом идентификатора протокола, заданного для сеанса.
Рис. 3. Резервирование ресурсов при помощи протокола RSVP
Получив сообщение Path, получатель передает маршрутизатору, от которого это сообщение получено, запрос резервирования ресурсов Resv (Reservation Request). Получив сообщение Resv, каждый поддерживающий RSVP маршрутизатор, находящийся на маршруте сообщений резервирования, с целью определить приемлемость указанных в запросе параметров резервирования выполняет две процедуры:
а) с помощью механизма управления доступом (Admission Control) проверяется, имеются ли у маршрутизатора ресурсы, необходимые для поддержки запрашиваемого качества обслуживания;
б) с помощью процедуры контроля прав (Policy Control) — имеет ли пользователь право на резервирование ресурсов. Если запрос не может быть удовлетворен, маршрутизатор передает его отправителю сообщение об ошибке.
Если же запрос принимается, маршрутизатор передает сообщение Resv следующему маршрутизатору, а данные о требуемом качестве обслуживания передаются механизмам маршрутизатора, ответственным за управление трафиком. Сообщение Resv, переадресованное следующему узлу, несет в себе спецификацию flowspec, которая определяет желательное QoS и включает в себя два набора параметров:
— набор Rspec, определяющий желательные характеристики QoS;
— набор Tspec, описывающий информационный поток.
Прием маршрутизатором запроса резервирования означает также передачу им характеристик QoS на обработку в соответствующие собственные функциональные блоки, так как форматы и содержимое Tspec и Rspec установлены общими моделями обслуживания, определенными в RFC 2210 'The Use of RSVP with IETF Integrated Services".
Когда последний маршрутизатор получает сообщение Resv и принимает запрос, он передает подтверждающие сообщение обратно к узлу-получателю (последний маршрутизатор располагается ближе всего к инициатору процедуры резервирования, а в случае групповых потоков — в точке слияния резервируемых трактов). После выполнения резервирования инициатор вышеописанной процедуры начинает передавать свой трафик, который на всем пути к получателю обслуживаются с заданным качеством.
Отменить резервирование можно двумя путями: прямо или косвенно. В первом случае отмена производится по инициативе источника или приемника с помощью специальных сооб-
щений RSVR Во втором случае — по таймеру, так как резервирование имеет определенный срок действия.
В протоколе RSVP довольно просто произвести привязку меток к потокам с резервированием, по крайней мере, в случае использования уникратных адресов. В расширенной версии протокола RSVP-TE, описанной в RFC 3209, определен новый объект LABEL, который переносится в сообщении Resv. Таким образом, RSVP становится инструментом для распределения меток MPLS. Когда маршрутизатору LSR нужно передать сообщение Resv для нового потока, он выбирает из своего пула свободную метку, создает запись в своей таблице LFIB, определяя выбранную метку как входящую, и затем передает сообщение Resv, содержащее эту метку в объекте LABEL.
При получении сообщения Resv с объектом LABEL, содержащим эту входящую метку, вышестоящий LSR вносит ее в свою таблицу как исходящую для пересылки к нижестоящему LSR, передавшему сообщение Resv. Затем он назначает новую метку, которая будет использоваться им как входящая метка, и вставляет эту новую метку в сообщение Resv, передаваемое следующему вышестоящему LSR. Понятно, что по мере прохождения сообщений Resv от нижестоящих маршрутизаторов к вышестоящим создается тракт LSP вдоль всего пути следования этих сообщений. Поскольку в сообщениях Resv указываются метки, каждый LSR может легко связать с трактом LSP соответствующие ресурсы, необходимые для поддержки QoS.
Протокол RSVP, расширенный объектом LABEL, поддерживает пересылку пакетов по сети MPLS (тракт LSP) только вдоль маршрута, вычисленного схемой традиционной маршрутизации пакетов IP При этом отсутствует возможность "управлять" сообщением Path, направляя его по определенному, явно заданному маршруту. Для того чтобы это стало возможно, протокол RSVP расширяется новым объектом — Explicit Route Object (ERO). Объект переносится в сообщении Path и содержит явно заданный маршрут, по которому должно идти сообщение. Пересылка такого сообщения маршрутизатором определяется не адресом получателя, содержащимся в заголовке IP пакета, а содержанием объекта ERO. Эта функция позволяет автоматически (или в результате действий администратора) ремаршрутизировать LSP в обход аварийных участков, перегруженных областей и узких мест сети. Использование явно заданных маршрутов помогает решать задачи управления трафиком.
Поскольку трафик, проходящий по LSP, определяется меткой, присвоенной во входном
маршрутизаторе, то сточки зрения протокола IPLSP можно считать своеобразным туннелем, находящимся подуровнем IP-маршрутизации. Для поддержки функций такого туннеля в RSVP-TE специфицированы новые С-типы для объектов SESSION, SENDER_TEMPLATE и FILTER_SPEC. Эти новые типы называются LSP_TUNNEL_IPv4 и LSP_TUNNEL_IPv6.
В некоторых приложениях, например, при операциях ремаршрутизации, вызванных обнаружением лучшего маршрута или неисправностями в сети, а также при распределении трафика по нескольким маршрутам, может оказаться полезным создавать ассоциированный набор LSR В приложениях управления трафиком такие наборы называются Traffic Engineered Tunnels или ТЕ-туннели. Для идентификации ТЕ-туннелей используются 2 идентификатора.
Идентификатор туннеля (tunnel ID) является частью объекта SESSION и однозначно определяет ТЕ-туннель. Объекты SENDER_TEMPLATE и FILTER_SPEC несут идентификатор (LSPJD) и, в паре с объектом SESSION, любой из них может однозначно идентифицировать LSP
Чтобы отправитель мог получать информацию о маршруте, по которому проходит LSP, в сообщение Path может включаться объект RECORD_ROUTE. Отправитель может также использовать этот объект для того, чтобы запросить получение уведомлений об изменениях маршрута LSP. Объект RECORD_ROUTE практически аналогичен вектору пути (Path Vector) и поэтому может использоваться для обнаружения закольцованных маршрутов.
В сообщение Path может быть также включен объект SESSION_ATTRIBUTE, который содержит информацию, относящуюся к приоритету данного сеанса создания LSP по отношению к другим текущим сеансам, к защите в системе коммутации, обеспечивающей создание нового маршрута в обход отказавших звеньев, а также к категории срочности данного сеанса. Этот объект может также указывать, должны ли записываться значения меток при записи информации о маршрутах.
Одним из основных требований к управлению трафиком (Traffic Engineering) является возможность изменять маршрут, т.е. ремаршрутизировать ТЕ-туннели согласно некоторым условиям, основанным на административной политике. В общем случае весьма нежелательно перераспределять трафик или оказывать неблагоприятное воздействие на сеть в процессе ремаршрутизации ТЕ-туннелей. Это соображение привело к применению механизма make-before-break (создать новый тракт до уничтожения старого), т.е. механизма, при котором старый тракт продолжает использоваться в то вре-
Рис. 4. Процедура передача информационного трафика в MPLS-VPN
мя, пока создается новый тракт, а после того как он создан, выполняется переключение на новый тракт и затем разрушается старый. Эта методика может применяться во избежание двойного резервирования ресурсов, например как в протоколе RSVP (путем использования фильтров при стиле резервирования Shared-Explicit). Расширение RSVP-TE помогает обойти эти проблемы. Комбинация объекта LSP_TUN-NELSESSION и стиля резервирования SE позволяет плавно увеличивать пропускную способность и производить динамическую маршрутизацию.
Все новые объекты не обязательны для RSVP, но объекты LABEL_REQUEST и LABEL обязательны для RSVP-TE.
MPLS-VPN. В MPLS-VPN существуют два основных потока трафика:
а) поток управления, который включает маршрутную информацию между РЕ и СЕ и между маршрутизаторами РЕ, а также информацию, необходимую для создания LSP между маршрутизаторами;
б) поток данных, т.е. поток информации пользователей.
Проирсс управления созданием LSP-туннелей в сети MPLS включает следующие процедуры:
обмена маршрутной информацией между РЕ и СЕ и между маршрутизаторами РЕ с использованием многопротокольного расширения протокола MP-BGP Маршрутное объявление передается по протоколу MP-BGP только тем маршрутизаторам РЕ, которые записаны в конфигурационных параметрах маршрутизатора-отправителя в качестве соседей;
— создания коммутируемого по меткам тракта LSP с использованием протокола LDP благодаря которому создается топологическая
карта сети и распространяются атрибуты ресурсов;
— создания LSP-туннелей с помощью протоколов RSVP-TE или CR-LDP Использование протокола RSVP позволяет поддерживать заданное качество обслуживания и регулирование трафика.
Процесс передачи трафика пользователя можно разделить на четыре этапа:
— передача потока от СЕ-маршрутизатора источника до входного пограничного маршрутизатора сети провайдера;
— передача информационного потока от РЕ до Р;
— передача трафика по транзитной области MPLS;
—передача потока от выходного маршрутизатора РЕ до маршрутизатора назначения СЕ.
В качестве примера на рис. 4 показана процедура передачи информационного трафика в MPLS-VPN между удаленными пользователями 213.10.2.11 и 208.22.14.8.
Удаленный пользователь 213.10.2.11 отправляет IP-пакет. В первую очередь, этот пакет попадает на сервер доступа AS, реализованный вместе с маршрутизатором СЕ2. Сервер доступа проводит аутентификацию и авторизацию пользователя, после чего по таблице маршрутизации СЕ2 определяет дальнейший путь следования пакета и пересылает его к маршрутизатору РЕ2. При получении IP-пакета РЕ2 обращается к таблице VRF-A и назначает этому пакету метку виртуальной частной сети Lvpn. Далее маршрутизатор обращается к таблице LIB, в которой, в соответствии с требуемым QoS выбирается LSP-туннель. Продвижение пакета по сети провайдера происходит на основании метки верхнего уровня, которой является Lvpn.
Каждый раз, когда пакет проходит очередной маршрутизатор Р вдоль туннеля, метка Lvpn анализируется и заменяется новой. И только после достижения конечной точки LSP-туннеля (маршрутизатора РЕ1) метка Lvpn из стека извлекается.
Дальнейшее продвижение пакета основано на метке LMPLS. В зависимости от ее значения пакет направляется в тот или иной выходной интерфейс маршрутизатора РЕ1: маршрутизатор РЕ1 обращается к таблице VRFVPN-A, связанной с этим интерфейсом, и извлекает запись о маршруте к пункту назначения. Продвижение пакета к маршрутизатору СЕ1 обеспечивается при помощи протокола IP Когда стандартный IP-пакет поступает в маршрутизатор СЕ1, по таблице маршрутизации производится поиск маршрута, и пакет поступает на FW Брандмауэр проводит фильтрацию трафика, поступаю-щзго от провайдера. После фильтрации пакет дешифрируется и поступает к получателю 208.22.14.8.
Следует отметить, что такое сочетание технологий для организации VPN несомненно является эффективным и позволяет построить сеть, поддерживающую множество взятых из VPN дополнительных услуг и реализующую гарантированное качество обслуживания на основе MPLS.
Литература
1. Прокис Дж Цифровая связь. Пер с англ. / Под ред. Д. Д. Кловского. — М.: Радио и связь, 2000. — 241 с.
2. Raniwala A, Gopalan K, Chiueh T. Centralized channel assignment and routing algorithms for multichannel wireless mesh networks. ACM Mobile Computing and Communications Review, 2004, vol. 8, pp. 50-65.
3. RanWda, A. Tzi-cker Chiueh. Architecture and algorithms for an IEEE 802.11-based multi-channel wire-ess mesh network. Proc. of INFOCOM '05, vol. 3, pp. 2223- 2234.
4. Лепков К.Е., Донченко АА Анализ существующих алгоритмов распределения частотного ресурса беспроводньк сетей специального назначе-ния.//Сборник трудов СКФ МТУСИ — 2009. Ростов-на-Дону: СКФ МТУСИ, 2009. С. 50-52.
5. Легков К.Е., Донченко МА Требования к показателям качества информационного обмена в сетях беспроводного широкополосного доступа.// Сборник трудов СКФ МТУСИ — 2009. Ростов-на-Дону: СКФ МТУСИ, 2009. — С. 59-64.
6. Легков К.Е Методы оценки качества информационного обмена в сетях беспроводного широкополосного доступа // Сборник трудов СКФ МТУСИ, 2009. Ростов-на-Дону: СКФ МТУСИ, 2009. — С. 64-68.
