Изобретение относится к области телекоммуникаций и может быть использовано в программно-конфигурируемой сети (ПКС) и коммутаторах на основе протокола OpenFlow для передачи разнородного трафика.
Уровень техники
Современные сетевые компьютерные парадигмы основаны на технологии Ethernet, которая позволяет передавать различный трафик по сети. Для того чтобы классифицировать и разделить передаваемый трафик по сети было введено понятие «качества обслуживания» (Quality of Service, QoS). QoS позволяет передавать разнородный трафик в зависимости от его приоритета.
Однако компьютерные сети развиваются также стремительным образом, как и любой программный продукт. Возникают прорывные и перспективные архитектуры и технологии в компьютерных сетях, которые будут играть значимую роль в будущем. К такой категории компьютерных сетей могут относиться распределенные сети.
Причиной широкого применения и развития распределенных сетей стало ограничение классической компьютерной сети Ethernet по дальнейшим разработкам и вариациям передачи трафика согласно стандарту IEEE 802.1.
Современные требования, предъявляемые к обработке трафика, должны обладать свойствами мобильности, быстроты, упрощения администрирования сетевого оборудования. Все эти требования послужили к возникновению ПКС [US 9215093 B2].
В ПКС сетях выделяют 3 уровня: приложений, управления и инфраструктурный. Основным элементом является контроллер, ведущий обработку трафика и рассчитывающий оптимальные маршруты для передачи трафика в коммутаторы. Обмен трафика производится через протокол OpenFlow [US 9215093 B2].
В ПКС управление и настройка происходит над потоками данных, совокупностью набора кадров. Входящий поток поступает в коммутатор, работающий по протоколу OpenFlow, где выполняется поиск на соответствие набора полей потока в одной из таблиц потоков. Таблица потоков состоит из следующих полей: полей стандарта IEEE 802.1, приоритет, счетчики, инструкции, таймауты [US 9215093 B2]. Как и в обычной сети передается разнородный трафик, который делится в свою очередь на трафик реального времени и обычный (эластичный) трафик.
Недостатком в известном коммуникационном методе [US 9215093 B2] является то, что для работы распределенной компьютерной сети тратятся аппаратные ресурсы на сбор, вычисление и установку таймаутов (hard timeout таймаут на мгновенное удаление кадра из ПКС и idle timeout таймаут в зависимости от длины кадра достижения приемной стороны). Таким образом, в коммутаторах OpenFlow возможно упростить структуру таблиц потоков.
Алгоритм протокола OpenFlow в известном существующем методе [US 9215093 B2] затрачивает значительное увеличение времени поиска правила для потока в таблицах потоков. Недостатком метода является то, что данная ситуация приводит к информированию контроллера о необходимости удаления потока из ПКС на более позднем этапе. Таким образом, необходимо выполнять поиск таймаутов для потока в таблицах потоков, пока не будет найдено нужное правило или будет удален поток из ПКС. В этом случае отсутствует быстрая передача разнородного трафика, поскольку тратятся значительные временные и аппаратные ресурсы для поиска таймаутов потока. Кроме этого, контроллер также может медленно реагировать на сигнал удаления потока из ПКС за счет различных архитектур и топологий ПКС, где возможна целая группа иерархий контроллеров.
В известном коммуникационном методе [US 9356871 B2] отсутствует контроль функций доставки трафика на входных портах коммутаторов OpenFlow. Недостатком является то, что затруднительно определить доставку трафика реального времени получателю в необходимые моменты времени. Возникает необходимость получения трафика реального времени в строго отведенное время, поскольку для конечного пользователя, оборудования критична поздняя доставка трафика реального времени или не доставка данного трафика.
В известном коммуникационном методе [US 2018/0063848 A1] возникает необходимость прерывания эластичного трафика в случае временного конфликта между различными видами трафика в коммутаторе. Недостатком данного метода является то, что данная ситуация способствует к уменьшению пропускной способности сети из-за повторной передачи прерванного эластичного трафика.
Наиболее близким техническим решением является патент US 9215093 B2 «ENCOOING PACKETS FOR TRANSPORT OVER SDN NETWORKS» (прототип). Аналоги: US 9356871 B2 «PROGRAMMABLE MANAGEMENT ENGINE FOR NETWORKS», US 2018/0063848 A1 «USING LTE CONTROL CHANNEL TO SEND OPENFLOW MESSAGE DIRECTLY TO SMALL CELLS TO REDUCE LATENCY IN AN SDN-BASED MULTI-HOP WIRELESS BACKHAUL NETWORK».
Технический результат
Технический результат – уменьшение задержки кадров и потоков в ПКС, повышение пропускной способности сети, снижение количество удаленных кадров из ПКС, исключение временных конфликтов между разнородным трафиком, возможность досрочной передачи эластичного трафика, до наступления времени доставки трафика реального времени.
Краткое описание чертежей
На фиг. 1 показана схема алгоритма функционирования процесса передачи трафика реального времени с использованием планировщика и функцией контроля доставки в ПКС.
На фиг. 2 показан предпочтительный вариант реализации архитектуры коммутатора на основе OpenFlow, выполняющего обработку и передачу разнородного трафика. Основные узлы аппаратной архитектуры: 1 – шина приема кадров из аппаратуры продвижения кадров в порт назначения коммутатора; 2 – валидатор времени доставки трафика; 3 – планировщик расписания трафика реального времени; 4 – таблица потоков 0; 5 – классификатор поступающего трафика и канал прямой записи в память; 6 – таблица потоков N; 7 – шина чтения кадров из очередей; 8 – шина передачи кадров в очередь или на выходной порт; 9 – процессор диспетчеризации; 10 – сигнал «очереди свободны»; 11 – память типа FIFO для приема эластичного трафика; 12 – память типа FIFO для приема трафика реального времени; 13 – дешифратор инструкций коммутатора OpenFlow; 14 – канал прямого чтения кадров из очередей или шины передачи кадров на выходной порт; 15 – физический интерфейс выходного порта; 16 – сигнал «выходной порт свободен»; 17 – шина выходного канала; 18 – контроллер ПКС.
На фиг. 3 показана структура планировщика трафика, состоящая из следующих узлов: таблицы расписания планировщика, измененного узла классификации разнородного трафика и узел валидации времени доставки трафика реального времени.
На фиг. 4 показаны временные диаграммы работы коммутатора по протоколу OpenFlow в ПКС предложенным способом при передаче разнородного трафика: РВ – трафик реального времени и ЭТ – обычный (эластичный) трафик. Где фиг. 4а показывает работу системы в случае, когда текущий момент передачи РВ-кадра равен сравниваемому моменту доставки РВ-кадра в таблице расписания планировщика трафика; фиг. 4б показывает работу системы в случае, когда текущий момент передачи РВ-кадра больше сравниваемого момента доставки РВ-кадра в таблице расписания планировщика трафика, такой РВ-кадр удаляется из ПКС и информируется контроллер о повторной передаче; фиг. 4в показывает работу системы в случае, когда текущий момент передачи РВ-кадра меньше сравниваемого момента доставки РВ-кадра в таблице расписания планировщика трафика, тогда проверяется в зависимости от длины ЭТ-кадра возможность его передачи до момента доставки РВ-кадра и снятия блокировки.
Подробное описание изобретения
Вводится аппаратный планировщик трафика в каждый коммутатор ПКС, который обеспечивает своевременную доставку трафика пользователю или конечному оборудованию. Он управляет и контролирует входящий трафик. Рассылка и настройка расписания выполняется на уровне приложения через интерфейсы и функции ПКС.
Реализация алгоритма функционирования процесса передачи трафика реального времени с использованием планировщика и функцией контроля доставки в ПКС заключается в выполнении следующих действий:
1. При запуске системы должно быть выполнено начальная инициализация и конфигурирование, заключающееся в задании планировщика трафика каждому сетевому узлу и задании временных параметров подстройки трафика реального времени.
2. Контроллер выполняет рассылку расписания планировщика трафика каждому сетевому узлу.
3. Поток трафика направляется через входящий порт коммутатора OpenFlow к таблицам потоков.
4. В таблице потоков выполняется поиск правила для потока, при этом некоторые поля найденного правила могут быть замаскированы. В случае если не найдено правило для потока в заданной таблице, то он переходит в следующую подсеть таблицы потоков N, где происходит дальнейший поиск и сравнение с правилами в следующих таблицах.
5. После поиска во всех таблицах потоков, если для входящего потока так и не будет обнаружено правило, такой поток удаляется из сети и информируется контроллер об этом.
6. В случае успешного поиска правила для потока включается в работу планировщик расписания трафика.
7. Планировщик расписания классифицирует принятый поток в зависимости от типа трафика: трафик реального времени или эластичный трафик. При этом для каждого потока трафика реального времени фиксируется время прибытия в коммутаторе OpenFlow.
8. Поток реального времени направляется в узел валидатора времени доставки потока, где сравнивается время прибытия потока с заранее установленным значением момента его доставки из расписания.
9. Если время прибытия потока будет позже заранее известного времени из расписания, валидатор времени доставки может удалить поток реального времени.
10. Если текущий момент поступления потока реального времени равен значению времени доставки в расписании, тогда выполняется передача принятого потока реального времени в выходной порт. В случае если текущий момент поступления потока реального времени меньше значения времени доставки в расписании, то поток реального времени помещается в отдельную очередь.
11. Поток эластичного трафика помещается в отдельные очереди с помощью узла классификации и приоритета потока.
12. Валидатор времени доставки с помощью таймера определяет наступление очередного момента времени доставки для потока реального времени. Если время доставки не наступило, то управление передается диспетчеру очередей.
13. Диспетчер очередей начинает работать только при наличии свободного выходного канала и не пустыми очередями, связанными с потоками трафика. Входящими параметрами для диспетчера очередей являются размер потока и время помещения потока в очередь для каждого из видов трафика.
14. Диспетчер проверяет возможность передачи потока эластичного трафика, прежде чем наступит момент доставки очередного потока реального времени:
ТТЕК + ТЭТ ≤ ТБЛ + ТРВ,
где ТТЕК – текущее время в системе, ТЭТ – время передачи эластичного трафика с учетом его длины, ТБЛ – время блокировки, ТРВ – время передачи трафика реального времени.
возможность передачи ЭТ-трафика определяется исходя из следующего условия: текущий момент времени системы и длина ЭТ-трафика должны быть меньше наступления момента доставки очередного РВ-трафика, то:
1) запускается передача ЭТ-трафика из выбранной очереди в выходной канал;
2) иначе ожидается момент доставки очередного РВ-трафика, и когда он наступает, осуществляется передача очередного РВ-трафика из выбранной очереди в выходной канал;
15. Выполняется переход к п.1 и снова осуществляется передача потока трафика в ПКС.
Функционирование предпочтительного устройства, реализующего предложенный метод процесса передачи трафика реального времени с использованием планировщика и функцией контроля доставки, представлено ниже.
По шине 1 поступают потоки (кадры) из аппаратуры продвижения кадров в порт назначения коммутатора OpenFlow, которые могут быть направлены в данный порт.
Выполняется поиск правила для входящего потока во всех таблицах потоков. Таблиц потоков может быть несколько от 0 до N. Вначале выполняется поиск правила в таблице потоков 0 (на рис. 3 узел 4), затем далее в таблице потоков N (на рис. 3 узел 6). Если для входящего потока не будет обнаружено правило, то информация передается дешифратору инструкций коммутатора OpenFlow 13. Дешифратор инструкций совместно с контроллером ПКС 18 принимает решение об удалении потока из ПКС. В случае успешного поиска правила включается в работу планировщик расписания трафика 3.
Текущий момент поступления трафика реального времени сравнивается с моментом доставки в планировщике расписания 3. Контроль и сравнение времени прибытия потока с заранее установленным значением момента его доставки из расписания выполняет валидатор времени доставки потока 2.
Основными элементами узла 2 являются управляющая логика и таймер сравнения времени. Планировщик расписания представляет собой регистровую память (набор регистров), в которой хранятся таблицы расписаний со значениями моментов доставки трафика реального времени. Каждый коммутатор OpenFlow должен содержать свой планировщик расписания.
Планировщик расписания может обрабатывать следующие ситуации: передавать эластичный трафик в классификатор 5; поместить трафик реального времени в очередь для данного трафика (текущий момент прибытия трафика реального меньше момента его доставки); направить трафик реального времени сразу же в выходной канал 17 (текущий момент прибытия трафика реального меньше равен моменту его доставки). За выполнение инструкций отвечает дешифратор инструкций коммутатора 13 согласно протоколу OpenFlow.
Классификатор 5 разделяет эластичные потоки в зависимости от типа трафика и помещает в соответствующую очередь (очереди) эластичного трафика.
Потоки записываются по шине 8, а считываются из очередей по шине 7. Валидатор времени доставки потока 2 постоянно проверяет наступление момента доставки трафика реального времени и передает управление процессору диспетчеризации 9. Он запускается сигналами 8 и 13, когда очереди не пусты и выходной канал свободен. Осуществляется передача кадров в выходной канал через дешифратор инструкций 13.
Функционирование временных диаграмм предпочтительного устройства реализующего предложенный способ заключается в следующем.
Текущий момент поступления РВ-кадра сравнивается с моментом доставки данного РВ-трафика в таблице расписании планировщика трафика (ПЛ), и:
1) если оба момента равны (tРВ= tПЛ), то РВ-кадр передается сразу же в выходной канал;
2) если момент поступления РВ-кадра больше момента доставки в расписании (tРВ> tПЛ), то РВ-кадр удаляется из ПКС и информируется контроллер ПКС;
3) если момент поступления РВ-кадра меньше момента доставки в расписании (tРВ<tПЛ), то проверяется возможность передачи ЭТ-кадра: текущий момент времени системы и длина ЭТ-кадра должны быть меньше наступления момента доставки РВ-кадра (tБЛ> tЭТ2), тогда осуществляется передача ЭТ-кадра, иначе когда (tБЛ< tЭТ3), то ЭТ-кадр передается только после передачи РВ-кадра.
Изобретение относится к области телекоммуникаций. Технический результат заключается в уменьшении задержки кадров и потоков в ПКС, повышении пропускной способности сети, снижении количества удаленных кадров из ПКС, исключении временных конфликтов между разнородным трафиком, возможности досрочной передачи эластичного трафика, до наступления времени доставки трафика реального времени. Способ реализует передачу разнородного трафика, в котором есть множество сетевых устройств, таких как контроллер и коммутаторы, работающие по протоколу OpenFlow, которые обеспечивают пересылку между узлами трафик реального времени РВ и эластичный трафик ЭТ, кадры трафика имеют различные поля заголовка, причем кадры трафика реального времени в заголовке содержат указатель на время отправки кадра, эластичный трафик передается стандартным образом в коммутаторах OpenFlow. Коммутатор OpenFlow обеспечивает доставку РВ-трафика получателю в заранее назначенные моменты времени по расписанию из планировщика трафика, при этом расписание устанавливается заранее для каждого коммутатора на уровне приложения ПКС через интерфейсы и функции сети. 11 з.п. ф-лы, 6 ил.
1. Способ процесса передачи трафика реального времени с использованием планировщика и функцией контроля доставки в ПКС, реализующий передачу разнородного трафика, в котором есть множество сетевых устройств, таких как контроллер и коммутаторы, работающие по протоколу OpenFlow, которые обеспечивают пересылку между узлами трафик реального времени РВ и эластичный трафик ЭТ, кадры трафика имеют различные поля заголовка, причем кадры трафика реального времени в заголовке содержат указатель на время отправки кадра, эластичный трафик передается стандартным образом в коммутаторах OpenFlow, отличающийся тем, коммутатор OpenFlow обеспечивает доставку РВ-трафика получателю в заранее назначенные моменты времени по расписанию из планировщика трафика, при этом расписание устанавливается заранее для каждого коммутатора на уровне приложения ПКС через интерфейсы и функции сети.
2. Способ по п.1, отличающийся тем, что вводится аппаратный планировщик трафика в каждый коммутатор ПКС, который обеспечивает своевременную доставку трафика пользователю или конечному оборудованию, планировщик управляет и контролирует входящий трафик.
3. Способ по п.1, отличающийся тем, что упрощаются аппаратные ресурсы на сбор, вычисление и установку таймаутов, данные поля удаляются из структуры таблиц потоков в коммутаторах OpenFlow.
4. Способ по п.1, отличающийся тем, что классификация принятого потока выполняется в составе планировщика расписания в зависимости от типа трафика согласно полю качества обслуживания в формате кадров потока и подразделяется на трафик реального времени и эластичный трафик, при этом для каждого потока трафика реального времени фиксируется время прибытия в коммутаторе OpenFlow.
5. Способ по п.1, отличающийся тем, что направление потока реального времени осуществляется узлом валидатора времени доставки потока, где сравнивается время прибытия потока с заранее установленным значением момента его доставки из расписания и выполняются следующие действия: удаление потока реального времени, если время прибытия потока позже заранее известного времени из расписания валидатором времени доставки; передача принятого потока реального времени в выходной порт, если текущий момент поступления потока реального времени равен значению времени доставки в расписании; перемещение потока реального времени в отдельную очередь, если текущий момент поступления потока реального времени меньше значения времени доставки в расписании.
6. Способ по п.1, отличающийся тем, что перемещается поток эластичного трафика в отдельные очереди с помощью узла классификации и приоритета потока.
7. Способ по п.1, отличающийся тем, что принятый коммутатором OpenFlow поток продвигается в выходной порт назначения, где классифицируется по типу трафика, кадры ЭТ-трафика и РВ-трафика помещаются в отдельные буферы, при этом фиксируется момент поступления каждого РВ-потока, значение которого сравнивается с установленным значением момента его доставки расписанием и в случае прибытия потока позже заранее известного времени, зависимого от времени доставки, он помечается как некорректный.
8. Способ по п.1, отличающийся тем, что для каждого выходного порта коммутатора OpenFlow контролируется время доставки поступивших в него РВ-кадров и при достижении локального времени временного окна, определяемого соответствующим расписанием в планировщике трафика, выполняется передача буферизируемого РВ-трафика.
9. Способ по п.1, отличающийся тем, что для каждого момента доставки РВ-кадров, указанных в расписании из планировщика трафика, вычисляется время блокировки начала передачи ЭТ-кадров, величина которого определяется максимальной длиной ЭТ-кадра, при этом очередная блокировка снимается после передачи очередного корректного РВ-кадра, в случае некорректного РВ-кадра блокировка снимается при окончании специального окна или отсутствия поступления очередного РВ-кадра.
10. Способ по п.1, отличающийся тем, что определение наступления очередного момента времени доставки для потока реального времени валидатором времени доставки осуществляется с помощью таймера и далее управление передается диспетчеру очередей, причем диспетчер очередей начинает работать только при наличии свободного выходного канала и не пустыми очередями, связанными с потоками трафика, где входящими параметрами для диспетчера очередей являются размер потока и время помещения потока в очередь для каждого из видов трафика.
11. Способ по п.1, отличающийся тем, что проверка возможности передачи потока эластичного трафика диспетчером очередей происходит, исходя из условия, что сумма текущего момента времени системы и времени передачи эластичного трафика с учетом его длины должна быть меньше наступления момента доставки очередного трафика реального времени, то происходит запуск передачи эластичного трафика из выбранной очереди в выходной канал, иначе ожидание момента доставки очередного трафика реального времени, и когда он наступает, осуществляется передача очередного трафика реального времени из выбранной очереди в выходной канал.
12. Способ по п.1, отличающийся тем, что некорректные РВ-кадры удаляются из ПКС и информируется контроллер сети.
| US 20140119367 A1, 01.05.2014 | |||
| US 20150281085 A1, 01.10.2015 | |||
| US 20180063848 A1, 01.03.2018 | |||
| US 20140280834 A1, 18.09.2014 | |||
| Система и способ выявления проблем функционирования сервисов в сети передачи данных, содержащей виртуальные машины | 2019 |
|
RU2748963C2 |
