Базовые контроллеры для преобразования универсальных потоков

Изобретение относится к сетевой системе управления. Технический результат изобретения заключается в генерировании данных физической плоскости управления для управления первым и вторым управляемыми элементами продвижения данных, которые реализуют операции продвижения данных, связанные с первой совокупностью логических информационных каналов. Система содержит первый экземпляр контроллера для преобразования данных логической плоскости управления первой совокупности логических информационных каналов в данные универсальной плоскости физического управления (UPCP). Система также содержит второй экземпляр контроллера для преобразования данных UPCP в данные заказной плоскости физического управления (СРСР) для первого управляемого элемента продвижения данных, но не для второго управляемого элемента продвижения данных. Система также содержит третий экземпляр контроллера для получения данных UPCP, сгенерированных первым экземпляром контроллера, идентифицирующих второй экземпляр контроллера в качестве экземпляра контроллера, ответственного за генерацию данных СРСР для первого управляемого элемента продвижения данных, и подающего полученные данные UPCP на второй экземпляр контроллера. 2 н. и 18 з.п. ф-лы, 25 ил.

 

ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ

Многие современные предприятия имеют большие и сложные сети, содержащие переключатели, концентраторы, серверы, рабочие станции и другие сетевые устройства, которые поддерживают самые различные соединения, прикладные задачи и системы. Все возрастающая сложность компьютерных сетей, включая виртуальную миграцию сетевых станций, динамические рабочие нагрузки, множественную принадлежность и определяемые потребителями конфигурации качества обслуживания и защиты, требуют улучшенной парадигмы сетевого управления. Традиционно сети управлялись посредством низкоуровневой конфигурации отдельных компонентов. Сетевые конфигурации часто зависят от базовой сети: например, блокировка доступа пользователя входным сообщением списка контроля доступом ("ACL") требует знания текущего IP-адреса пользователя. Более сложные задачи требуют более обширных сетевых знаний: принуждение графика порта 80 пользователя - гостя переходить на агента HTTP требует знания текущей топологии сети и положения каждого гостя. Этот процесс является процессом повышенной трудности, где сетевые коммутаторы совместно используются многими пользователями.

Ответом на это является все усиливающееся движение по направлению к новой парадигме сетевого управления, получившей название "программно определяемая сеть" (SDN). В парадигме SDN сетевой контроллер, исполняемый на одном или более серверов в сети, управляет, поддерживает и реализует управляющую логику, которая определяет поведение продвижения данных разделенных переключающих элементов сети, ориентируясь на каждого пользователя. Принятие решений по управлению сетью часто требует знания состояния сети. Для упрощения принятия управляющих решений сетевой контроллер создает и поддерживает обзор состояния сети и предоставляет интерфейс прикладного программирования, через который управляющие приложения могут получать доступ к обзору состояния сети.

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

КРАТКОЕ ИЗЛОЖЕНИЕ ИЗОБРЕТЕНИЯ

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

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

В некоторых примерах осуществления, каждый экземпляр контроллера является устройством (например, универсальным компьютером), которое исполняет один или более модулей, преобразующих входные данные пользователя из данных логической плоскости управления (LCP) в данные логической плоскости продвижения данных (LFP), а затем преобразует данные LFP в данные плоскости физического управления (РСР). Эти модули в некоторых примерах осуществления содержат модуль управления и модуль виртуализации. Модуль управления предоставляет пользователю возможность специфицировать и наполнять совокупность логических информационных каналов (LDPS), в то время как модуль виртуализации реализует заданную LDPS отображением LDPS на физическую переключающую инфраструктуру. В некоторых примерах осуществления, модули управления и виртуализации являются двумя различными приложениями, в то время как в других примерах осуществления они являются частью одного и того же приложения.

В некоторых примерах осуществления, модуль управления контроллера получает от пользователя или другого источника данные LCP (например, данные, которые описывают соединения, относящиеся к логическому переключающему элементу), которые описывают LDPS. Затем модуль управления преобразует эти данные в данные LFP, которые затем передаются на модуль виртуализации. Затем модуль виртуализации генерирует данные РСР из данных LFP. Данные РСР распространяются на управляемые переключающие элементы. В некоторых примерах осуществления, модули управления и виртуализации используют механизм nLog для генерации данных LFP из данных РСР и данных РСР из данных LFP.

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг. 1 - иллюстрирует виртуализированную сетевую систему некоторых примеров осуществления изобретения.

Фиг. 2 - иллюстрирует инфраструктуру переключения многопользовательской системы хостинга.

Фиг. 3 - иллюстрирует сетевой контроллер, который управляет концевыми переключающими элементами.

Фиг. 4 - иллюстрирует пример многих логических переключающих элементов, реализованных как совокупность переключающих элементов.

Фиг. 5 - иллюстрирует прохождение команд управления управляемым переключающим элементом через различные обрабатывающие слои экземпляров контроллеров.

Фиг. 6 - иллюстрирует распределенную сетевую систему управления некоторых примеров осуществления с многими экземплярами контроллеров.

Фиг. 7 - иллюстрирует пример специфицирования экземпляра задающего контроллера переключающего элемента.

Фиг. 8 - иллюстрирует пример работы нескольких экземпляров контроллеров.

Фиг. 9 - концептуально иллюстрирует программную архитектуру приложения трансляции входных данных.

Фиг. 10 - иллюстрирует приложение управления некоторых примеров осуществления изобретения.

Фиг. 11 - иллюстрирует приложение виртуализации некоторых примеров осуществления изобретения.

Фиг. 12 - концептуально иллюстрирует различные таблицы в таблицах выходных данных RE.

Фиг. 13 - иллюстрирует упрощенное изображение операций отображения таблиц приложений управления и виртуализации некоторых примеров осуществления изобретения.

Фиг. 14 - иллюстрирует пример интегрированного приложения.

Фиг. 15 - иллюстрирует другой пример такого интегрированного приложения.

Фиг. 16 - концептуально иллюстрирует пример архитектуры сетевой системы управления.

Фиг. 17 - концептуально иллюстрирует пример архитектуры сетевой системы управления.

Фиг. 18 - иллюстрирует пример архитектуры приложения базового управления.

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

Фиг. 20 - концептуально иллюстрирует процесс, который выполняют некоторые примеры осуществления для генерации из данных универсальной плоскости физического управления данных заказной плоскости физического управления.

Фиг. 21 - концептуально иллюстрирует процесс, который выполняют некоторые примеры осуществления для генерации заказных команд туннельного потока и пересылки этих заказных команд к управляемому переключающему элементу.

Фиг. 22 - концептуально иллюстрирует в семи различных этапах пример работы базового контроллера, который транслирует универсальные команды туннельного потока в заказные команды.

Фиг. 23 - концептуально иллюстрирует электронную систему, на которой реализуются некоторые примеры осуществления изобретения.

ПОДРОБНОЕ ОПИСАНИЕ

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

Некоторые примеры осуществления изобретения предоставляют сетевую систему управления, которая обеспечивает возможность специфицирования нескольких различных совокупностей LDP для нескольких различных пользователей через один или более совместно используемых элементов продвижения данных, не позволяя различным пользователям управлять логикой продвижения данных друг друга или даже просматривать ее. Совместно используемые элементы продвижения данных в некоторых примерах осуществления могут содержать виртуальные или физические сетевые переключатели, программные переключатели (например. Open vSwitch), маршрутизаторы и/или другие переключающие устройства, а также любые другие сетевые элементы (такие как выравниватели нагрузки и пр.), которые устанавливают соединения между этими переключателями, маршрутизаторами и/или другими переключающими устройствами. Такие элементы продвижения данных (например, физические переключатели или маршрутизаторы) также именуются ниже как переключающие элементы. В отличие от серийно выпускаемых переключателей, программный элемент продвижения данных является переключающим элементом, который в некоторых примерах осуществления образуется хранением его таблицы (таблиц) переключения и логики в памяти автономного устройства (например, автономного компьютера), в то время как в других примерах осуществления он является переключающим элементом, который образуется хранением его таблицы (таблиц) переключения и логики в памяти устройства (например, компьютера), который также исполняет гипервизор и одну или более виртуальных машин на верхнем уровне этого гипервизора.

Эти управляемые, совместно используемые переключающие элементы именуются ниже как управляемые переключающие элементы или управляемые элементы продвижения данных, поскольку они управляются сетевой системой управления для реализации совокупностей LDP. В некоторых примерах осуществления, система управления управляет этими переключающими элементами помещением в них данных РСР, как будет описано далее. Переключающие элементы в общем случае получают данные (например, пакет данных) и исполняют одну или более операций обработки на этих данных, таких как отбрасывание принятого пакета данных, пересылка пакета, который получен от одного из исходных устройств, на другое назначенное устройство, обработка пакета и затем пересылка его на назначенное устройство и прочее. В некоторых примерах осуществления, данные РСР, которые помещаются в переключающий элемент, преобразуются этим переключающим элементом (например, универсальным процессором переключающего элемента) в данные физической плоскости продвижения данных, которые определяют, как переключающий элемент (например, как специализированная переключающая схема переключающего элемента) обрабатывает пакеты данных, которые он получил.

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

В некоторых примерах осуществления, каждый экземпляр контроллера является устройством (например, универсальным компьютером), которое исполняет один или более модулей, преобразующих входные данные пользователя из LCP в LFP, а затем преобразующих данные LFP в данные РСР. Эти модули в некоторых примерах осуществления содержат модуль управления и модуль виртуализации. Модуль управления дает пользователю возможность специфицировать и наполнять LDPS, в то время как модуль виртуализации реализует специфицированную LDPS отображением LDPS на физическую переключающую инфраструктуру. В некоторых примерах осуществления, модули управления и виртуализации выражают специфицированные или отображенные данные в терминах записей, которые представлены в структуре данных реляционной базы данных. То есть, структура данных реляционной базы данных хранит как входные данные логического информационного канала, полученные через модуль управления, так и физические данные, на которые модулем виртуализации отображены входные данные логического информационного канала. В некоторых примерах осуществления, приложения управления и виртуализации являются двумя различными приложениями, в то время как в других примерах осуществления они являются частью одного и того же приложения.

Выше описано несколько примеров сетевой системы управления. Несколько более подробных примеров осуществления описаны ниже. Раздел I описывает сетевую систему управления некоторых примеров осуществления. В Разделе II следует описание преобразования универсального состояния продвижения данных сетевой системой управления. Раздел III описывает электронную систему, на которой реализованы некоторые примеры осуществления изобретения.

I. СЕТЕВАЯ СИСТЕМА УПРАВЛЕНИЯ

А. Внешние слои для продвижения потоков на слой управления

На Фиг. 1 показывается виртуализированная сетевая система 100 некоторых примеров осуществления изобретения. Эта система предоставляет многим пользователям возможность создавать и управлять многими различными совокупностями LDP на совместно используемой совокупности переключающих элементов сетевой инфраструктуры (например, переключателей, виртуальных переключателей, программных переключателей и проч.). Это позволяет пользователю создавать и управлять пользовательским набором совокупностей логических информационных каналов (LDP) (то есть, переключающей логикой пользователя), система не дает пользователю возможность прямого доступа к совокупности LDP другого пользователя с целью просмотра или модификации переключающей логики другого пользователя. Однако система действительно позволяет различным пользователям пропускать друг к другу пакеты через их виртуализированную переключающую логику, если эти пользователи желают иметь такую связь.

Как показывается на Фиг. 1, система 100 содержит один или более переключающих элементов 105 и сетевой контроллер 110. Переключающие элементы содержат N переключающих устройств (где N является числом равным единице или более), которые образуют переключающие элементы сетевой инфраструктуры системы 100. В некоторых примерах осуществления, переключающие элементы сетевой инфраструктуры содержат виртуальные или физические сетевые переключатели, программные переключатели (например. Open vSwitch), маршрутизаторы и/или другие переключающие устройства, а также любые другие сетевые элементы (такие как балансировщики нагрузки и пр.), которые устанавливают соединения между этими переключателями, маршрутизаторами и/или другими переключающими устройствами. Все такие переключающие элементы сетевой инфраструктуры именуются далее как переключающие элементы или элементы продвижения данных.

Виртуальные или физические переключающие устройства 105 обычно содержат управляющую логику переключения 125 и логику переключения продвижения данных 130. В некоторых примерах осуществления, управляющая логика переключения 125 определяет (1) правила, которые должны применяться к входящим пакетам, (2) пакеты, которые будут отброшены, и (3) способы обработки пакетов, которые будут применены к входящим пакетам. Виртуальные или физические переключающие элементы 105 используют управляющую логику 125 для наполнения таблиц, руководящей логикой продвижения данных 130. Логика продвижения данных 130 осуществляет операции просмотра входящих пакетов и направляет входящие пакеты по адресам назначения.

Как также показывается на Фиг. 1, сетевой контроллер 110 содержит приложение управления 115, посредством которого логика переключения специфицируется для одного или более пользователей (например, для одного или более администраторов или пользователей) в терминах совокупностей LDP. Сетевой контроллер 110 содержит также приложение виртуализации 120, которое преобразует совокупности LDP в управляющую логику переключения, передаваемую на переключающие устройства 105. В этой заявке приложение управления и приложение виртуализации именуются для некоторых примеров осуществления как " механизм управления" и "механизм виртуализации".

В некоторых примерах осуществления, виртуализированная система 100 содержит более одного сетевого контроллера 110. Сетевые контроллеры содержат логические контроллеры, каждый из которых ответственен за специфицирование управляющей логики совокупности переключающих устройств для определенной LDPS. Сетевые контроллеры содержат также физические контроллеры, каждый из которых направляет управляющую логику к совокупности переключающих элементов, за управление которыми ответственен физический контроллер. Иными словами, логический контроллер специфицирует управляющую логику только для совокупности переключающих элементов, которые реализуют определенную LDPS, в то время как физический контроллер направляет управляющую логику на переключающие элементы, которыми управляет физический контроллер, безотносительно к тем совокупностям LDP, которые реализуют переключающие элементы.

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

В некоторых примерах осуществления, структура данных реляционной базы данных является сердцевиной модели управления в виртуализированной сетевой системе 100. При одном из подходов, приложения управляют сетью считыванием из структуры данных реляционной базы данных и записью в нее. В частности, в некоторых примерах осуществления, логика приложения управления может (1) считывать текущее состояние, относящееся к записям входных сетевых сообщений в структуре данных реляционной базы данных и (2) изменять состояние сети исполнением операций на этих записях. При такой модели, когда приложению виртуализации 120 необходимо модифицировать запись в таблице (например, в таблице потока плоскости управления) переключающего элемента 105, то приложение виртуализации 120 сначала записывает одну или более записей, которые представляют таблицу, в структуру данных реляционной базы данных. Затем приложение виртуализации переносит это изменение на таблицу переключающего элемента.

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

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

В некоторых примерах осуществления, операционная система (не показана) экземпляра контроллера предоставляет совокупность различных структурных компонентов связи (не показаны) для приложений управления и виртуализации и переключающих элементов 105 различных примеров осуществления. Например, в некоторых примерах осуществления, операционная система предоставляет управляемый переключающий элемент с интерфейсом связи (не показан) между (1) переключающими элементами 105, которые выполняют физическое переключение для любого из пользователей, и (2) приложением виртуализации 120, которое используется для продвижения переключающей логики пользователей к переключающим элементам. В некоторых из этих примерах осуществления приложение виртуализации руководит управляющей логикой переключения 125 переключающего элемента через широко известный интерфейс доступа с переключением, которая специфицирует совокупности API, позволяя внешнему приложению (такому как приложение виртуализации) управлять выполняемыми функциями переключающего элемента в плоскости управления. В частности, управляемый переключающий элемент реализует интерфейс связи совокупности API так, что приложение виртуализации может посылать записи, хранимые в структуре данных реляционной базы данных, на переключающие элементы, используя интерфейс связи управляемого переключающего элемента.

Двумя примерами таких известных интерфейсов доступа с переключением является интерфейс OpenFlow и интерфейс связи Open Virtual Switch, которые описаны соответственно в следующих статьях: McKeown, N. (2008). OpenFlow: Enabling Innovation in Campus Networks (которая может быть найдена из http://www.openflowswitch.org//documents/openflow-wp-latest.pdf) и Pettit, J. (2010). Virtual Switching in an Era of Advanced Edges (которая может быть найдена из http://openswitch.org/papers/dccaves2010.pdf). Эти две статьи введены здесь ссылками.

Следует заметить, что для этих примеров осуществления, описанных выше и ниже, где для хранения записей данных используется структура данных реляционной базы данных, структура данных, которая может хранить данные в форме объектов объект-ориентированных данных, может быть использована альтернативно или совместно. Примером такой структуры данных является структура данных NIB. Несколько примеров использования структуры данных NIB описаны в заявках на патенты США 13/177,529 и 13/177,533, обе поданные 6 июля 2011 г. Заявки на патенты США 13/177,529 и 13/177,533 введены здесь ссылками.

На Фиг. 1 концептуально иллюстрируется применение API доступа с переключением изображением пунктиров 135 вокруг управляющей логики переключения 125. Через эти API приложение виртуализации может считывать и записывать входные сообщения в таблицы потока плоскости управления. Связанность приложения виртуализации с ресурсами плоскости управления переключающих элементов (то есть, с таблицами плоскости управления) реализуется в некоторых примерах осуществления внутри диапазона (то есть, сетевым графиком, управляемым операционной системой), в то время как в других примерах осуществления это реализуется вне диапазона (то есть, через отдельную физическую сеть). К выбранному механизму, помимо нечувствительности к отказам и принципиальной связанности с операционной системой, предъявляются только минимальные требования, и таким образом при использовании отдельной сети будет достаточно стандартного протокола IGP, такого как IS-IS или OSPF.

Для определения управляющей логики переключения 125 переключающих элементов, когда эти переключающие элементы являются физическими переключающими элементами (в противоположность программным переключающим элементам), приложение виртуализации некоторых примеров осуществления использует протокол Open Virtual Switch для создания одной или более управляющих таблиц в плоскости управления переключающего элемента. Плоскость управления обычно создается и исполняется универсальным ЦП переключающего элемента. Как только система создала таблицу (таблицы) управления, приложение виртуализации записывает затем потоковые входные сообщения в управляющую таблицу (таблицы), используя протокол OpenFlow. Универсальный ЦП физического переключающего элемента использует его внутреннюю логику для преобразования входных сообщений, записанных в управляющей таблице (таблицах), для наполнения одной или более таблиц продвижения данных в плоскости продвижения данных переключающего элемента. Таблицы продвижения данных создаются и исполняются обычно специализированным переключающим чипом переключающего элемента. Переключающий чип переключающего элемента, исполняя потоковые входные сообщения в таблицах продвижения данных, может обрабатывать и маршрутизировать пакеты данных, которые он принимает.

В некоторых примерах осуществления, виртуализированная сетевая система 100 дополнительно к логическим и физическим контроллерам содержит базовый контроллер. В этих примерах осуществления, базовый контроллер реализует несколько API доступа с переключением для управления определенным переключающим элементом. То есть, базовый контроллер является именно тем контроллером, который пересылает управляющую логику на определенный переключающий элемент. Физический контроллер в этих примерах осуществления функционирует как точка агрегации для передачи управляющей логики от логических контроллеров на базовые контроллеры, устанавливая связь с совокупностью переключающих элементов, за которые ответственен этот физический контроллер. Физический контроллер распределяет управляющую логику на базовые контроллеры, управляющие совокупностью переключающих элементов. В этих примерах осуществления, управляемый переключающий элемент служит средством связи, посредством которого операционная система сетевого контроллера устанавливает канал связи (например, канал удаленного вызова процедуры (RPC)) между физическим контроллером и базовым контроллером, так что физический контроллер может пересылать управляющую логику, хранимую в виде записей данных в структуре данных реляционной базы данных, на базовый контроллер. Базовый контроллер будет, в свою очередь, продвигать управляющую логику к переключающему элементу, используя несколько API доступа с переключением или другие протоколы.

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

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

В. Продвижение потоков к концевым переключающим элементам

Как было упомянуто выше, структура данных реляционной базы данных в некоторых примерах осуществления хранит данные, касающиеся каждого переключающего элемента в сетевой инфраструктуре системы, в то время как в других примерах осуществления, структура данных реляционной базы данных хранит только информацию состояния переключающих элементов на конце сетевой инфраструктуры. На Фиг. 2 и Фиг. 3 иллюстрируется пример, который разграничивает эти два различных подхода. В частности, на Фиг. 2 иллюстрируется переключающая инфраструктура многопользовательской системы хостинга. В этой системе шесть переключающих элементов используются для соединения между собой шести сетевых станций двух пользователей А и В. Четыре из этих переключающих элементов 205-220 являются концевыми переключающими элементами, которые имеют прямые соединения с сетевыми станциями 235-260 пользователей А и В, в то время как два переключающих элемента 225 и 230 являются внутренними переключающими элементами (то есть, не концевыми переключающими элементами), которые соединяют между собой концевые переключающие элементы и соединяются друг с другом. Все переключающие элементы, показанные на этих рисунках и описанные выше и ниже, могут быть программными переключающими элементами в некоторых примерах осуществления, в то время как в других примерах осуществления переключающие элементы являются смесью программных и физических переключающих элементов. Например, концевые переключающие элементы 205-220, а также не концевые переключающие элементы 225-230 являются в некоторых примерах осуществления программными переключающими элементами. Также "сетевые станции", описанные в этой заявке, включают виртуальные сетевые станции и физические сетевые станции, такие как вычислительные устройства.

На Фиг. 3 иллюстрируется сетевой контроллер 300, который управляет концевыми переключающими элементами 205-220. Сетевой контроллер 300 аналогичен сетевому контроллеру 110, описанному выше со ссылками на Фиг. 1. Как показывается на Фиг. 3, контроллер 300 содержит приложение управления и приложение виртуализации 310. Операционная система экземпляра контроллера 300 поддерживает структуру данных реляционной базы данных (не показана), которая содержит записи данных, касающихся только концевых переключающих элементов 205-220. Кроме того, приложения 305 и 310, исполняемые на верхнем уровне операционной системы, предоставляют пользователям А и В возможность модифицировать конфигурации переключающих элементов, которые они используют. Затем сетевой контроллер 300 распространяет, если необходимо, эти модификации на концевые переключающие элементы. В частности, в этом примере два концевых переключающих элемента 205 и 220 используются сетевыми станциями обоих пользователей А и В, в то время как концевой переключающий элемент 210 используется только сетевой станцией 245 пользователя А, а концевой переключающий элемент 215 используется только сетевой станцией 250 пользователя В. Соответственно, на Фиг. 3 иллюстрируется сетевой контроллер 300, модифицирующий записи пользователей А и В в переключающих элементах 205 и 220, но только обновляя записи пользователя А в переключающем элементе 210 и только записи пользователя В в переключающем элементе 215.

Контроллер 300 некоторых примеров осуществления управляет только концевыми переключающими элементами (то есть, поддерживает только те данные в структуре данных реляционной базы данных, которые относятся к концевым переключающим элементам) по нескольким причинам. Управление концевыми переключающими элементами предоставляет контроллеру достаточный механизм для поддержания автономности между сетевыми станциями (например, вычислительными устройствами), которое необходимо, в отличие от подержания автономности между всеми переключающими элементами, что не является необходимым. Внутренние переключающие элементы продвигают пакеты данных между переключающими элементами. Концевые переключающие элементы продвигают пакеты данных между сетевыми станциями и другими сетевыми элементами (например, другими переключающими элементами). Таким образом, контроллер может поддерживать автономность пользователей просто управлением концевым переключающим элементом, поскольку концевой переключающий элемент является последним переключающим элементом в тракте продвижения пакетов к сетевой станции.

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

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

Сетевые контроллеры некоторых примеров осуществления реализуют логический переключающий элемент через управляемые переключающие элементы, базируясь на физических данных и логических данных, описанных выше. Логический переключающий элемент (называемый также как "логический элемент продвижения данных") может быть определен для функционирования некоторым числом различных способов (например, переключение слоя 2, маршрутизация слоя 3 и проч.), которые могли бы быть функцией переключающего элемента. Сетевые контроллеры реализуют определенный логический переключающий элемент определенным манипулированием управляемым переключающим элементом. В некоторых примерах осуществления, сетевые контроллеры реализуют многие логические переключающие элементы через управляемые переключающие элементы. Это обеспечивает возможность реализации многих различных логических переключающих элементов посредством управляемых переключающих элементов безотносительно к сетевой топологии сети.

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

С. Логические переключающие элементы и физические переключающие элементы

На Фиг. 4 иллюстрируется пример многих логических переключающих элементов, реализованных посредством совокупности переключающих элементов. В частности, на Фиг. 4 концептуально иллюстрируются логические переключающие элементы 480 и 490, реализованные управляемыми переключающими элементами 410-430. Как показывается на Фиг. 4, сеть 400 содержит управляемые переключающие элементы 410-430 и сетевые станции 440-465. Как указывается на этом рисунке, сетевые станции 440, 450 и 460 принадлежат пользователю А, а сетевые станции 445, 455 и 465 принадлежат пользователю В.

Управляемые переключающие элементы 410-430 некоторых примеров осуществления направляют сетевые данные (например, пакеты, кадры и прочее) между сетевыми элементами в сети, которые подсоединены к управляемым переключающим элементам 410-430. Как показывается, управляемый переключающий элемент 410 направляет сетевые данные между сетевыми станциями 440 и 445 и переключающим элементом 420. Аналогичным образом, переключающий элемент 420 направляет сетевые данные между сетевой станцией 450 и управляемыми переключающими элементами 410 и 430, а переключающий элемент 430 направляет сетевые данные между сетевыми станциями 455-465 и переключающим элементом 420.

Более того, каждый из управляемых переключающих элементов 410-430 направляет сетевые данные, базируясь на логике продвижения данных переключателя, которая в некоторых примерах осуществления представлена в форме таблиц. В некоторых примерах осуществления, таблица продвижения данных определяет, куда направлять сетевые данные (например, порт на переключателе) в соответствии с критерием маршрутизации. Например, таблица продвижения данных переключающего элемента слоя 2 может определять, куда направлять сетевые данные, базируясь на адресах MAC (например, исходный адрес MAC и/или адрес MAC места назначения). В качестве другого примера, таблица продвижения данных переключающего элемента слоя 3 может определять, куда направлять сетевые данные, базируясь на IP адресах (например, исходный IP адрес и/или IP адрес места назначения). Возможно много других типов критериев маршрутизации.

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

На Фиг. 4 иллюстрируются также концептуальные представления логической сети каждого пользователя. Как показывается, логическая сеть 480 пользователя А содержит логический переключающий элемент 485, к которому подсоединены сетевые станции 440, 450 и 460 пользователя А. Логическая сеть 490 пользователя В содержит логический переключающий элемент 495, к котором подсоединены сетевые станции 445, 455 и 465 пользователя В. По существу, с позиции пользователя А, пользователь А имеет переключающий элемент, к которому подсоединены только сетевые станции пользователя А, а с позиции пользователя В, пользователь В имеет переключающий элемент, к которому подсоединены только сетевые станции пользователя В. Иными словами, говоря о каждом пользователе, пользователь имеет свою собственную сеть, которая содержит только сетевые станции этого пользователя.

Далее будут описаны концептуальные потоковые входные сообщения для реализации потока сетевых данных, которые возникают на сетевой станции 440 и предназначаются для сетевой станции 450, и которые возникают на сетевой станции 440 и предназначаются для сетевой станции 460. Потоковое входное сообщение "А1 к А2" в таблице продвижения данных управляемого переключающего элемента 410 выдает команду управляемому переключающему элементу 410 на проводку сетевых данных, которые возникают на сетевой станции 410 и предназначаются для сетевой станции 450, к переключающему элементу 420. Потоковое входное сообщение "А1 к А2" в таблице продвижения данных переключающего элемента 420 выдает команду переключающему элементу 420 на проводку сетевых данных, которые возникают на сетевой станции 410 и предназначаются для сетевой станции 450, к сетевой станции 450. Поэтому, когда сетевая станция 440 посылает сетевые данные, которые предназначаются для сетевой станции 450, управляемые переключающие элементы 410 и 420 направляют сетевые данные вдоль информационного канала 470, базируясь на соответствующих записях в таблицах продвижения данных этих переключающих элементов.

Кроме того, потоковое входное сообщение "А1 к A3" в таблице продвижения данных управляемого переключающего элемента 410 выдает команду управляемому переключающему элементу 410 на проводку сетевых данных, которые возникают на сетевой станции 440 и предназначаются для сетевой станции 460, к переключающему элементу 420. Потоковое входное сообщение "А1 к A3" в таблице продвижения данных переключающего элемента 420 выдает команду переключающему элементу 420 на проводку сетевых данных, которые возникают на сетевой станции 440 и предназначаются для сетевой станции 460, к переключающему элементу 430. Потоковое входное сообщение "А1 к A3" в таблице продвижения данных переключающего элемента 430 выдает команду переключающему элементу 430 на проводку сетевых данных, которые возникают на сетевой станции 440 и предназначаются для сетевой станции 460, к сетевой станции 460. Таким образом, когда сетевая станция 440 пересылает сетевые данные, которые предназначаются для сетевой станции 460, управляемые переключающие элементы 410-430 проводят сетевые данные по информационным каналам 470 и 475, базируясь на соответствующих записях в таблицах продвижения данных переключающих элементов.

Хотя выше были описаны концептуальные потоковые входные сообщения для маршрутизации сетевых данных, возникающих на сетевой станции 440 и предназначенных для сетевой станции 450, и возникающих на сетевой станции 440 и предназначенных для сетевой станции 460, аналогичные потоковые входные сообщения могут быть включены в таблицы продвижения данных управляемых переключающих элементов 410-430 для маршрутизации сетевых данных между другими сетевыми станциями в логической сети 480 пользователя А. Более того, аналогичные потоковые входные сообщения будут включены в таблицы продвижения данных управляемых переключающих элементов 410-430 для маршрутизации сетевых данных между сетевыми станциями в логической сети 490 пользователя В.

Концептуальные потоковые входные сообщения, показанные на Фиг. 4, включают информацию как источника, так и места назначения для управляемых переключающих элементов и вычисления переключающих элементов следующего сегмента, к которым следует пересылать пакеты. Однако информация источника не должна быть в потоковых входных сообщениях, поскольку управляемые переключающие элементы некоторых примеров осуществления могут вычислять переключающие элементы следующего сегмента, используя только информацию места назначения (например, идентификатор контекста, адрес места назначения и пр.).

В некоторых примерах осуществления, для упрощения реализации логических переключающих элементов 485 и 495 через управляемые переключающие элементы 410-430 могут быть использованы туннели, поддерживаемые протоколами образования туннеля (например, управление и обеспечение услуг на точках беспроводного доступа (CAPWAP), общая инкапсуляция маршрутизации (GRE), защита протоколов Интернета GRE (протокол IPsec) и пр.). За счет образования туннеля пакет передается через переключатели и маршрутизаторы, как полезная нагрузка другого пакета. То есть, туннелированный пакет не должен раскрывать своих адресов (например, адресов MAC источника и места назначения), поскольку пакет продвигается на базе адресов, входящих в заголовок внешнего пакета, который инкапсулирует туннелируемый пакет. Образование туннеля, тем самым, обеспечивает отделение пространства логических адресов от пространства физических адресов, поскольку туннелированный пакет может иметь адреса значимые в пространстве логических адресов, в то время как внешний пакет продвигается/направляется на базе адресов в пространстве физических адресов. Подобным образом, туннели могут рассматриваться как "логические проводники", которые соединяют управляемые переключающие элементы в сети для реализации логических переключающих элементов 485 и 495.

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

II. УНИВЕРСАЛЬНОЕ СОСТОЯНИЕ ПРОДВИЖЕНИЯ ДАННЫХ

А. Слои экземпляров контроллеров

На Фиг. 5 иллюстрируется распространение команд для управления управляемым переключающим элементом через различные обрабатывающие слои экземпляров контроллеров некоторых примеров осуществления изобретения. На этом рисунке иллюстрируется конвейер управляющих данных 500, который транслирует и распространяет данные плоскости управления через четыре обрабатывающих слоя одного и того же или различных экземпляров контроллеров управляемого переключающего элемента 525. Эти четыре слоя являются входным слоем трансляции 505, слоем управления 510, слоем виртуализации 515 и слоем настройки под пользователя 520.

В некоторых примерах осуществления, эти четыре слоя находятся в одном и том же экземпляре контроллера. Однако в других примерах осуществления существуют и другие конфигурации этих слоев. Например, в других примерах осуществления в одном и том же экземпляре контроллера находятся только слои управления и виртуализации 510 и 515, а функция распространения данных заказной плоскости физического управления (СРСР) находится в слое настройки другого экземпляра контроллера (например, базового контроллера, не показан). В других примерах осуществления, данные универсальной плоскости физического управления (UPCP) передаются из структуры данных реляционной базы данных (не показана) одного из экземпляров контроллера на структуру данных реляционной базы данных другого экземпляра контролера, перед тем как другой экземпляр контроллера генерирует и продвигает данные СРСР на управляемый переключающий элемент. Упомянутый выше экземпляр контроллера может быть логическим контроллером, который генерирует данные UPCP, а последний экземпляр контроллера может быть физическим контроллером или базовым контролером, который трансформирует данные UPCP в данные СРСР.

Как показывается на Фиг. 5, слой трансляции входных данных 505 в некоторых примерах осуществления имеет LCP 530, которая может быть использована для выражения выходных данных этого слоя. В некоторых примерах осуществления, пользователям предоставляется приложение (например, приложение на базе web, не показано) для подачи пользователями входных данных, специфицирующих совокупности LDP. Это приложение пересылает входные данные в форме вызовов API на слой трансляции входных данных 505, который преобразует вызовы API в данные LCP в формате, который может быть обработан слоем управления 510. Например, входные данные преобразуются в совокупность входных событий, которые могут быть поданы в механизм отображения таблиц nLog слоя управления. Механизм отображения таблиц nLog и его работа будут описаны далее ниже.

Слой управления 510 в некоторых примерах осуществления имеет LCP 530 и LFP 535, которые могут быть использованы для представления входных данных и выходных данных этому слою. LCP содержит набор высокоуровневых структурных компонентов, которые дают возможность управляющему слою и его пользователям специфицировать одну или более совокупностей LDP внутри LCP одного или более пользователей. LFP 535 представляет совокупности LDP пользователей в формате, который может быть обработан слоем виртуализации 515. Подобным образом, две логические плоскости 530 и 535 являются аналогами в пространстве виртуализации плоскостей управления и продвижения данных 555 и 560, которые обычно могут быть найдены в типичном управляемом переключающем элементе 525, как показано на Фиг. 5.

В некоторых примерах осуществления, слой управления 510 определяет и выражает структурные компоненты LCP, которыми сам слой или пользователи слоя определяют различные совокупности LDP внутри LCP. Например, в некоторых примерах осуществления, данные LCP 530 содержат логические данные ACL и т.д. Некоторые из этих данных (например, логические данные ACL) могут быть специфицированы пользователем, в то время как другие такие данные (например, логические записи L2 или L3) генерируются слоем управления и не могут быть специфицированы пользователем. В некоторых примерах осуществления, слой управления 510 генерирует и/или специфицирует такие данные в ответ на определенные изменения в структуре данных реляционной базы данных (которые указывают изменения в управляемых переключающих элементах и управляемых информационных каналах), которые обнаруживает слой управления 510.

В некоторых примерах осуществления, данные LCP (то есть, совокупности данных LDP, которые выражаются в терминах структурных компонентов плоскости управления) могут быть первоначально специфицированы без рассмотрения текущих данных о работе управляемых переключающих элементов и без рассмотрения способа, которым эти данные плоскости управления будут преобразовываться в данные РСР. Например, данные LCP могли бы специфицировать управляющие данные одного логического переключающего элемента, который соединяет пять компьютеров, даже хотя эти данные плоскости управления могли бы позднее быть преобразованы в физические данные управления для трех управляемых переключающих элементов, которые реализуют желаемое переключение между этими пятью компьютерами.

Слой управления содержит набор модулей (не показаны) для преобразования любой LDPS внутри LCP в LDPS в LFP 535. В некоторых примерах осуществления, для выполнения этого преобразования слой управления 510 использует механизм отображения таблиц nLog. Использование слоем управления механизма отображения таблиц nLog для выполнения этого преобразования описывается несколько далее. Слой управления также содержит набор модулей (не показан) для продвижения совокупностей LDP от LFP 535 слоя управления 510 к LFP 540 слоя виртуализации 515.

LFP 540 содержит одну или более совокупностей LDP одного или более пользователей. LFP 540 в некоторых примерах осуществления содержит логические данные продвижения данных одной или более совокупностей LDP одного или более пользователей. Некоторые из этих данных передаются на LFP 540 слоем управления, в то время как другие такие данные передаются на LFP слоем виртуализации, обнаруживающим события в структуре данных реляционной базы данных, как будет описано немного далее для некоторых примеров осуществления.

Дополнительно к LFP 540, слой виртуализации 515 содержит UPCP 545. UPCP 545 содержит данные UPCP для совокупностей LDP. Слой виртуализации содержит набор модулей (не показаны) для преобразования совокупностей LDP внутри LFP 540 в данные UPCP 545. В некоторых примерах осуществления, слой виртуализации 515 для выполнения этого преобразования использует механизм отображения таблиц nLog. Слой виртуализации содержит также набор модулей (не показаны) для перемещения данных UPCP от UPCP 545 слоя виртуализации 515 в структуру данных реляционной базы данных слоя настройки под пользователя 520.

В некоторых примерах осуществления, данные UPCP, которые посылаются на слой настройки под пользователя 515, позволяют управляемому переключающему элементу 525 обрабатывать пакеты данных в соответствии с совокупностями LDP, специфицированными слоем управления 510. Однако, в отличие от данных СРСР, данные UPCP не являются полной реализацией логических данных, специфицированных слоем управления, поскольку данные UPCP в некоторых примерах осуществления не выражают различия в управляемых переключающих элементах и/или информацию, специфичную для положения управляемых переключающих элементов.

Данные UPCP должны быть преобразованы в данные СРСР каждого управляемого переключающего элемента, для того чтобы полностью реализовать совокупности LDP на управляемых переключающих элементах. Например, когда совокупности LDP специфицируют туннель, который захватывает несколько управляемых переключающих элементов, данные UPCP выражают один конец туннеля, используя определенный сетевой адрес (например, IP адрес) управляемого переключающего элемента, представляющего этот конец. Однако каждый из других управляемых переключающих элементов, через которые проходит туннель, использует номер порта, который является локальным адресом для управляемого переключающего элемента, чтобы ссылаться на концевой управляемый переключающий элемент, имеющий определенный сетевой адрес. То есть, определенный сетевой адрес должен быть транслирован в локальный номер порта каждого из управляемых переключающих элементов, с тем, чтобы полностью реализовать совокупности LDP, специфицирующие туннель на управляемых переключающих элементах.

Данные UPCP, как промежуточные данные, транслируемые в данные СРСР, позволяют управляющей системе некоторых примеров осуществления масштабироваться, принимая, что слой настройки под пользователя 520 исполняется в другом экземпляре контроллера, отличном от экземпляра контроллера, который генерирует данные UPCP. Это определяется тем, что слой виртуализации 515 не должен преобразовывать данные LFP, специфицирующие совокупности LDP, в данные СРСР для каждого из управляемых переключающих элементов, которые реализуют совокупности LDP. Вместо этого слой виртуализации 515 однократно преобразует данные LFP в данные UPCP всех управляемых переключающих элементов, которые реализуют совокупности LDP. Подобным образом, приложение виртуализации экономит вычислительные ресурсы, которые в обратном случае были бы потрачены на выполнение преобразования совокупностей LDP в данные СРСР столько раз, сколько имеется управляемых переключающих элементов, которые реализуют совокупности LDP.

Слой настройки под пользователя 520 содержит UPCP 546 и СРСР 550, которые могут быть использованы для выражения входных и выходных данных для этого слоя. Слой настройки под пользователя содержит набор модулей (не показаны) для преобразования данных UPCP в UPCP 546 в данные СРСР в СРСР 550. В некоторых примерах осуществления, слой настройки под пользователя 520 использует механизм отображения таблиц nLog для выполнения этого преобразования. Слой настройки под пользователя содержит также набор модулей (не показаны) для перемещения данных СРСР из СРСР 550 слоя подстройки под пользователя 520 в управляемые переключающие элементы 525.

Данные СРСР, которые перемещаются к каждому управляемому переключающему элементу, являются специфичными для этого управляемого переключающего элемента. Данные СРСР, хотя эти данные именуются как "физические" данные, позволяют управляемому переключающему элементу выполнять физические операции переключения в обеих областях обработки как физических, так и логических данных. В некоторых примерах осуществления, слой настойки под пользователя 520 исполняется в отдельном экземпляре контроллера для каждого из управляемых переключающих элементов 525.

В некоторых примерах осуществления слой настройки под пользователя 520 не исполняется в экземпляре контроллера. Слой настройки под пользователя 515 в этих примерах осуществления находится в управляемых переключающих элементах 525. Поэтому, в этих примерах осуществления, слой виртуализации 515 пересылает данные UPCP на управляемые переключающие элементы. Каждый управляемый переключающий элемент будет настраивать данные UPCP в данные СРСР, специфичные для этого управляемого переключающего элемента. В некоторых из этих примеров осуществления, демон контроллера будет исполняться в каждом управляемом переключающем элементе и будет проводить преобразование универсальных данных в заказные данные управляемого переключающего элемента. Демон контроллера будет описан несколько позднее.

В некоторых примерах осуществления, заказные данные физической плоскости управления, которые распространяются на управляемый переключающий элемент 525, инициируют этот переключающий элемент на выполнение физических операций продвижения сетевых данных (например, пакетов), базируясь на логических значениях, определенных в логической области. В частности, в некоторых примерах осуществления, данные заказной плоскости физического управления специфицируют потоковые входные сообщения, которые содержат логические значения. Эти логические значения включают логические адреса, логические номера портов и проч., которые используются для продвижения сетевых данных в логической области. Эти потоковые входные сообщения также отображают логические значения в физические значения, определенные в физической области, так что управляемый переключающий элемент может выполнять логические операции продвижения сетевых данных исполнением физических операций продвижения данных, базируясь на логических значениях. Подобным образом, данные физической плоскости управления поддерживают реализацию логических переключающих элементов через управляемые переключающие элементы. Несколько примеров использования переданных данных физической плоскости управления для реализации обработки логических данных в управляемых переключающих элементах описаны дополнительно в заявке на патент США 13/177,535, поданной 6 июля 2011 г. Патентная заявка США 13/177,535 введена здесь ссылкой.

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

В. Экземпляры многих контроллеров

На Фиг. 6 иллюстрируется распределенная система сетевого управления 600 некоторых примеров осуществления со многими экземплярами контроллеров. Эта распределенная система управляет многими переключающими элементами 690 тремя экземплярами контроллеров 605, 610 и 615. В некоторых примерах осуществления, распределенная система 600 предоставляет возможность различным экземплярам контроллеров управлять операциями одного и того же переключающего элемента или различных переключающих элементов. Как показывается на Фиг. 6, каждый экземпляр содержит модуль ввода 620, модуль управления 625, записи 635, структуру вторичной памяти (например, PTD) 640, интерфейс связи между контроллерами 645, интерфейс связи управляемого переключающего элемента 650.

Модуль ввода 620 экземпляра контроллера аналогичен слою трансляции входных данных 505, описанному выше со ссылкой на Фиг. 5, в том, что модуль ввода 620 получает входные данные от пользователей и транслирует входные данные в данные LCP, которые модуль управления 625 будет распознавать и обрабатывать. Как было упомянуто выше, в некоторых примерах осуществления входные данные существуют в форме вызовов API. Модуль ввода 620 пересылает данные LCP на модуль управления 625.

Модуль управления 625 экземпляра контроллера аналогичен слою управления 510 в том, что модуль управления 625 преобразует данные LCP в данные LFP и пересылает данные LFP в модуль виртуализации 630. Кроме того, модуль управления 625 определяет, являются ли полученные данные LCP данными LDPS, которые управляются этим экземпляром контроллера. Если экземпляр контроллера является задающим контроллером LDPS для данных LCP (то есть, логическим контроллером, управляющим LDPS), то модуль виртуализации экземпляра контроллера будет далее обрабатывать данные. В противном случае, модуль управления 625 некоторых примеров осуществления сохраняет данные LCP во вторичной памяти 640.

Модуль виртуализации 630 экземпляра контроллера аналогичен слою виртуализации 515 в том, что модуль виртуализации 630 преобразует данные LFP в данные UPCP. Модуль виртуализации 630 некоторых примеров осуществления пересылает затем данные UPCP на другой экземпляр контроллера через интерфейс связи между контроллерами 645 или на управляемые переключающие элементы через интерфейс связи управляемых переключающих элементов 650.

Модуль виртуализации 630 пересылает данные UPCP на другой экземпляр, когда другой экземпляр контроллера является физическим контроллером, который ответственен за управление по меньшей мере одним из управляемых переключающих элементов, который реализует LDPS. Это происходит в случае, когда экземпляр контроллера, на котором модуль виртуализации 630 сгенерировал данные UPCP, является как раз логическим контроллером, ответственным за определенную LDPS, но не является физическим контроллером или базовым контроллером, ответственным за управляемые переключающие элементы, которые реализуют LDPS.

Модуль виртуализации 630 пересылает данные UPCP на управляемые переключающие элементы, когда управляемые переключающие элементы сконфигурированы для преобразования данных UPCP в данные СРСР, специфичные для этих управляемых переключающих элементов. В этом случае, экземпляр контроллера не будет иметь слой настройки под пользователя или модуль, который будет выполнять преобразование данных UPCP в данные СРСР.

Записи 635, в некоторых примерах осуществления, являются набором записей, хранимых в структуре данных реляционной базы данных экземпляра контроллера. В некоторых примерах осуществления, некоторые или все из входных модулей, управляющих модулей и модулей виртуализации используют, обновляют и управляют записями, хранимыми в структуре данных реляционной базы данных. То есть, входные и/или выходные данные этих модулей хранятся в структуре данных реляционной базы данных.

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

PTD 640 некоторых примеров осуществления является структурой вторичной памяти для хранения данных сетевой конфигурации, специфичной для пользователя (то есть, данных LCP, преобразованных из входных данных в форме вызовов API). В некоторых примерах осуществления, PTD каждого экземпляра контроллера хранит данные конфигурации для всех пользователей, использующих систему 600. Экземпляр контроллера, который получает входные данные пользователя, пересылает данные конфигурации на многие PTD других экземпляров контроллеров, так что каждый PTD каждого экземпляра контроллера имеет в этом примере осуществления все конфигурационные данные для всех пользователей. Однако в других примерах осуществления PTD экземпляра контроллера хранит только конфигурационные данные определенной LDPS, которой управляется этот экземпляр контроллера.

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

Интерфейс связи между контроллерами 645 используется (например, экспортером, не показан) для установления канала связи (например, канала RPC) с другим экземпляром контроллера. Как показано, интерфейсы связи между контроллерами поддерживают обмен данными между различными экземплярами контроллеров 605-615.

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

Для некоторых или всех связей между распределенными экземплярами контроллеров система 600 использует администраторов координации (СМ) 655. CM 655 в каждом экземпляре предоставляет экземпляру возможность координировать с другими экземплярами определенные действия. Различные примеры осуществления используют СМ для координации различных совокупностей действий между экземплярами. Примерами таких действий является запись в структуру данных реляционной базы данных, запись в PTD, управление переключающими элементами, поддержка связи между контроллерами, касающаяся отказоустойчивости экземпляров контроллеров и проч. Также многие СМ используются для поиска задающих контроллеров LDPS и задающих контроллеров управляемых переключающих элементов.

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

Для распределения рабочей нагрузки и для устранения конфликтующих операций между различными экземплярами контроллеров, система 600 некоторых примеров осуществления назначает один экземпляр контроллера (например, 605) в системе 600 в качестве задающего контроллера LDPS и/или любого заданного управляемого переключающего элемента (то есть, в качестве логического контроллера или физического контроллера). В некоторых примерах осуществления, каждый экземпляр задающего контроллера хранит в своей структуре данных реляционной базы данных только данные, относящиеся к управляемым переключающим элементам, которые управляются задающим контроллером.

В некоторых примерах осуществления, как было отмечено выше, несколько СМ поддерживают сообщения между контроллерами, относящиеся к отказоустойчивости экземпляров контроллеров. Например, несколько СМ реализуют связь между контроллерами через вторичную память, описанную выше. Экземпляр контроллера в управляющей системе может отказать по многим причинам (например, аппаратный отказ, программный отказ, сетевой отказ и проч.). Различные примеры осуществления могут использовать различные технологии определения того, отказал ли экземпляр контроллера. В некоторых примерах осуществления, для определения того, отказал ли экземпляр контроллера в управляющей системе, используется протокол консенсуса. В то время как некоторые из этих примеров осуществления для реализации протоколов консенсуса могут использовать Apache Zookeeper, другие примеры осуществления могут реализовывать протокол консенсуса другими способами.

Некоторые примеры осуществления СМ 655 могут использовать заданные длительности ожидания для определения того, отказал ли экземпляр контроллера. Например, если СМ экземпляра контроллера не отвечает на сообщение (например, посланное от другого СМ другого экземпляра контроллера в управляющей системе) в течение определенного времени (т.е. определенной величины длительности ожидания), то этот не отвечающий экземпляр контроллера определяется как отказавший. В других примерах осуществления могут использоваться другие способы определения того, отказал ли экземпляр контроллера.

Когда отказывает экземпляр задающего контроллера, то необходимо определить новый задающий контроллер для совокупностей LDP и переключающих элементов. В некоторых примерах осуществления СМ 655 такое определение проводится выполнением процесса выбора задающего контроллера, при котором выбирается экземпляр задающего контроллера (например, для декомпозиции управления совокупностями LDP и/или для декомпозиции управления переключающими элементами). СМ 655 некоторых примеров осуществления может выполнять процесс выбора задающего контроллера для подбора нового экземпляра задающего контроллера как для совокупностей LDP, так и для тех переключающих элементов, задающим контроллером которых был отказавший экземпляр контроллера. Однако СМ 655 других примеров осуществления может выполнять (1) процесс выбора задающего контроллера для подбора нового экземпляра задающего контроллера совокупностей LDP, задающим контроллером которых был отказавший экземпляр контроллера и (2) другой процесс выбора задающего контролера для подбора нового экземпляра задающего контроллера для переключающих элементов, задающим контроллером которых был отказавший экземпляр контроллера. В этих случаях СМ 655 может определять два различных экземпляров контроллеров, как новых экземпляров контроллеров: один - для совокупностей LDP, задающим контроллером которых был отказавший экземпляр контроллера, а другой - для переключающих элементов, задающим контроллером которых был отказавший экземпляр контроллера.

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

В некоторых примерах осуществления, процесс выбора задающего контроллера выполняется также для декомпозиции управления совокупностями LDP и/или управления переключающими элементами, когда экземпляр контроллера добавляется к управляющей системе. В частности, в некоторых примерах осуществления СМ 655 проводит процесс выбора задающего контроллера, когда управляющая система 600 обнаруживает изменение в принадлежности экземпляров контроллеров к управляющей системе 600. Например, СМ 655 может проводить процесс выбора задающего контроллера для перераспределения части управления совокупностями LDP и/или управления переключающими элементами от существующих экземпляров контроллеров на новый экземпляр контроллера, когда управляющая система 600 обнаруживает, что к управляющей системе 600 был добавлен новый сетевой контроллер. Однако в других примерах осуществления, перераспределение части управления совокупностями LDP и/или управления переключающими элементами от существующих экземпляров контроллеров на новый экземпляр контроллера не возникает, когда управляющая система 600 обнаруживает, что к управляющей системе 600 был добавлен новый сетевой контроллер. Вместо этого, управляющая система 600, в этих примерах осуществления, назначает не назначенные совокупности LDP и/или переключающие элементы (например, новые совокупности LDP и/или переключающие элементы или совокупности LDP и/или переключающие элементы из отказавшего сетевого контроллера) на новый экземпляр контроллера, когда управляющая система 600 обнаруживает не назначенные совокупности LDP и/или переключающие элементы.

С. Декомпозиция управления совокупностями LDP и управляемыми переключающими элементами

На Фиг. 7 иллюстрируется пример определения экземпляра задающего контроллера переключающего элемента (то есть, физического контроллера) в распределенной системе 700, которая аналогична системе 600 на Фиг. 6. В этом примере два контроллера 705 и 710 управляют тремя переключающими элементами S1, S2 и S3 двух различных пользователей А и В. Два пользователя посредством двух приложений управления 715 и 720 специфицируют две различные совокупности LDP 725 и 730, преобразуемые в многочисленные записи, которые идентично хранятся в двух структурах данных реляционной базы данных 755 и 760 двух экземпляров контроллеров 705 и 710 приложениями виртуализации 745 и 750 этих контроллеров.

В примере, показанном на Фиг. 7, оба приложения управления 715 и 720 обоих контроллеров 705 и 710 могут модифицировать записи переключающего элемента S2 обоих пользователей А и В, но задающим контроллером этого переключающего элемента является только контроллер 705. Этот пример иллюстрирует два различных сценария. В первом сценарии используется контроллер 705, который обновляет запись S2b1 в переключающем элементе S2 пользователя В. Во втором сценарии используется контроллер 705, который обновляет записи S2a1 в переключающем элементе S2 после того, как приложение управления 720 обновляет запись S2a1 переключающего элемента S2 и пользователя А в структуре данных реляционной базы данных 760. В примере, представленном на Фиг. 7, это обновление направляется из структуры данных реляционной базы данных 760 контроллера 710 в структуру данных реляционной базы данных 755 контроллера 705, а вслед за этим направляется на переключающий элемент S2.

Различные примеры осуществления используют различные технологии для перенесения изменений в структуре данных реляционной базы данных 760 экземпляра контроллера 710 в структуру данных реляционной базы данных 755 экземпляра контроллера 705. Например, для перенесения этого обновления приложение виртуализации 750 контроллера 710 в некоторых примерах осуществления пересылает набор записей непосредственно в структуру данных реляционной базы данных 755 (использованием модулей связи между контроллерами или экспортера/импортера). В ответ на это, приложение виртуализации 745 будет пересылать эти изменения структуры данных реляционной базы данных 755 к переключающему элементу S2.

Вместо перенесения изменений структуры данных реляционной базы данных в структуру данных реляционной базы данных другого экземпляра контроллера, система 700 некоторых примеров осуществления использует другие технологии для изменения записи S2a1 в переключающем элементе S2 в ответ на запрос от приложения управления 720. Например, распределенная управляющая система некоторых примеров осуществления использует структуры вторичной памяти (например, PTD) в качестве каналов связи между различными экземплярами контроллеров. В некоторых примерах осуществления, многие PTD копируются по всем экземплярам, а некоторые или все изменения структуры данных реляционной базы данных продвигаются от одного экземпляра контроллера к другому экземпляру через слой памяти PTD. Соответственно, в экземпляре, показанном на Фиг. 7, изменение в структуре данных реляционной базы данных 760 могло бы быть реплицировало в PTD контроллера 710, а от него оно могло бы быть реплицировано в PTD контроллера 705 и структуру данных реляционной базы данных 755.

Могли бы существовать и другие варианты последовательности операций, показанных на Фиг. 7, поскольку некоторые примеры осуществления, дополнительно к назначению экземпляра контроллера в качестве задающего контроллера переключающего элемента, назначают один экземпляр контроллера в качестве задающего контроллера для LDPS. В некоторых примерах осуществления, различные экземпляры контроллеров могут быть задающими контроллерами переключающего элемента и соответствующей записи для этого переключающего элемента в структуре данных реляционной базы данных, в то время как в других примерах осуществления требуется, чтобы экземпляр контроллера был задающим контроллером переключающего элемента и всех записей для этого переключающего элемента в структуре данных реляционной базы данных.

В примерах осуществления, где система 700 учитывает назначение задающих контроллеров для переключающих элементов и записей структуры данных реляционной базы данных, пример, показанный на Фиг. 7, иллюстрирует случай, где экземпляр контроллера 710 является задающим контроллером записи S2a1 в структуре данных реляционной базы данных, в то время как экземпляр контроллера 705 является задающим контроллером переключающего элемента S2. Если задающим контроллером записи S2a1 структуры данных реляционной базы данных был экземпляр контроллера, отличный от экземпляра контроллера 705 и 710, то тогда к этому другому экземпляру контроллера от приложения управления 720 должно бы быть перемещено требование о модификации записи в структуре данных реляционной базы данных. Этот другой экземпляр контроллера будет затем модифицировать запись в структуре данных реляционной базы данных и эта модификация будет затем причиной того, что структура данных реляционной базы данных 755 и переключающий элемент S2 обновят свои записи любым числом механизмов, которые будут распространять эту модификацию на экземпляр контроллера 705.

В других примерах осуществления, экземпляр контроллера 705 может быть задающим контроллером записи S2a1 структуры данных реляционной базы данных или экземпляр контроллера 705 может быть задающим контроллером переключающего элемента S2 и всех записей его структуры данных реляционной базе данных. В этих примерах осуществления, требование модификации записи в структуре данных реляционной базы данных от приложения управления 720 должно будет передаваться на экземпляр контроллера 705, который будет затем модифицировать записи в структуре данных реляционной базы данных 755 и переключающем элементе S2.

Как было упомянуто выше, различные примеры осуществления используют различные технологии для поддержки связи между различными экземплярами контроллеров. Кроме того, различные примеры осуществления по разному реализуют экземпляры контроллеров. Например, в некоторых примерах осуществления, на одном компьютере устанавливаются и исполняются набор из приложения управления (например, 625 или 715 на Фиг. 6 и Фиг. 7) и приложения виртуализации (например, 630 или 745). Также, в некоторых примерах осуществления, на одном компьютере могут быть установлены и параллельно исполняться многие экземпляры контроллеров. В некоторых примерах осуществления, экземпляр контроллера может также иметь свой набор компонентов, которые разделены между несколькими компьютерами. Например, в пределах одного экземпляра приложение управления (например, 625 или 715) может быть на первой физической или виртуальной машине, а приложение виртуализации (например, 630 или 745) может быть на второй физической или виртуальной машине.

На Фиг. 8 иллюстрируется пример работы нескольких экземпляров контроллеров, которые функционируют как контроллер распределения входных данных, задающий контроллер LDPS (называемый также логическим контроллером) и задающий контроллер управляемого переключающего элемента (называемый также физическим контроллером). В некоторых примерах осуществления, не каждый экземпляр контроллера содержит полный набор различных модулей и интерфейсов, как было описано выше со ссылкой на Фиг. 6. Или же не каждый экземпляр контроллера выполняет каждую функцию этого полного набора. Например, ни один из экземпляров контроллеров 805, 810 и 815, показанных на Фиг. 8, не имеет полный набор модулей или интерфейсов.

Экземпляр контроллера 805 в этом примере является экземпляром контроллера для распределения входных данных. То есть, экземпляр контроллера 805 некоторых примеров осуществления получает входные данные от пользователей в форме вызовов API. Посредством вызовов API пользователи могут специфицировать запросы на конфигурирование определенной LDPS (например, конфигурирование логического переключающего элемента или логического маршрутизатора, который должен быть реализован в совокупности управляемых переключающих элементов) или специфицировать запросы информационных требований (например, статистики сетевого графика логических портов логического переключателя пользователя). Модуль ввода 820 экземпляра контроллера 805 получает эти вызовы API и транслирует их в форму (например, кортежей или записей данных), которая может быть сохранена в PTD 825, и пересылает на другой экземпляр контроллера в некоторых примерах осуществления.

Экземпляр контроллера 805 в этом примере пересылает затем эти записи на другой экземпляр контроллера, который ответственен за управление записями определенной LDPS. В этом примере, ответственным за записи LDPS является экземпляр контроллера 810. Экземпляр контроллера 810 получает записи от PTD 825 экземпляра контроллера 805 и сохраняет эти записи в PTD 845, который является структурой вторичной памяти экземпляра контроллера 810. В некоторых примерах осуществления, PTD различных экземпляров контроллеров могут непосредственно обмениваться информацией друг с другом и не должны передавать сообщения на интерфейсы связи между контроллерами.

Затем приложение управления 810 обнаруживает добавление этих записей к PTD и обрабатывает записи для генерации или модификации других записей в структуре данных реляционной базы данных 842. В частности, приложение управления генерирует данные LFP. В свою очередь, приложение виртуализации обнаруживает модификацию и/или добавление этих записей в структуре данных реляционной базы данных и модифицирует и/или генерирует другие записи в структуре данных реляционной базы данных. Эти другие записи в этом примере представляют данные UPCP. Затем эти записи пересылаются на другой экземпляр контроллера, который управляет, по меньшей мере, одним из переключающих элементов, реализующим определенную LDPS, через интерфейс связи между контроллерами 850 экземпляра контроллера 810.

Экземпляр контроллера 815 в этом примере является экземпляром контроллера, который управляет переключающим элементом 855. Этот переключающий элемент реализует по меньшей мере часть определенной LDPS. Экземпляр контроллера 815 получает записи, представляющие данные UPCP, от экземпляра контроллера 810 через интерфейс связи между контроллерами 865. В некоторых примерах осуществления, экземпляр контроллера 815 будет иметь приложение управления и приложение виртуализации для выполнения преобразования данных UPCP в данные СРСР. Однако в этом примере, экземпляр контроллера 815 только идентифицирует совокупность управляемых переключающих элементов, на которые пересылает данные UPCP. Подобным образом, экземпляр контроллера 815 функционирует как точка агрегации для сбора данных и пересылки к тем управляемым переключающим элементам, за управление которыми ответственен этот контроллер. В этом примере управляемый переключающий элемент 855 является одним из переключающих элементов, управляемых экземпляром контроллера 815.

D. Слой трансляции входных данных

На Фиг. 9 концептуально иллюстрируется программная архитектура приложения трансляции входных данных. Приложение трансляции входных данных некоторых примеров осуществления функционирует как слой трансляции входных данных 505, описанный выше со ссылкой на Фиг. 5. В частности, приложение трансляции входных данных получает входные данные от приложения интерфейса пользователя, который предоставляет пользователю возможность вводить значения входных данных. Приложение трансляции входных данных преобразует входные данные в требования и распределяет требования на один или более экземпляров контроллеров для обработки этих требований. В некоторых примерах осуществления, приложение трансляции входных данных исполняется в том же самом экземпляре контроллера, в котором исполняется приложение управления, в то время как в других примерах осуществления приложение трансляции входных данных исполняется как отдельный экземпляр контроллера. Как показывается на этом рисунке, приложение трансляции входных данных содержит программу синтаксического анализа (анализатор) входных данных 905, фильтр 910, генератор запросов 915, репозиторий запросов 920, диспетчер 925, администратор ответов 930 и интерфейс связи между контроллерами 940.

В некоторых примерах осуществления, приложение трансляции входных данных 900 поддерживает совокупность вызовов API для специфицирования совокупностей LDP и информационных запросов. В этих примерах осуществления, приложение интерфейса пользователя, которое предоставляет пользователю возможность вводить значения входных данных, реализуется для пересылки входных данных в форме вызовов API на приложение трансляции входных данных 900. Поэтому такие вызовы API специфицируют LDPS (например, логическую конфигурацию переключающих элементов, специфицированную пользователем) и/или информационный запрос пользователя (например, статистику сетевого графика логических портов логического переключающего элемента пользователя). Кроме того, в некоторых примерах осуществления приложение трансляции входных данных 900 может получать входные данные от логических контроллеров, физических контроллеров и/или другого приложения трансляции входных данных другого экземпляра контроллера.

Анализатор входных данных 905 некоторых примеров осуществления получает входные данные в форме вызовов API от приложения интерфейса пользователя. В некоторых примерах осуществления, анализатор входных данных выделяет значения входных данных пользователя из вызовов API и пересылает эти значения входных данных на фильтр 910. Фильтр 910 отфильтровывает значения входных данных, которые не отвечают определенным требованиям. Например, фильтр 910 отфильтровывает значения входных данных, которые специфицируют неправильный сетевой адрес логического порта. Для тех вызовов API, которые содержат не удовлетворяющие запросу значения входных данных, администратор ответов 930 пересылает ответ пользователю, указывающий, что входные данные не удовлетворяют запросу.

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

Генератор запросов 915 различных примеров осуществления генерирует запросы в соответствии с различными форматами, зависящими от реализации экземпляров контроллеров, которые получают и обрабатывают запросы. Например, запросы, которые генерирует генератор запросов 915 некоторых примеров осуществления, находятся в форме записей (например, кортежи данных), удобных для хранения в структурах данных реляционной базы данных экземпляров контроллеров, которые получают эти запросы. В некоторых из этих примеров осуществления, получающие экземпляры контроллеров используют механизм отображения таблиц nLog для обработки записей, представляющих эти запросы. В других примерах осуществления, запросы находятся в форме объект-ориентированных объектов данных, которые могут взаимодействовать со структурами данных NIB экземпляров контроллеров, которые получают запрос. В этих примерах осуществления, получающие экземпляры контроллеров обрабатывают объекты данных непосредственно на структуре данных NIB, без прохождения через механизм отображения таблиц nLog.

Генератор запросов 915 некоторых примеров осуществления помещает сгенерированные запросы в репозиторий запросов 920, так что диспетчер 925 может пересылать запросы к надлежащим экземплярам контроллеров. Диспетчер 925 идентифицирует экземпляр контроллера, к которому должен быть послан каждый запрос. В некоторых случаях, диспетчер просматривает LDPS, связанную с этим запросом, и идентифицирует экземпляр контроллера, который является задающим контроллером этой LDPS. В некоторых случаях, диспетчер идентифицирует задающий контроллер определенного переключающего элемента (то есть, физический контроллер), как экземпляр контроллера для посылки запроса, когда запрос определенно относится к переключающему элементу (например, когда запрос является запросом о статистической информации логического порта, который отображается на порт переключающего элемента). Этот диспетчер пересылает запрос на идентифицированный экземпляр контроллера. Получающий экземпляр контроллера возвращает ответы, когда запросы содержат запрашиваемую информацию.

Интерфейс связи между контроллерами 940 аналогичен интерфейсу связи между контроллерами 645, который был описан ранее со ссылкой на Фиг. 6, в том, что интерфейс связи между контроллерами 940 устанавливает канал связи (например, канал RPC) с другим экземпляром контроллера, через который могут быть посланы запросы. Канал связи некоторых примеров осуществления является бинаправленным, в то время как в других примерах осуществления канал связи является однонаправленным. Когда канал является однонаправленным, интерфейс связи между контроллерами устанавливает несколько каналов с другим экземпляром контроллера, так что приложение трансляции входных данных может пересылать запросы и получать ответы через различные каналы.

Когда получающие экземпляры контроллеров получают запросы, которые специфицируют запрашиваемую информацию, экземпляры контроллеров обрабатывают запросы и формируют ответы, содержащие запрашиваемую информацию. Администратор ответов 930 получает ответы от экземпляров контроллеров, через канал(ы), установленный (установленные) интерфейсом связи между контроллерами 940. В некоторых случаях, на запрос, который был послан, может возвращаться более одного ответа. Например, запрос о статистической информации обо всех логических портах логического переключающего элемента, который управляется пользователем, будут возвращать ответ от каждого контроллера. Ответы от многих экземпляров физических контроллеров многих различных переключающих элементов, порты которых отображаются на логические порты, могут возвращаться к приложению трансляции входных данных 900 или непосредственно к приложению трансляции входных данных 900 или через задающий контроллер LDPS, связанной с логическим переключателем. В таких случаях, администратор ответов 930 некоторых примеров осуществления объединяет эти ответы и пересылает единый объединенный ответ на приложение интерфейса пользователя.

Как было упомянуто выше, приложение управления, исполняемое в экземпляре контроллера, преобразует записи данных, представляющих данные LCP, в записи данных, представляющих данные LFP, выполнением операций преобразования. В частности, в некоторых примерах осуществления, приложение управления заполняет таблицы LDPS (например, логические таблицы продвижения данных), которые создаются приложением виртуализации с совокупностями LDP.

Е. Механизм nLog

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

Соответственно, механизм nLog некоторых примеров осуществления создается специально для быстрой работы, с тем чтобы он мог бы выполнять отображение в реальном времени кортежей данных LDPS на кортежи данных управляемых переключающих элементов. Эта специализированная разработка базируется на нескольких вариантах заказной разработки. Например, некоторые примеры осуществления компилируют механизм отображения таблиц nLog из совокупности декларативных правил высокого уровня, которые выражаются разработчиком приложений (например, разработчиком приложения управления). В некоторых из этих примеров осуществления, один вариант заказной разработки, который создается для механизма nLog, должен позволять разработчику приложения использовать только оператор И для выражения декларативного правила. Предотвратив возможность того, что разработчик будет использовать другие операторы (такие как ИЛИ, исключающее ИЛИ и прочие), эти примеры осуществления обеспечивают, что результирующие правила механизма nLog выражаются в терминах операторов И, которые являются более быстрыми по времени исполнения.

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

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

Декомпозиция управления совокупностями LDP назначает также в некоторых примерах осуществления операции отображения таблиц каждой LDPS на механизм nLog экземпляра контроллера, который ответственен за эту LDPS. Распределение операций отображения таблиц nLog по нескольким экземплярам nLog снижает нагрузку на каждый экземпляр nLog и тем самым повышает скорость, с которой каждый экземпляр nLog может завершить свои операции отображения. Также, это распределение снижает объем памяти, необходимый на каждой сетевой станции, которая исполняет экземпляр контроллера. Некоторые примеры осуществления разделяют операции отображения таблиц nLog по различным экземплярам назначением первой совместной операции, которая исполняется каждым экземпляром nLog, базируясь на параметре LDPS. Это назначение гарантирует, что совместные операции каждого экземпляра nLog будут неадекватными и немедленно прекратятся, когда этот экземпляр запускает совокупность совместных операций, относящиеся к LDPS, который не управляется этим экземпляром nLog. Несколько примеров использования механизма nLog описаны во введенной выше патентной заявке США 13/177,533.

F. Слой управления

На Фиг. 10 иллюстрируется приложение управления 1000 некоторых примеров осуществления изобретения. Это приложение 1000 используется в некоторых примерах осуществления как модуль управления 625 на Фиг. 6. Это приложение 1000 использует механизм отображения таблиц nLog для отображения таблиц входных данных, которые содержат кортежи входных данных, представляющих данные LCP, в кортежи данных, представляющих данные LFP. Это приложение постоянно хранится на верхнем уровне приложения виртуализации 1005, которое получает кортежи данных, специфицирующих совокупности LDP, от приложения управления 1000. Приложение виртуализации 1005 отображает кортежи данных на данные UPCP.

Более конкретно, приложение управления 1000 предоставляет различным пользователям возможность определять различные совокупности LDP, которые специфицируют желаемую конфигурацию логического переключающего элемента, управляемого пользователями. Приложение управления 1000 посредством этих операций отображения преобразует данные каждой LDPS каждого пользователя в совокупность кортежей данных, которые специфицируют данные LFP логического переключающего элемента, связанного с LDPS. В некоторых примерах осуществления, приложение управления исполняется на том же самом хосте, на котором исполняется приложение виртуализации 1005. В других примерах осуществления приложение управления и приложение виртуализации не должны исполняться на одной и той же сетевой станции.

Как показывается на Фиг. 10, приложение управления 1000 содержит совокупность таблиц входных данных механизма правил 1010, совокупность таблиц функций и констант 1015, импортер 1020, механизм правил 1025, совокупность таблиц выходных данных механизма правил 1045, транслятор 1050, экспортер 1055, PTD 1060 и компилятор 1035. Компилятор 1035 является одним из компонентов приложения, который оперирует на отличном по времени экземпляре, чем оперируют компоненты других приложений. Компилятор работает, когда разработчику необходимо специфицировать механизм правил определенного приложения управления и/или виртуализированной среды, в то время как остальные модули приложения работают во время исполнения, когда приложение соединяется с приложением виртуализации для развертывания совокупностей LDP, специфицированных одним или более пользователями.

В некоторых примерах осуществления, компилятор 1035 занимает относительно небольшой набор (например, несколько сотен строк) декларативных команд 1040, которые специфицируются на декларативном (непроцедурном) языке, и преобразует команды в большой набор (например, тысячи строк) кода (то есть, в объектную программу), который специфицирует операцию механизма правил 1025, выполняющего отображение таблицы приложения. По существу, компилятор существенно упрощает для разработчика приложения управления процесс определения и обновления приложения управления. Это следует из того, что компилятор позволяет разработчику использовать язык программирования высокого уровня, что обеспечивает компактное определение комплексной операции отображения приложения управления и последующее обновление этой операции отображения в ответ на любое число изменений (например, изменения в логических сетевых функциях, поддерживаемых приложением управления, изменения желаемого поведения приложения управления и проч.). Более того, компилятор освобождает разработчика от рассмотрения порядка, в котором на приложение управления будут прибывать входные сообщения, когда разработчик определяет операцию отображения.

В некоторых примерах осуществления, таблицы входных данных механизма правил (RE) 1010 содержит таблицы с логическими данными и/или конфигурациями переключения (например, конфигурации списка управления доступом, конфигурации частной виртуальной сети, конфигурации защиты портов и пр.), специфицированные пользователем и/или приложением управления. В некоторых примерах осуществления, таблицы входных данных 1010 включают также таблицы, которые содержат физические данные от переключающих элементов, управляемых сетевой системой управления. В некоторых примерах осуществления, такие физические данные включают данные, касающиеся управляемых переключающих элементов, и другие данные, касающиеся конфигурации сети, используемой сетевой системой управления для развертывания различных совокупностей LDP различных пользователей.

Таблицы входных данных RE 1010 частично пополняются данными LCP, предоставляемыми пользователями. Таблицы входных данных RE 1010 содержат также данные LFP и данные UPCP. Дополнительно к таблицам входных данных RE 1010, приложение управления 1000 включает другие смешанные таблицы 1015, которые механизм правил 1025 использует для сбора входных данных для своих операций отображения таблиц. Эти таблицы 1015 содержат таблицы констант, которые хранят определенные значения констант, необходимые механизму правил 1025 для выполнения операций отображения таблиц. Например, таблицы констант 1015 могут содержать константу "zero", которая определяется как значение 0, константу "dispatch_port_no", как значение 4000, и константу "broadcast_MAC_addr", как значение 0×FF:FF:FF:FF:FF:FF.

Когда механизм правил 1025 обращается к константам, отыскиваются и используются соответствующие значения, определенные для констант. Кроме того, значения, определенные для констант в таблицах констант 1015, могут быть модифицированы и/или обновлены. Подобным образом, таблицы констант 1015 предоставляют возможность модифицировать значения, определенные для констант, к которым ссылается механизм правил 1025, без необходимости переписывать или перекомпилировать код, который специфицирует операцию механизма правил 1025. Таблицы 1015 содержат также таблицы функций, хранящие функции, которые механизму правил 1025 необходимо использовать для вычисления значений, требуемых при пополнении таблиц выходных данных 1045.

Механизм правил 1025 выполняет операции отображения таблиц, которые специфицируют один способ преобразования данных LCP в данные LFP. Всякий раз, когда модифицируется одна из таблиц входных данных механизма правил (RE), механизм правил выполняет набор операций отображения таблицы, что может приводить к модификации одного или более кортежей данных в одной или более таблиц выходных данных RE.

Как показывается на Фиг. 10, механизм правил 1025 включает процессор событий 1022, несколько планов запросов 1027 и процессор таблиц 1030. Каждый план запроса является совокупностью правил, специфицирующих совокупность совместных операций, которые должны быть выполнены при возникновении модификации одной из таблиц входных данных RE. Такая модификация именуется далее, как событие таблицы входных данных. В этом примере, каждый план запроса генерируется компилятором 1035 из одного декларативного правила в совокупности деклараций 1040. В некоторых примерах осуществления, из одного декларативного правила генерируется более одного плана запроса. Например, план запроса создается для каждой из таблиц, объединенной одним декларативным правилом. То есть, когда декларативное правило специфицирует объединение четырех таблиц, из этой одной декларации будут созданы четыре различных планов запроса. В некоторых примерах осуществления, планы запроса определяются использованием декларативного языка nLog.

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

В ответ на обнаруженное событие в таблице входных данных, процессор событий 1022 (1) выбирает надлежащий план запроса для обнаруженного события таблицы, и (2) отдает команду процессору таблиц 1030 на исполнение плана запроса. В некоторых примерах осуществления, процессор таблиц 1030 для исполнения плана запроса выполняет совместные операции, специфицированные планом запроса, для образования одной или более записей, которые представляют одну или более совокупностей значений данных от одной или более таблиц входных данных и таблиц смешанных данных 1010 и 1015. Затем процессор таблиц 1030 некоторых примеров осуществления (1) выполняет операцию селекции для выбора подмножества значений данных из записи (записей), образованных совместными операциями, и (2) записывает выбранное подмножество значений данных в одну или более таблиц выходных данных RE 1045.

В некоторых примерах осуществления, таблицы выходных данных RE 1045 хранят атрибуты элементов данных как логической, так и физической сети. Таблицы 1045 называются таблицами выходных данных RE, поскольку они хранят выходные данные операций отображения таблиц механизма правил 1025. В некоторых примерах осуществления, таблицы выходных данных RE могут быть сгруппированы по нескольким различным категориям. Например, в некоторых примерах осуществления, этими таблицами могут быть таблицы входных данных RE и/или таблицы выходных данных приложения управления (СА). Таблица является таблицей входных данных RE, когда изменение в таблице приводит к тому, что механизм правил обнаруживает входное событие, которое требует исполнения плана запроса. Таблица выходных данных RE 1045 может также быть таблицей входных данных RE 1010, генерирующей событие, которое приводит к тому, что механизм правил исполняет другой план запроса. Такое событие именуется здесь как внутреннее входное событие, и оно должно быть противоположностью внешнему входному событию, которое является событием, инициируемым модификацией таблицы входных данных RE, произведенной приложением управления 1000 или импортером 1020.

Таблица является таблицей выходных данных СА, когда изменение в таблице приводит к тому, что экспортер 1055 переносит изменение в приложение виртуализации 1005, как это будет описано ниже. В некоторых примерах осуществления, таблица в таблицах выходных данных RE 1045 может быть таблицей входных данных RE, таблицей выходных данных СА или как таблицей входных данных RE, так и таблицей выходных данных СА.

Экспортер 1055 обнаруживает изменения в таблицах выходных данных СА таблиц выходных данных RE 1045. Экспортер различных примеров осуществления обнаруживает возникновение события в таблицах выходных данных СА по разному. В некоторых примерах осуществления, экспортер регистрирует обратные вызовы таблицами выходных данных СА для уведомления изменений в записях таблиц выходных данных СА. В таких примерах осуществления, экспортер 1055 обнаруживает событие в таблице выходных данных, когда он получает уведомление от таблицы выходных данных СА о том, что одна из ее записей изменилась.

В ответ на обнаруженное событие в таблицах выходных данных, экспортер 1055 принимает некоторые или все из кортежей модифицированных данных в модифицированных таблицах выходных данных СА и распространяет кортежи (кортеж) модифицированных данных в таблицы входных данных (не показаны) приложения виртуализации 1005. В некоторых примерах осуществления, вместо экспортера 1055, продвигающего кортежи данных в приложение виртуализации, приложение виртуализации 1005 перемещает кортежи данных из таблиц выходных данных СА 1045 в таблицы входных данных приложения виртуализации. В некоторых примерах осуществления, таблицы выходных данных СА 1045 приложения управления 1000 и таблицы входных данных приложения виртуализации 1005 могут быть идентичными. В других же примерах осуществления, приложения управления и виртуализации используют одну совокупность таблиц, так что таблицы выходных данных СА являются, по существу, таблицами входных данных приложения виртуализации (VA).

В некоторых примерах осуществления, приложение управления не хранит в таблицах выходных данных 1045 данные совокупностей LDP, за управление которыми не ответственно приложение управления. Однако такие данные будут транслироваться транслятором 1050 в формат, который может быть сохранен в PTD, и действительно хранятся в PTD. PTD приложения управления 1000 распространяет эти данные на один или более других экземпляров приложения управления других экземпляров контроллеров, так что некоторые из других экземпляров контроллеров, которые ответственны за управление совокупностями LDP, связанными с этими данными, могут обрабатывать данные.

В некоторых примерах осуществления, приложение управления также доставляет данные, хранимые в таблицах выходных данных 1045 (то есть, данные, которые приложение управления содержит в таблицах выходных данных), на PTD для устойчивости данных к ошибкам. Такие данные также транслируются транслятором 1050, хранимым в PTD, и распространяются на другие экземпляры приложений управления других экземпляров контроллеров. Поэтому, в этих примерах осуществления, PTD экземпляра контроллера имеет все конфигурационные данные для всех совокупностей LDP, управляемых сетевой системой управления. То есть, в некоторых примерах осуществления каждый PTD содержит глобальное представление о конфигурации логической сети.

Импортер 1020 сообщается с рядом различных источников входных данных и использует эти входные данные для модифицирования или создания таблиц входных данных 1010. Импортер 1020 некоторых примеров осуществления получает входные данные от приложения трансляции входных данных 1070 через интерфейс связи между контроллерами (не показан). Импортер 1020 также сообщается с PTD 1060, так что данные, полученные через PTD от других экземпляров контроллеров, могут быть использованы как входные данные для модифицирования или создания таблиц входных данных 1010. Более того, импортер 1020 также обнаруживает изменения таблиц входных данных RE и таблиц входных данных RE вместе с таблицами выходных данных СА таблиц выходных данных RE 1045.

G. Слой виртуализации

Как было упомянуто выше, приложение виртуализации некоторых примеров осуществления специфицирует тот способ, которым различные совокупности LDP различных пользователей сетевой системы управления могут быть реализованы переключающими элементами, управляемыми сетевой системой управления. В некоторых примерах осуществления, приложение виртуализации специфицирует реализацию совокупностей LDP внутри инфраструктуры управляемых переключающих элементов выполнением операций преобразования. Эти операции преобразования преобразуют записи данных совокупностей LDP в записи управляющих данных (например, данные UPCP), которые первоначально хранятся внутри управляемых переключающих элементов, а затем используются этими переключающими элементами для образования данных плоскости продвижения данных (например, потоковых входных сообщений) для определения поведений переключающих элементов при продвижении данных. Операции преобразования создают также другие данные (например, в таблицах), специфицирующие конструктивные компоненты сети (например, туннели, очереди, совокупности очередей и пр.), которые должны быть определены внутри управляемых переключающих элементов и между ними. Конструктивные компоненты сети включают также управляемые программные переключающие элементы, которые динамически развертываются или предварительно конфигурируются управляемыми программными переключающими элементами, которые динамически добавляются к совокупности управляемых переключающих элементов.

На Фиг. 11 иллюстрируется приложение виртуализации 1100 некоторых примеров осуществления изобретения. Это приложение 1100 используется в некоторых примерах осуществления как модуль виртуализации 630 на Фиг. 6. Приложение виртуализации 1100 использует механизм отображения таблиц nLog для отображения таблиц входных данных, которые содержат кортежи данных LDPS, представляющие данные UPCP. Это приложение постоянно находится ниже уровня приложения управления 1105, которое генерирует кортежи данных LDPS. Приложение управления 1105 аналогично приложению управления 1000, описанному выше со ссылкой на Фиг. 10. Приложение виртуализации 1100 аналогично приложению виртуализации 1005.

Как показывается на Фиг. 11, приложение виртуализации 1100 содержит совокупность таблиц входных данных механизма правил 1110, совокупность таблиц функций и констант 1115, импортер 1120, механизм правил 1125, совокупность таблиц выходных данных механизма правил 1145, транслятор 1150, экспортер 1155, PTD 1160 и компилятор 1135. Компилятор 1135 аналогичен компилятору 1035, описанному выше со ссылками на Фиг. 10.

Для того чтобы приложение виртуализации 1100 отображало кортежи данных LDPS на кортежи данных UPCP, разработчик в некоторых примерах осуществления специфицирует на декларативном языке декларативные команды 1140, которые содержат команды отображения кортежей данных LDPS в кортежи данных UPCP некоторых управляемых переключающих элементов. В некоторых примерах осуществления, эти переключающие элементы содержат несколько UPCP для преобразования данных UPCP в данные СРСР.

Для других управляемых переключающих элементов приложение виртуализации 1100 отображает кортежи данных LDPS в кортежи данных СРСР, которые специфицируются для каждого управляемого переключающего элемента, не имеющего UPCP. В некоторых примерах осуществления, когда приложение виртуализации 1100 получает данные UPCP от приложения виртуализации другого экземпляра контроллера, приложение виртуализации 1100 затем отображает кортежи данных UPCP в таблицах выходных данных 1140 в кортежи данных СРСР некоторого управляемого переключающего элемента, который не имеет UPCP, для преобразования кортежей данных универсальной плоскости физического управления в кортежи данных совокупностей физических информационных каналов данных.

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

Таблицы входных данных RE 1100 аналогичны таблицам входных данных RE 1010. Дополнительно к таблицам входных данных RE 1110, приложение виртуализации 1100 содержит другие смешанные таблицы 1115, которые механизм правил 1125 использует при сборе входных данных для своих операций отображения таблиц. Эти таблицы 1115 аналогичны таблицам 1015. Как показывается на Фиг. 11, механизм правил 1125 содержит процессор событий 1122, несколько планов запросов 1127 и процессор таблиц 1130, которые функционируют аналогично тому, как это делают процессор событий 1022, планы запросов 1027 и процессор таблиц 1030.

В некоторых примерах осуществления, таблицы выходных данных RE 1145 хранят атрибуты элементов данных как логической, так и физической сети. Таблицы 1145 называются таблицами выходных данных RE, поскольку они хранят выходные данные операций отображения таблиц механизма правил 1125. В некоторых примерах осуществления, таблицы выходных данных RE могут быть сгруппированы по нескольким различным категориям. Например, в некоторых примерах осуществления, эти таблицы могут быть таблицами входных данных RE и/или таблицами выходных данных приложения виртуализации (VA). Таблица является таблицей входных данных RE, когда изменение в таблице является причиной того, что механизмом правил обнаруживает входное событие, которое требует исполнения плана запроса. Таблица выходных данных RE 1145 также может быть таблицей входных данных RE 1110, генерирующей событие, которое является причиной того, что механизм правил исполняет другой план запроса после его модифицирования механизмом правил. Такое событие именуется как внутреннее входное событие, и оно должно быть противоположностью внешнему входному событию, которое является событием, инициируемым модификацией таблицы входных данных RE, произведенной приложением управления 1105 посредством импортера 1120.

Таблица является таблицей выходных данных VA, когда изменение в таблице является причиной того, что экспортер 1155 экспортирует изменение в управляемые переключающие элементы или другие экземпляры контроллеров. Как показывается на Фиг. 12, в некоторых примерах осуществления, таблица в таблицах выходных данных RE 1145 может быть таблицей входных данных RE 1110, таблицей выходных данных VA 1205 или как таблицей входных данных RE 1110, так и таблицей выходных данных VA 1205.

Экспортер 1155 обнаруживает изменения в таблицах выходных данных VA 1205 таблиц выходных данных RE 1145. Экспортер различных примеров осуществления обнаруживает возникновение события в таблицах выходных данных VA по разному. В некоторых примерах осуществления, экспортер регистрирует обратные вызовы таблицами выходных данных VA для уведомления изменений в записях таблиц выходных данных VA. В таких примерах осуществления, экспортер 1155 обнаруживает событие таблицы выходных данных, когда он получает уведомление от таблицы выходных данных VA о том, что одна из ее записей изменилась.

В ответ на обнаруженное событие в таблице выходных данных, экспортер 1155 принимает каждый кортеж модифицированных данных в модифицированных таблицах выходных данных VA и распространяет этот кортеж модифицированных данных на один или более других экземпляров контроллеров (например, базовый контроллер) или на один или более управляемых переключающих элементов. Делая это, экспортер завершает развертывание LDPS (например, одной или более логических конфигураций переключения) на один или более управляемых переключающих элементов, как специфицировано записями.

Поскольку в некоторых примерах осуществления таблицы выходных данных VA хранят элементарные атрибуты данных как логической, так и физической сети, то PTD 1160 в некоторых примерах осуществления хранит элементарные атрибуты как логической, так и физической сети, которые идентичны элементарным атрибутам данных логической и физической сети в таблицах выходных данных 1145 или выводятся из этих атрибутов. Однако в других примерах осуществления, PTD 1160 хранит только элементарные атрибуты физической сети, которые идентичны элементарным атрибутам данных физической сети в таблицах выходных данных 1145 или выводятся из этих атрибутов.

В некоторых примерах осуществления, приложение виртуализации не хранит в таблицах выходных данных 1145 данные совокупностей LDP, за управление которыми не ответственно приложение виртуализации. Однако такие данные будут транслироваться транслятором 1150 в формат, который может быть сохранен в PTD, а затем сохраняется в PTD. PTD приложения виртуализации 1100 распространяет эти данные на один или более других экземпляров приложения виртуализации других экземпляров контроллеров, так что обрабатывать эти данные могут некоторые из других экземпляров приложения виртуализации, которые ответственны за управление совокупностями LDP, связанными с этими данными.

В некоторых примерах осуществления, приложение виртуализации может также доставлять данные, хранимые в таблицах выходных данных 1145 (то есть, данные, которые приложение виртуализации содержит в таблицах выходных данных), к PTD для устойчивости этих данных к ошибкам. Такие данные также транслируются транслятором 1150, хранимым в PTD, и передаются на другие экземпляры приложения виртуализации других экземпляров контроллеров. Поэтому, в этих примерах осуществления, PTD экземпляра контроллера имеет все конфигурационные данные всех совокупностей LDP, управляемых сетевой системой управления. То есть, в некоторых примерах осуществления каждый PTD содержит глобальное представление о конфигурации логической сети.

Импортер 1120 сообщается с рядом различных источников входных данных и использует эти входные данные для модифицирования или создания таблиц входных данных 1110. Импортер 1120 некоторых примеров осуществления получает входные данные от приложения трансляции входных данных 1170 через интерфейс связи между контроллерами. Импортер 1120 также сообщается с PTD 1160, так что данные, полученные через PTD от других экземпляров контроллеров, могут быть использованы как входные данные для модифицирования или создания таблиц входных данных 1110. Более того, импортер 1120 также обнаруживает изменения таблиц входных данных RE и таблиц входных данных RE вместе с таблицами выходных данных СА таблиц выходных данных RE 1145.

Н. Сетевой контроллер

На Фиг. 13 иллюстрируется упрощенное представление операций отображения таблиц приложений управления и виртуализации некоторых примеров осуществления изобретения. Как показано в верхней половине этого рисунка, приложение управления 1305 отображает данные LCP в данные LFP, которые приложение виртуализации 1310 некоторых примеров осуществления отображает затем в данные UPCP или данные СРСР.

На нижней половине этого рисунка иллюстрируются операции отображения таблиц приложения управления и приложения виртуализации. Как показывается на этой половине, таблицы входных данных приложения управления 1315 хранят данные LCP, данные LFP (LFP) и данные UPCP, и совокупность всех этих данных, вместе с данными в таблицах констант и функций (не показаны), в некоторых примерах осуществления используются механизмом nLog 1320 приложения управления для генерации данных LFP из входных данных LCP.

Этот рисунок показывает, что импортер 1350 получает данные LCP от пользователя (например, через приложение трансляции входных данных) и обновляет данными LCP таблицы входных данных 1315 приложения управления. Этот рисунок показывает также, что импортер 1350 обнаруживает или получает изменения в PTD 1340 (например, изменения данных LCP, исходящие от других экземпляров контроллеров) в некоторых примерах осуществления и в ответ на такие изменения импортер 1350 может обновлять таблицы входных данных 1315.

На нижней половине этого рисунка иллюстрируются также операции отображения таблиц приложения виртуализации 1310. Как показано, таблицы входных данных приложения виртуализации 1355 хранят данные LFP, как данные LFP, и совместно с данными в таблицах констант и функций (не показаны) используются механизмом nLog 1320 приложения виртуализации в некоторых примерах осуществления для генерации данных UPCP и/или данных СРСР. В некоторых примерах осуществления, экспортер 1370 пересылает сгенерированные данные UPCP на один или более других экземпляров контроллеров (например, базовый контроллер) для генерации данных СРСР перед продвижением этих данных на управляемые переключающие элементы или на один или более управляемых переключающих элементов, которые преобразуют данные UPCP в данные СРСР, специфичные для этих управляемых переключающих элементов. В других примерах осуществления, экспортер 1370 пересылает сгенерированные данные СРСР на один или более управляемых переключающих элементов для определения поведений продвижения данных этих управляемых переключающих элементов.

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

На этом рисунке показывается, что импортер 1375 получает данные LFP от приложения управления 1305 и этими данными LFP обновляет таблицы входных данных 1355 приложения виртуализации. На этом рисунке также показывается, что импортер 1375 обнаруживает или получает изменения в PTD 1340 (например, изменения данных LCP, исходящие от других экземпляров контроллеров) в некоторых примерах осуществления и в ответ на такие изменения импортер 1375 может обновлять таблицы входных данных 1355. На этом рисунке также показывается, что импортер 1375 может получать данные UPCP от другого экземпляра контроллера.

Как было упомянуто выше, некоторые из логических или физических данных, которые импортер помещает в таблицы входных данных приложения управления или виртуализации, относятся к данным, которые генерируются другими экземплярами контроллеров и пересылаются на PTD. Например, в некоторых примерах осуществления, логические данные, касающиеся логических структурных компонентов (например, логические порты, логические очереди и проч.), которые относятся к многим совокупностям LDP, могли бы измениться, и транслятор (например, транслятор 1380 экземпляра контроллера) может записать это изменение в таблицы входных данных. Другой пример таких логических данных, которые создаются другим экземпляром контроллера в среде многих экземпляров контроллеров, возникает тогда, когда пользователь предоставляет данные LCP для LDPS на первом экземпляре контроллера, который не ответствен за эти LDPS. Это изменение добавляется транслятором первого экземпляра контроллера к PTD первого экземпляра контроллера. Это изменение распространяется затем по многим PTD других экземпляров контроллеров процессами образования реплик, исполняемыми многими PTD. Импортер второго экземпляра контроллера, который является задающим контроллером LDPS, или логический контроллер, который ответственен за LDPS, в конечном счете получает это изменение, а затем записывает изменение в таблицы входных данных одного из приложений (например, в таблицу входных данных приложения управления). Соответственно, логические данные, которые импортер записывает в таблицы входных данных, могут в некоторых случаях происходить от PTD другого экземпляра контроллера.

Как было упомянуто выше, приложение управления 1305 и приложение виртуализации 1310 являются двумя отдельными приложениями, которые в некоторых примерах осуществления работают на одной и той же сетевой станции или на раздельных сетевых станциях. Однако в других примерах осуществления эти два приложения реализуются как два модуля одного интегрированного приложения, при том модуль приложения управления 1305 генерирует логические данные в LFP, а модуль приложения виртуализации генерирует физические данные в UPCP или в СРСР.

В других примерах осуществления, операции управления и виртуализации этих двух приложений объединяются в одно интегрированное приложение, без разделения этих операций на два раздельных модуля. На Фиг. 14 иллюстрируется пример такого интегрированного приложения 1400. В этом приложении 1400 используется механизм отображения таблиц nLog 1400 для отображения данных из совокупности таблиц входных данных 1415 в совокупность таблиц выходных данных 1420, которые аналогично описанным выше примерам осуществления на Фиг. 10, 11 и 13 могут содержать одну или более таблиц в совокупности таблиц входных данных. Совокупность таблиц входных данных в этом интегрированном приложении может содержать данные LCP, которые необходимо будет отобразить в данные LFP, или она может содержать данные LFP, которые необходимо будет отобразить в данные СРСР или UPCP. Эта совокупность таблиц входных данных может также содержать данные UPCP, которые необходимо будет отобразить в данные СРСР. Данные UPCP распределяются по совокупности базовых контроллеров совокупности управляемых переключающих элементов без отображения в данные СРСР. Отображение зависит от того, является ли экземпляр контроллера, исполняющего интегрированное приложение 1400, логическим контроллером или физическим контроллером, и от того, имеют ли управляемые переключающие элементы, задающим контроллером которых является физический контроллер, базовый контроллер для отображения данных UPCP в данные СРСР управляемых переключающих элементов.

В этом интегрированном приложении управления и виртуализации 1400 импортер 1430 получает входные данные от пользователей или от других экземпляров контроллеров. Импортер 1430 также обнаруживает или получает изменения в PTD 1440, которые дублируются в PTD. Экспортер 1425 переносит записи таблиц выходных данных на другие экземпляры контроллеров (например, на базовый контроллер).

Когда записи таблицы выходных данных посылаются на другой экземпляр контроллера, то экспортер использует интерфейс связи между контроллерами (не показан) так, что данные, содержащиеся в записях, пересылаются на другой экземпляр контроллера через канал связи (например, через канал PRC). Когда записи таблицы выходных данных посылаются на управляемые переключающие элементы, то экспортер использует интерфейс связи управляемого переключающего элемента (не показан), так что данные, содержащиеся в записях, посылаются на управляемый переключающий элемент через два канала. Один канал устанавливается с использованием протокола управления переключениями (например, OpenFlow) для управления плоскостью продвижения данных управляемого переключающего элемента, а другой канал устанавливается с использованием протокола конфигурации для пересылки конфигурационных данных.

Когда записи таблицы выходных данных посылаются на базовый контроллер, то экспортер 1425 в некоторых примерах осуществления использует единственный канал связи для посылки данных, содержащихся в записях. В этих примерах осуществления, базовый контроллер принимает данные через этот единственный канал, но с управляемым переключающим элементом сообщается через два канала. Базовый контроллер описывается более подробно несколько ниже со ссылками на Фиг. 18.

На Фиг. 15 иллюстрируется другой пример такого интегрированного приложения 1500. Интегрированное приложение 1500 использует структуру данных сетевой информационной базы (NIB) 1510 для хранения некоторых из входных и выходных данных механизма отображении таблиц nLog 1410. Как было упомянуто выше, структура данных NIB хранит данные в форме объектов объект-ориентированных данных. В интегрированном приложении 1500 таблицы выходных данных 1420 являются структурами первичной памяти. PTD 1440 и NIB 1510 являются структурами вторичной памяти.

Интегрированное приложение 1500 использует механизм отображения таблиц nLog 1410 для отображения данных из совокупности таблиц входных данных 1415 в совокупность таблиц выходных данных 1420. В некоторых примерах осуществления, некоторые из данных в совокупности таблиц выходных данных 1420 переносятся экспортером 1425 на один или более других экземпляров контроллеров или один или более других управляемых переключающих элементов. Такие экспортированные данные включают данные UPCP или СРСР, которые будут определять потоковые поведения управляемых переключающих элементов. Эти данные могут быть продублированы в PTD транслятором 1435 в PTD 1440 для устойчивости данных к ошибкам.

Некоторые из данных в совокупности таблиц выходных данных 1420 помещаются в NIB 1510 посредством публикатора NIB 1505. Эти данные включают конфигурационную информацию логических переключающих элементов, которая управляется пользователями, используя интегрированное приложение 1500. Данные, хранящиеся в NIB 1510, реплицируются в другие NIB других экземпляров контроллеров администратором координации 1520.

Монитор NIB 1515 получает уведомления об изменениях от NIB 1510, и для некоторых уведомлений (например, тех, которые относятся к совокупностям LDP, для которых интегрированное приложение является задающим контроллером) помещает изменения в таблицы входных данных 1415 посредством импортера 1430.

Администратор запросов 1525 использует интерфейс связи между контролерами (не показан) для соединения с приложением трансляции входных данных (не показано) и получения запросов (например, информационных запросов), касающихся конфигурационных данных. Как показывается на этом рисунке, администратор 1525 некоторых примеров осуществления также соединяется с NIB 1510, с тем, чтобы запросить NIB о предоставлении информации состояния (например, статистики логических портов), касающейся элементов логической сети, которые управляются пользователем. Однако в других примерах осуществления, для получения информации состояния администратор запросов 1525 запрашивает таблицы выходных данных 1420.

В некоторых примерах осуществления, приложение 1500 использует структуры вторичной памяти (не показаны), отличные от структур PTD и NIB. Эти структуры включают долговременную не транзактную базу данных (PNTD) и хэш-таблицу. В некоторых примерах осуществления, эти два типа структур вторичной памяти хранят различные типы данных, хранят данные в различных представлениях и/или образуют различные интерфейсы запроса, которые обрабатывают различные типы запросов.

PNTD является долговременной базой данных, которая хранится на диске или другом энергонезависимом запоминающем устройстве. Некоторые примеры осуществления используют эту базу данных для хранения данных (например, статистик, результатов вычислений и проч.), касающихся одного или более атрибутов переключающих элементов или операций. Например, эта база данных используется в некоторых примерах осуществления для хранения списка пакетов, направляемых через определенный порт определенного переключающего элемента. Другие примеры типов данных, хранимых в PNTD, включают сообщения об ошибках, системные журналы, предупреждающие сообщения и данные биллинга.

PNTD в некоторых примерах осуществления имеет администратора запросов к базе данных (не показан), который может обрабатывать запросы к базе данных, но поскольку PNTD не является базой данных транзакций, этот администратор запросов не может обрабатывать запросы транзакций со сложными условиями. В некоторых примерах осуществления, обращения к PNTD будут быстрее, чем обращения к PTD, но медленнее, чем обращения к хэш-таблице.

В отличие от PNTD, хэш-таблица не является базой данных, которая хранится на диске или другом энергонезависимом запоминающем устройстве. Вместо этого, она является структурой памяти, которая хранится на энергозависимом запоминающем устройстве (например, ЗУПВ). Она использует методы хэширования, в которых применяются хэш-индексы для быстрой идентификации записей, хранимых в таблице. Эта структура, объединенная с размещением хэш-таблицы в системной памяти, обеспечивает очень быстрое обращение к этой таблице. В некоторых примерах осуществления для облегчения такого быстрого обращения используется упрощенный интерфейс запроса. Например, в некоторых примерах осуществления, хэш-таблица имеет только два запроса: запрос "Put" для записи значений в таблицу и запрос "Get" для извлечения значений из таблицы. В некоторых примерах осуществления хэш-таблица используется для хранения данных, которые быстро изменяются. Примерами таких быстро изменяющихся данных являются статус сетевого объекта, статистика, состояние, период работоспособности, размещение ссылок и информация пакетной обработки. Кроме того, в некоторых примерах осуществления, интегрированное приложение использует хэш-таблицы в качестве кэш-памяти для хранения информации, которая запрашивается многократно, такая как потоковые входные сообщения, которые будут записаны на многих узлах. В некоторых примерах осуществления хэш-структура используется в NIB для быстрого обращения к записям в NIB. Соответственно, в некоторых из этих примеров осуществления, хэш-таблица является частью структуры данных NIB.

PTD и PNTD улучшают устойчивость контроллера к ошибкам за счет сохранения сетевых данных на жестких дисках. Если система контроллера отказывает, то данные сетевой конфигурации будут сохранены на диске в PTD, а информация журнала регистрации событий будет сохранена на диске в PNTD.

I. Иерархия сетевой системы управления

На Фиг. 16 концептуально иллюстрируется пример архитектуры сетевой системы управления 1600. В частности, на этом рисунке иллюстрируется генерация данных СРСР из входных данных различных элементов сетевой системы управления. Как показывается, сетевая система управления 1600 некоторых примеров осуществления содержит контроллер трансляции входных данных 1605, логический контроллер 1610, физические контроллеры 1615 и 1620 и три управляемых переключающих элемента 1625-1635. На этом рисунке показываются также пять сетевых станций 1640-1660, которые подсоединены к управляемым переключающим элементам (обозначенным на рисунке как "M.S.E.") 1625-1635 для обмена данными между сетевыми станциями. Специфические особенности архитектуры, такие как число контроллеров в каждом слое иерархии, число управляемых переключающих элементов и сетевых станций, а также отношения между контроллерами, управляемыми переключающими элементами и сетевыми станциями, показанные на этом рисунке, являются только иллюстрацией. Любой рядовой специалист в данной области техники признает, что в сетевой системе управления 1600 возможно много других различных комбинаций контроллеров, переключающих элементов и сетевых станций.

В некоторых примерах осуществления, каждый из контроллеров в сетевой системе управления имеет полный набор различных модулей и интерфейсов, описанных выше со ссылками на Фиг. 6. Однако каждый контроллер вовсе не должен использовать все эти модули и интерфейсы для выполнения функций, заданных для контроллера. В альтернативном варианте, в некоторых примерах осуществления, контроллер в системе имеет только те модули и интерфейсы, которые являются необходимыми для выполнения функций, заданных для контроллера. Например, логический контроллер 1610, который является задающим контроллером LDPS, не содержит модуля ввода (например, приложение трансляции входных данных), но необходимо содержит модуль управления и модуль виртуализации (например, приложение управления или приложение виртуализации или же интегрированное приложение) для генерации данных UPCP из входных данных LCP.

Более того, в одной и той же сетевой станции могут исполняться различные комбинации различных контроллеров. Например, контроллер трансляции входных данных 1605 и логический контроллер 1610 могут исполняться на одном и том же вычислительном устройстве. Также и один контроллер может функционировать различно при различных совокупностях LDP. Например, один контроллер может быть и задающим контроллером первой LDPS, и задающим контроллером управляемого переключающего элемента, который реализует вторую LDPS.

Контроллер трансляции входных данных 1605 включает приложение трансляции входных данных (не показано), которое генерирует данные LCP из входных данных, полученных от пользователя, который специфицирует определенную LDPS. Контроллер трансляции входных данных 1605 идентифицирует из конфигурационных данных системы 1605 задающий контроллер LDPS. В этом примере, задающим контроллером LDPS является логический контроллер 1610. В некоторых примерах осуществления, более одного контролера могут быть задающими контроллерами одной и той же LDPS. Также и один логический контроллер может быть задающим контроллером более чем одной совокупностей LDP.

Логический контроллер 1610 ответственен за определенную LDPS. Логический контроллер 1610, таким образом, генерирует данные UPCP из данных LCP, полученных от контроллера трансляции входных данных. В частности, модуль управления (не показан) логического контроллера 1610 генерирует данные LFP из полученных данных LCP, а модуль виртуализации (не показан) логического контроллера 1610 генерирует данные UPCP из данных LFP.

Логический контроллер 1610 идентифицирует физические контроллеры, которые являются задающими контроллерами управляемых переключающих элементов, реализующих LDPS. В этом примере, логический контроллер 1610 идентифицирует физические контроллеры 1615 и 1620, поскольку управляемые переключающие элементы 1625 - 1635 сконфигурированы так, что в этом примере реализуют LDPS. Логический контроллер 1610 пересылает сгенерированные данные UPCP на физические контроллеры 1615 и 1620.

Каждый из физических контроллеров 1615 и 1620 может быть задающим контроллером одного или более управляемых переключающих элементов. В этом примере, физический контроллер 1615 является задающим контроллером двух управляемых переключающих элементов 1625 и 1630, а физический контроллер 1620 является задающим контроллером управляемого переключающего элемента 1635. Физические контроллеры некоторых примеров осуществления, как задающие контроллеры совокупности управляемых переключающих элементов, генерируют из полученных данных UPCP данные СРСР, специфичные для каждого из управляемых переключающих элементов. Поэтому, в этом примере, физический контроллер 1615 генерирует данные РСР, настроенные для каждого из управляемых переключающих элементов 1625 и 1630. Физический контроллер 1320 генерирует данные РСР, настроенные для управляемого переключающего элемента 1635. Физические контроллеры пересылают данные СРСР на управляемые переключающие элементы, задающими контроллерами которых являются эти контроллеры. В некоторых примерах осуществления, задающими контроллерами одних и тех же управляемых переключающих элементов могут быть несколько физических контроллеров.

Физические контроллеры некоторых примеров осуществления, дополнительно к тому, что пересылают данные СРСР, получают данные от управляемых переключающих элементов. Например, физический контроллер получает конфигурационную информацию (например, идентификаторы нескольких VIF управляемого переключающего элемента) управляемых переключающих элементов. Физический контролер обслуживает конфигурационную информацию и также пересылает эту информацию на логические контроллеры, так что логические контроллеры имеют конфигурационную информацию управляемых переключающих элементов, реализующих совокупности LDP, задающими контроллерами которых являются эти логические контроллеры.

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

На Фиг. 17 концептуально иллюстрируется пример архитектуры сетевой системы управления 1700. Как и Фиг. 16, этот рисунок иллюстрирует генерацию данных СРСР из входных данных различными элементами сетевой системы управления. В отличие от сетевой системы управления 1600 на Фиг. 16, сетевая система управления 1700 содержит базовые контроллеры 1725-1735. Как показано, сетевая система управления некоторых примеров осуществления содержит контроллер трансляции входных данных 1705, логический контроллер 1610, физические контроллеры 1715 и 1720, базовые контроллеры 1725-1735 и три управляемых переключающих элемента 1740-1750. На этом рисунке показываются также пять сетевых станций 1755-1775, которые подсоединены к управляемым переключающим элементам 1740-1750 для обмена данными между ними. Специфические особенности архитектуры, такие как число контроллеров в каждом слое иерархии, число управляемых переключающих элементов и сетевых станций, а также отношения между контроллерами, управляемыми переключающими элементами и сетевыми станциями, показанные на этом рисунке, являются только иллюстрацией. Любой рядовой специалист в данной области техники признает, что в сетевой системе управления 1700 возможно много других различных комбинаций контроллеров, переключающих элементов и сетевых станций.

Контроллер трансляции входных данных 1705 аналогичен контроллеру трансляции входных данных 1605 в том, что контроллер трансляции входных данных 1705 содержит приложение трансляции входных данных, которое генерирует данные LCP из входных данных, полученных от пользователя, который специфицирует определенную LDPS. Контроллер трансляции входных данных 1705 идентифицирует из конфигурационных данных системы 1705 задающий контроллер LDPS. В этом примере, задающим контроллером LDPS является логический контроллер 1710.

Логический контроллер 1710 аналогичен логическому контролеру 1610, в том, что логический контроллер 1710 генерирует данные UPCP из данных LCP, полученных от контроллера трансляции входных данных 1705. Логический контроллер 1710 идентифицирует физические контроллеры, которые являются задающими контроллерами управляемых переключающих элементов, реализующих LDPS. В этом примере, логический контроллер 1710 идентифицирует физические контроллеры 1715 и 1720, поскольку управляемые переключающие элементы 1740-1750 сконфигурированы так, что в этом примере реализуют LDPS. Логический контроллер 1710 пересылает сгенерированные данные UPCP на физические контроллеры 1715 и 1720.

Подобно физическим контроллерам 1615 и 1620, каждый из физических контроллеров 1715 и 1720 может быть задающим контроллером одного или более управляемых переключающих элементов. В этом примере, физический контроллер 1715 является задающим контроллером двух управляемых переключающих элементов 1740 и 1745, а физический контроллер 1730 является задающим контроллером управляемого переключающего элемента 1750. Однако физические контроллеры 1715 и 1720 не генерируют данные СРСР для управляемых переключающих элементов 1740-1750. Физический контроллер, как задающий контроллер управляемых переключающих элементов, пересылает данные UPCP на базовый контроллер, который ответственен за каждый управляемый переключающий элемент, задающим контроллером которого является физический контроллер. То есть, физический контроллер некоторых примеров осуществления идентифицирует базовые контроллеры, которые соединяются с управляемыми переключающими элементами, задающим контроллером которых является этот физический контролер. В некоторых примерах осуществления, физический контроллер идентифицирует эти базовые контроллеры определением того, приписаны ли базовые контроллеры к каналу физического контролера.

Базовый контроллер некоторых примеров осуществления имеет однозначное соответствие с управляемым переключающим элементом. Базовый контроллер получает данные UPCP от физического контроллера, который является задающим контроллером управляемого переключающего элемента, и генерирует данные СРСР, специфичные для этого управляемого переключающего элемента. Пример архитектуры базового контроллера будет описан несколько ниже со ссылками на Фиг. 18. Базовый контроллер в некоторых примерах осуществления исполняется в той же самой сетевой станции, в которой исполняется управляемый переключающий элемент, которым управляет базовый контроллер, в то время как в других примерах осуществления базовый контроллер и управляемый переключающий элемент исполняются в различных сетевых станциях. В этом примере, базовый контроллер 1725 и управляемый переключающий элемент 1740 исполняются в одном и том же вычислительном устройстве.

Подобно управляемым переключающим элементам 1625-1635, каждый из управляемых переключающих элементов 1740-1750 генерирует данные физической плоскости продвижения данных из данных СРСР, которые получил управляемый переключающий элемент. Управляемые переключающие элементы 1740-1750 заполняют свои соответствующие таблицы продвижения данных, используя данные СРСР. В соответствии с этими потоковыми таблицами, управляемые переключающие элементы 1740-1750 продвигают данные между сетевыми станциями 1755-1775.

Как было упомянуто выше, управляемый переключающий элемент может в некоторых случаях реализовывать более одной LDPS. В таких случаях, физический контроллер, который является задающим контроллером такого управляемого переключающего элемента, получает данные UPCD для каждой из совокупностей LDP. Таким образом, физический контроллер в сетевой системе управления 1700 может функционировать в качестве точки агрегации для пересылки данных UPCP различных совокупностей LDP определенного управляемого переключающего элемента, который реализует совокупности LDP, на базовые контроллеры.

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

В некоторых примерах осуществления, сетевая система управления может представлять собой гибрид сетевых систем управления 1600 и 1700. То есть, в этой гибридной сетевой системе управления некоторые из физических контроллеров генерируют данные СРСР для некоторых из управляемых переключающих элементов, а некоторые из физических контроллеров не генерируют данные СРСР для некоторых из управляемых переключающих элементов. Для последних управляемых переключаемых элементов в гибридной системе имеются базовые контроллеры, которые генерируют данные СРСР.

Как было упомянуто выше, базовый контроллер некоторых примеров осуществления является контроллером для управления единичным управляемым переключаемым элементом. Базовый контроллер некоторых примеров осуществления не имеет полного набора различных модулей и интерфейсов, описанных выше со ссылками к Фиг. 6. Одним из модулей, который действительно имеет базовый контроллер, является приложение базового управления, которое генерирует данные СРСР из данных UPCP, получаемых от одного или более физических контроллеров. На Фиг. 18 иллюстрируется пример архитектуры приложения базового управления 1800. В этом приложении 1800 используется механизм отображения таблиц nLog для отображения таблиц входных данных, которые содержат кортежи входных данных, представляющих данные UPCP, в кортежи данных, представляющих данные LFP. Это приложение 1800 управляет управляемым переключающим элементом 1855 в данном примере посредством обмена данными с управляемым переключающим элементом 1885. В некоторых примерах осуществления, приложение 1800 (то есть, базовый контроллер) исполняется в той же самой сетевой станции, в которой исполняется управляемый переключающий элемент 1885.

Как показывается на Фиг. 18, приложение базового управления 1800 содержит набор таблиц входных данных механизма правил 1810, набор таблиц функций и констант 1815, импортер 1820, механизм правил 1825, набор таблиц выходных данных механизма правил 1845, экспортер 1855, интерфейс связи управляемого переключающего элемента 1865 и компилятор 1835. На этом рисунке показывается также физический контроллер 1805 и управляемый переключающий элемент 1885.

Компилятор 1835 аналогичен компилятору 1035 на Фиг. 10. В некоторых примерах осуществления, таблицы входных данных механизма правил (RE) 1810 содержат таблицы с данными UPCP и/или конфигурациями переключения (например, конфигурации списка управления доступом, конфигурации частных виртуальных сетей, конфигурации защиты портов и проч.), которые физический контроллер 1805, являющийся задающим контроллером управляемого переключающего элемента 1885, пересылает на приложение базового управления 1800. Таблицы входных данных 1810 включают также таблицы, которые содержат физические данные от управляемого переключающего элемента 1885. В некоторых примерах осуществления, такие физические данные включают данные, касающиеся управляемого переключающего элемента 1885 (например, данные СРСР, данные физического продвижения данных) и другие данные, касающиеся конфигурации управляемого переключающего элемента 1885.

Таблицы входных данных RE 1810 аналогичны таблицам входных данных RE 1010. Таблицы входных данных 1810 частично пополняются данными UPCP, предоставляемыми физическим контроллером 1805. Физический контроллер 1805 некоторых примеров осуществления получает данные UPCP от одного или более логических контроллеров (не показаны).

Дополнительно к таблицам входных данных 1810, приложение базового управления 1800 включает другие смешанные таблицы 1815, которые механизм правил 1825 использует для сбора входных данных своих операций отображения таблиц. Эти таблицы 1815 аналогичны таблицам 1015. Как показывается на Фиг. 18, механизм правил 1825 содержит процессор событий 1822, несколько планов запросов 1827 и процессор таблиц 1830, которые функционируют подобно тому, как это делают процессор событий 1022, планы запросов 1027 и процессор таблиц 1030.

В некоторых примерах осуществления, таблицы выходных данных RE 1845 хранят элементарные атрибуты данных как логической, так и физической сети. Таблицы 1845 называются таблицами выходных данных RE, поскольку они хранят выходные данные операций отображения таблиц машины правил 1825. В некоторых примерах осуществления, таблицы выходных данных RE могут быть сгруппированы по нескольким различным категориям. Например, в некоторых примерах осуществления, эти таблицы могут быть таблицами выходных данных RE и/или таблицами выходных данных приложения базового контроллера (ССА). Таблица является таблицей входных данных RE, когда изменение в таблице является причиной того, что механизм правил обнаруживает входное событие, которое требует исполнения плана запроса. Таблица выходных данных RE 1845 может также быть таблицей входных данных RE, которая генерирует событие, являющееся причиной того, что механизм правил выполняет другой план запроса после того, как он был модифицирован механизмом правил. Такое событие именуется как внутреннее входное событие, и оно должно быть противоположностью внешнему входному событию, которое является событием, инициируемым модификацией таблицы входных данных RE, сделанного приложением управления 1805 посредством импортера 1820. Таблица является таблицей выходных данных ССА, когда изменение в таблице является причиной того, что экспортер 1855 переносит изменение на управляемые переключающие элементы или другие экземпляры контроллеров.

Экспортер 1855 обнаруживает изменения в таблицах выходных данных ССА таблиц выходных данных RE 1845. Экспортер различных примеров осуществления обнаруживает возникновение события в таблице выходных данных ССА по-разному. В некоторых примерах осуществления, экспортер регистрирует обратные вызовы с таблиц выходных данных ССА для уведомления изменений в записях таблиц выходных данных ССА. В таких примерах осуществления, экспортер 1855 обнаруживает событие в таблице выходных данных, когда он получает уведомление от таблицы выходных данных ССА о том, что одна из ее записей изменилась.

В ответ на обнаруженное событие в таблице выходных данных экспортер 1855 берет каждый кортеж модифицированных данных в модифицированных таблицах выходных данных и распространяет этот кортеж модифицированных данных на один или более других экземпляров контроллеров (например, физический контроллер) или на управляемый переключающий элемент 1885. Экспортер 1855 использует интерфейс связи между контроллерами (не показан) для пересылки кортежей модифицированных данных на другие экземпляры контроллеров. Интерфейс связи между контроллерами устанавливает каналы связи (например, канал RPC) с другими экземплярами контроллеров.

Экспортер 1855 некоторых примеров осуществления использует интерфейс связи управляемого переключающего элемента 1865 для пересылки кортежей модифицированных данных на управляемый переключающий элемент 1885. Интерфейс связи управляемого переключающего элемента некоторых примеров осуществления устанавливает два канала связи. Интерфейс связи управляемого переключающего элемента устанавливает первый из двух каналов, используя протокол управления переключением. Одним из примеров протокола управления переключением является протокол OpenFlow. Протокол OpenFlow, в некоторых примерах осуществления, является протоколом связи для управления плоскостью продвижения данных (например, таблиц продвижения данных) переключающего элемента. Например, протокол OpenFlow предоставляет команды добавления к потоковым входным сообщениям, удаления из потоковых входных сообщений и модифицирования потоковых входных сообщений в управляемом переключающем элементе 1885.

Интерфейс связи управляемого переключающего элемента устанавливает второй из двух каналов, используя протокол конфигурации, для пересылки конфигурационной информации. В некоторых примерах осуществления, конфигурационная информация содержит информацию конфигурирования управляемого переключающего элемента 1885, такую как информация конфигурирования портов входа, портов выхода, конфигурации QoS портов и проч.

Интерфейс связи управляемого переключающего элемента 1865 получает обновления в управляемом переключающем элементе 1885 от управляемого переключающего элемента 1885 через два канала. Управляемый переключающий элемент 1885 некоторых примеров осуществления пересылает обновления на приложение базового управления, когда существуют изменения потоковых входных сообщений или конфигурации управляемого переключающего элемента 1885, не инициированные приложением базового управления 1800. Примерами таких изменений являются отказ сетевой станции, которая была подсоединена к порту управляемого переключающего элемента 1885, миграция VM к управляемому переключающему элементу 1885 и проч. Интерфейс связи управляемого переключающего элемента 1865 пересыпает обновления на импортер 1820, который будет модифицировать одну или более таблиц входных данных 1810. Если существуют выходные данные, образованные механизмом правил 1825 из этих обновлений, то экспортер 1855 будет пересылать эти выходные данные на физический контроллер 1805.

J. Генерация потоковых входных сообщений

На Фиг. 19 иллюстрируется пример создания туннеля между управляемыми коммутаторами, базируясь на данных UPCP. В частности, этот рисунок иллюстрирует в четырех различных этапах 1901-1904 последовательности операций, выполняемых различными компонентами сетевой системы управления 1900 для установления туннеля между двумя управляемыми переключающими элементами 1925 и 1930. На этом рисунке показывается также логический переключающий элемент 1905 и VM 1 и VM 2. Каждый из этих четырех этапов 1901-1904 показывает сетевую систему управления 1900 и управляемые переключающие элементы 1925 и 1930 - в нижней части и логический переключающий элемент 1905 и два VM, подсоединенные к логическому переключающему элементу 1905, - в верхней части. VM показаны как в верхней, так и в нижней части каждого этапа.

Как показывается на первом этапе 1901, логический переключающий элемент 1905 продвигает данные между VM 1 и VM 2. В частности, данные следуют к VM 1 или от VM 1 через логический порт 1 логического переключающего элемента 1905, и данные следуют к VM 2 или от VM 2 через логический порт 2 логического переключающего элемента 1905. В этом примере логический переключающий элемент 1905 реализуется управляемым переключающим элементом 1925. То есть, логический порт 1 отображается на порт 3 управляемого переключающего элемента 1925, а логический порт 2 отображается на порт 4 управляемого переключающего элемента 1925.

Сетевая система управления 1900 в этом примере содержит кластер контролеров 1910 и два базовых контроллера 1915 и 1920. Кластер контроллеров 1910 содержит контроллеры трансляции входных данных (не показаны), логические контроллеры (не показаны) и физические контроллеры (не показаны), которые совместно генерируют данные UPCP, базируясь на входных данных, которые получает кластер контроллеров 1910. Базовые контроллеры получают данные UPCP и настраивают универсальные данные в данные РСР, которые специфичны для управляемого переключающего элемента, управляемого каждым базовым контролером. Базовые контроллеры 1915 и 1920 передают данные СРСР на управляемые переключающие элементы 1925 и 1930, соответственно, так что управляемые переключающие элементы 1925 и 1930 могут генерировать данные физической плоскости продвижения данных, которые управляемые переключающие элементы используют для продвижения данных между управляемыми переключающими элементами 1925 и 1930.

На втором этапе 1902 администратор сети, которая содержит управляемый переключающий элемент 1930, создает VM 3 в хосте (не показан), в котором исполняется управляемый переключающий элемент 1930. Администратор создает порт 5 управляемого переключающего элемента 1930 и присоединяет VM 3 к этому порту. После создания порта 3 управляемый переключающий элемент 1930 некоторых примеров осуществления посылает информацию о вновь созданном порте кластеру контроллеров 1910. В некоторых примерах осуществления, эта информация может содержать номер порта, сетевые адреса (например, адреса IP и MAC), транспортную зону, к которой принадлежит управляемый переключающий элемент, сетевую станцию, присоединенную к порту и проч. Как было упомянуто выше, эта конфигурационная информация проходит через базовый контроллер, управляющий управляемым переключающим элементом, а затем -через физические контролеры и логические контролеры на всем пути до пользователя, который управляет логическим переключающим элементом 1905. Этому пользователю предоставляется возможность добавления нового VM к логическому переключающему элементу 1905, которым управляет пользователь.

На этапе 1903 пользователь в этом примере решает использовать VM 3 и присоединяет VM 3 к логическому переключающему элементу 1905. В результате этого создается логический порт 6 логического переключающего элемента 1905. Поэтому данные, приходящие к VM 3 или от VM 3, будут идти через логический порт 6. В некоторых примерах осуществления, кластер контролеров 1910 дает команду всем управляемым переключающим элементам, которые реализуют логические переключающие элементы, на образование туннеля между каждой парой управляемых переключающих элементов, имеющих пару портов, на которую отображена пара логических портов логического переключающего элемента. В этом примере туннель может быть установлен между управляемыми переключающими элементами 1925 и 1930 для поддержки обмена данными между логическим портом 1 и логическим портом 6 (то есть, между VM 1 и VM 3) и между логическим портом 2 и логическим портом 6 (то есть, между VM 2 и VM 3). Иными словами, данные, которыми обмениваются между собой порт 3 управляемого переключающего элемента 1925 и порт 5 управляемого переключающего элемента 1930, а также данные, которыми обмениваются между собой порт 4 управляемого переключающего элемента 1925 и порт 5 управляемого переключающего элемента 1930, могут проходить через туннель, установленный между управляемыми переключающими элементами 1925 и 1930.

Туннель между двумя управляемыми переключающими элементами не является необходимым для поддержки обмена данными между логическим портом 1 и логическим портом 2 (то есть, между VM 1 и VM 2), поскольку логический порт 1 и логический порт 2 отображаются на два порта одного и того же управляемого переключающего элемента 1925.

Третий этап 1903 далее показывает, что кластер контроллеров 1910 пересылает данные UPCP, специфицирующие команды создания туннеля от управляемого переключающего элемента 1925 к управляемому переключающему элементу 1930. В этом примере данные UPCP пересылаются к базовому контроллеру 1915, который будет настраивать данные UPCP на данные РСР, специфичные для управляемого переключающего элемента 1925.

Четвертый этап 1904 показывает, что базовый контроллер 1915 пересылает туннельные данные РСР, которые специфицируют команды создания туннеля и продвижения пакетов данных к туннелю. Управляемый переключающий элемент 1925 создает туннель к управляемому переключающему элементу 1930, базируясь на данных СРСР. Более конкретно, управляемый переключающий элемент 1925 создает порт 7 и устанавливает туннель (например, туннель GRE) к порту 8 управляемого переключающего элемента 1930. Более детальные операции по созданию туннеля между двумя управляемыми переключающими элементами будут описаны ниже.

На Фиг. 20 концептуально иллюстрируется процесс 2000, который выполняется в некоторых примерах осуществления для генерации из данных UPCP данных СРСР, которые специфицируют образование и использование туннеля между двумя управляемыми переключающими элементами. В некоторых примерах осуществления, процесс 2000 выполняется базовым контролером, который связывается с управляемым переключающим элементом или физическим контролером, который непосредственно связывается с управляемым переключающим элементом.

Процесс 2000 начинается с получения данных UPCP от логического контроллера или физического контроллера. В некоторых примерах осуществления, данные UPCP имеют различные типы. Один из типов данных UPCP является универсальными командами туннельного потока, которые определяют образование туннеля в управляемом переключающем элементе и использование этого туннеля. В некоторых примерах осуществления, универсальные команды туннельного потока содержат информацию о порте, создаваемом в управляемом переключающего элементе в сети. Этот порт является портом управляемого переключающего элемента, на который пользователь отображает логический порт логического переключающего элемента. Этот порт является также портом назначения, которого необходимо достигнуть туннелируемым данным. Информация о порте содержит (1) транспортную зону, к которой принадлежит управляемый переключающий элемент, имеющий этот порт, (2) тип туннеля, который, в некоторых примерах осуществления, базируется на туннельных протоколах (например, GRE, CAPWAR и проч.), используемых для построения туннеля к управляемому переключающему элементу, который имеет порт назначения, и (3) сетевой адрес (например, IP адрес) управляемого переключающего элемента, который имеет порт назначения (например, IP адрес VIF, который будет функцией, как только будет установлен один конец туннеля).

Затем, процесс 2000 определяет (в 2010) являются ли полученные данные UPCP универсальной командой туннельного потока. В некоторых примерах осуществления, данные UPCP специфицируют ее тип, так что процесс 2000 может определить тип полученных данных универсальной плоскости. Если процесс 2000 определяет (в 2010), что полученные универсальные данные не являются универсальной командой туннельного потока, то процесс переходит к 2015 для обработки данных UPCP для генерации данных СРСР и пересылки этих сгенерированных данных на управляемый переключающий элемент, который управляется процессом 2000. Затем процесс 2000 заканчивается.

Если процесс 2000 определяет (в 2010), что полученные данные UPCP являются универсальными командами туннельного потока, то процесс 2000 переходит к 2020 для синтаксического анализа данных и получения информации о порте назначения. Затем процесс 2000 определяет (в 2025) находится ли управляемый переключающий элемент, который имеет порт назначения, в той же самой транспортной зоне, в которой находится управляемый переключающий элемент, имеющий исходный порт. Управляемый переключающий элемент, который имеет исходный порт, является управляемым переключающим элементом, которым управляет базовый контроллер или физический контроллер, исполняющий процесс 2000. В некоторых примерах осуществления, транспортная зона содержит группу сетевых станций, которые могут сообщаться друг с другом без использования управляемого переключающего элемента второго уровня, такого как групповой узел.

В некоторых примерах осуществления, логический контроллер определяет, находится ли управляемый переключающий элемент, который имеет порт назначения, в той же самой транспортной зоне, в которой находится управляемый переключающий элемент, имеющий исходный порт. Логический контроллер принимает во внимание это определение при подготовке универсальных команд туннельного потока, для пересылки (через физический контроллер) на базовый контроллер, выполняющий процесс 2000. В частности, универсальные команды туннельного потока будут содержать различающуюся информацию для создания различающихся туннелей. Примеры этих различающихся туннелей описываются ниже после описания Фиг. 21. В этих примерах осуществления, процесс 2000 пропускает 2025 и переходит к 2015.

Если процесс 2000 определяет (в 2025), что управляемый переключающий элемент с исходным портом и управляемый переключающий элемент с портом назначения не находятся в одинаковой транспортной зоне, то процесс 2000 переходит к 2015, который описывается выше. В ином случае, процесс переходит к 2030 для настройки универсальных команд туннельного потока и пересылки настроенной информации на управляемый переключающий элемент, который имеет исходный порт. Настройка универсальных команд туннельного потока будет подробно описана далее. Затем процесс 2000 заканчивается.

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

Процесс 2100 начинается с генерации (в 2105) команд создания порта туннеля. В некоторых примерах осуществления, процесс 2100 генерирует команды создания порта туннеля в управляемом переключающем элементе, которым управляет контролер, базируясь на информации о порте. Эти команды содержат, например, тип туннеля, который устанавливается, и IP адрес NIC, который будет назначенным концом туннеля. Порт туннеля управляемого переключающего элемента, управляемого контроллером, будет другим концом туннеля.

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

Процесс 2100 некоторых примеров осуществления, получает затем (в 2115) значение идентификатора порта туннеля (например, "tunnel_port=4") через канал конфигурации. Затем процесс 2100 модифицирует потоковое входное сообщение, которое содержится в универсальных командах туннельного потока, используя полученное значение. Это потоковое входное сообщение при его пересылке на управляемый переключающий элемент является причиной того, что управляемый переключающий элемент выполняет действие. Однако, будучи универсальными данными, это потоковое входное сообщение идентифицирует порт туннеля универсальным идентификатором (например, tunnel_port), a не действительным номером порта. Например, этот потоковое входное сообщение в полученных универсальных командах туннельного потока может быть "if destination=destination machine′s UUID, send to tunnel_port". Процесс 2100 создает (в 2120) потоковое входное сообщение со значением идентификатора порта туннеля. В частности, процесс 2100 заменяет идентификатор порта туннеля на действительное значение идентификатора, который идентифицирует созданный порт. Например, модифицированное потоковое входное сообщение могло бы выглядеть как "if destination=destination machine′s UUID, send to 4".

Затем процесс 2100 пересылает (в 2125) этот потоковое входное сообщение на управляемый переключающий элемент. В некоторых примерах осуществления, процесс пересылает это потоковое входное сообщение на управляемый переключающий элемент через канал управления переключающего элемента (например, канал OpenFlow). Управляемый переключающий элемент будет обновлять свою таблицу потоковых входных сообщений, используя это потоковое входное сообщение. После этого управляемый переключающий элемент продвигает озаглавленные данные на назначенную сетевую станцию через туннель пересылкой данных на порт туннеля. Затем процесс заканчивается.

На Фиг. 22 концептуально иллюстрируется в семи различных этапах 2201-2207 пример работы базового контроллера 2210, который транслирует универсальные команды туннельного потока в заказные команды для управляемого переключающего элемента 2215, который их получает и использует. Базовый контроллер 2210 аналогичен базовому контроллеру 1800, описанному выше со ссылками на Фиг. 18. Однако для простоты обсуждения, на Фиг. 22 показаны не все компоненты базового контроллера 2210.

Как видно, базовый контроллер 2210 содержит таблицы входных данных 2220, механизм правил 2225 и таблицы выходных данных 2230, которые аналогичны таблицам входных данных 1820, механизму правил 1825 и таблицам выходных данных 1845. Базовый контроллер 2210 управляет управляемым переключающим элементом 2215. В некоторых примерах осуществления, между базовым контроллером 2210 и управляемым переключающим элементом 2215 устанавливаются два канала 2235 и 2240. Канал 2235 предназначен для обмена конфигурационными данными (например, данными о созданных портах, текущем статусе портов, очередях, связанных с управляемым переключающим элементом и проч.). Канал 2240 является каналом OpenFlow (канал управления OpenFlow), через который, в некоторых примерах осуществления, происходит обмен потоковыми входными сообщениями.

На первом этапе 2201 показывается, что базовый контроллер 2210 обновляет таблицы входных данных 2220, используя универсальные команды туннельного потока, полученные от физического контроллера (не показан). Как показано, универсальные команды туннельного потока содержат команду 2245 для создания туннеля и потокового входного сообщения 2250. Как видно, команда 2245 содержит тип создаваемого туннеля и IP адреса управляемого переключающего элемента, который имеет порт назначения. Потоковое входное сообщение 2250 специфицирует исполняемое действие в терминах универсальных данных, которые не являются специфичными для управляемого переключающего элемента 2215. Механизм правил выполняет операции отображения таблиц на команду 2245 и потоковое входное сообщение 2250.

На втором этапе 2202 показывается результат операций отображения таблиц, выполняемых механизмом правил 2225. Команда 2260 является результатом команды 2245. В некоторых примерах осуществления, команды 2245 и 2260 могут быть идентичными, хотя в других примерах осуществления они могут быть не идентичными. Например, могут быть различными значения в командах 2245 и 2260, которые представляют тип туннеля. Команда 2260 среди другой информации, которая может быть включена в в команду 2260, содержит IP адрес и тип туннеля, который должен быть создан. Потоковое входное сообщение 2250 не запускает какую либо операцию отображения таблиц и тем самым остается в таблицах входных данных 2220.

На третьем этапе 2203 показывается, что команда 2260 была передана на управляемый переключающий элемент 2215 через канал конфигурации 2235. Управляемый переключающий элемент 2215 создает порт туннеля и устанавливает туннель между управляемым переключающим элементом 2215 и другим управляемым переключающим элементом, который имеет порт назначения. В некоторых примерах осуществления, один конец этого туннеля является созданным портом туннеля, а другой конец туннеля является портом, который связан с IP адресом места назначения. Управляемый переключающий элемент 2215 некоторых примеров осуществления для установления туннеля использует протокол, специфицированный типом туннеля.

На четвертом этапе 2204 показывается, что управляемый переключающий элемент 2215 создает порт туннеля ("port 1" в этом примере) и туннель 2270. На этом этапе также показывается, что управляемый переключающий элемент возвращает действительную величину идентификатора порта туннеля. В этом примере управляемый переключающий элемент 2215 пересылает эту информацию через канал OpenFlow 2240. Информация поступает в таблицы входных данных 2220 в качестве входных данных события. На пятом этапе 2205 показывается, что таблицы входных данных 2220 обновляются информацией от управляемого переключающего элемента 2215. Это обновление запускает механизм правил 2225 для выполнения операций отображения таблиц.

На шестом этапе 2206 показывается результат операций отображения таблиц, исполненных на предыдущем этапе 2204. Таблицы выходных данных 2230 имеют теперь потоковое входное сообщение 2275, которое специфицирует действие для получения его в терминах информации, которая определена для управляемого переключающего элемента 2215. В частности, потоковое входное сообщение 2275 определяет, что когда назначением пакета является порт назначения, управляемому переключающему элементу 2215 следует послать пакет через порт 1. На седьмом этапе 2207 показывается, что потоковое входное сообщение 2275 было передано на управляемый переключающий элемент 2215, который будет продвигать пакеты, используя потоковое входное сообщение 2275.

Следует заметить, что команда 2245 и данные, которыми обмениваются между собой базовый контроллер 2210 и управляемый переключающий элемент 2215, как показывается на Фиг. 22, являются концептуальным представлением универсальных команд туннельного потока и заказных команд и могут не быть представлены в действительных форматах и выражениях.

Более того, пример на Фиг. 22 описывается в терминах работы базового контроллера 2210. Этот пример применим также к физическому контроллеру некоторых примеров осуществления, который транслирует данные UPCP в данные СРСР для управляемых переключающих элементов, задающим контроллером которых является этот физический контроллер.

На Фиг. 19 - Фиг. 22 иллюстрируется образование туннеля между двумя концевыми переключающими элементами для поддержки обмена данными между парой сетевых станций (например, несколькими VM), которые используют два логических порта логического переключающего элемента. Этот туннель представляет одно из возможных использований туннеля. В некоторых примерах осуществления изобретения в сетевой системе управления возможно много других использований туннеля. Примерами использования туннеля являются: (1) туннель между концевым управляемым переключающим элементом и групповым узлом, (2) туннель между двумя управляемыми переключающими элементами, где один из них является концевым переключающим элементом, а другой обеспечивает сервис межсетевого шлюза L3 (то есть, управляемый переключающий элемент, который подсоединяется к маршрутизатору для получения маршрутного сервиса на сетевом слое (L3)), и (3) туннель между двумя управляемыми переключающими элементами, в которых один логический порт и другой логический порт присоединены к сервису межсетевого шлюза L2.

Теперь будет описана последовательность событий создания туннеля в каждом из трех примеров. Для случая туннеля между управляемым переключающим элементом и групповым узлом сначала создается групповой узел, а затем - управляемый переключающий элемент. К порту управляемого переключающего элемента подсоединяется VM. Этот VM является первым VM, который подсоединяется к управляемому переключающему элементу. Затем этот VM связывается с логическим портом логического переключающего элемента отображением логического порта на порт управляемого переключающего элемента. Как только отображение логического порта на порт управляемого переключающего элемента проведено, логический контроллер пересылает (например, через физический контроллер (контроллеры)) универсальные команды туннельного потока на базовый контроллер (или на физический контроллер), который подсоединяет управляемый переключающий элемент.

Затем базовый контроллер выдает команду управляемому переключающему элементу на образование туннеля к групповому узлу. Как только этот туннель будет создан, другой VM, который вслед за этим образуется и подсоединяется к управляемому переключающему элементу, будет совместно использовать один и тот же туннель для обмена данными с групповым узлом, если этот новый VM связан с логическим портом того же самого логического переключающего элемента. Если новый узел связывается с логическим портом другого логического переключателя, то логический контроллер будет пересылать те же самые универсальные команды туннельного потока, которые были переданы, когда первый VM был подсоединен к управляемому переключающему элементу. Однако универсальные команды туннельного потока не будут приводить к образованию нового туннеля к групповому узлу, поскольку, например, туннель уже был создан и находится в рабочем состоянии.

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

Для туннеля между концевым управляемым переключающим элементом и управляемым переключающим элементом, предоставляющим сервис межсетевого шлюза L3, принимается, что был предоставлен логический переключающий элемент с несколькими VM пользователя, а в транспортном узле, который предоставляет сервис межсетевого шлюза L3, реализуется логический маршрутизатор. Для подсоединения логического маршрутизатора к логическому переключающему элементу в логическом переключающем элементе создается фрагментарный логический порт. В некоторых примерах осуществления, порядок, в котором проводится образование логического фрагмента и предоставление нескольких VM, не создает различия в образовании туннеля. Образование фрагментарного логического порта является причиной того, что логический переключающий элемент посылает универсальные команды туннельного потока на базовые контроллеры (или физические контролеры), соединяя все управляемые переключающие элементы, которые реализуют логический переключающий элемент (то есть, все управляемые переключающие элементы, каждый из которых имеет, по меньшей мере, один порт, на который отображается логический порт логического переключающего элемента). Каждый базовый контролер каждого из этих управляемых переключающих элементов выдает команду управляемому переключающему элементу на образование туннеля к транспортному узлу. Каждый из управляемых переключающих элементов образует туннель к транспортному узлу, что дает в результате столько же туннелей, что и число управляемых переключающих элементов, которые реализуют логический переключающий элемент.

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

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

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

III. ЭЛЕКТРОННАЯ СИСТЕМА

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

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

На Фиг. 23 концептуально иллюстрируется электронная система 2300, которой реализуются некоторые примеры осуществления изобретения. Электронная система 2300 может быть использована для исполнения любого приложения управления, виртуализации или операционной системы, описанных выше. Электронная система 2300 может быть компьютером (например, персональным компьютером, планшетным компьютером, серверным компьютером, универсальным компьютером, компьютером клиент-терминала и проч.), телефоном, электронным секретарем или любым другим типом электронного устройства. Такая электронная система содержит различные типы носителей, считываемых компьютером, и интерфейсов для различных других типов носителей, считываемых компьютером. Электронная система 2300 содержит шину 2305, процессор(ы) 2310, системную память 2325, постоянное запоминающее устройство 2330, энергонезависимое запоминающее устройство 2335, устройства вода 2340 и устройства вывода 2345.

Шина 2305 совместно представляет всю систему, периферию и шины наборов микросхем, соединяя между собой разнообразные внутренние устройства электронной системы 2300. Например, шина 2305 соединяет процессор(ы) 2310 с постоянным запоминающим устройством 2330, системной памятью 2325 и энергонезависимым запоминающим устройством 2335.

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

Постоянное запоминающее устройство (ПЗУ) 2330 хранит постоянные данные и команды, которые необходимы для процессора 2310 и для других модулей электронной системы. Энергонезависимое запоминающее устройство 2335, с другой стороны, является запоминающим устройством чтения и записи. Это устройство не зависит от источника питания и сохраняет команды и данные, даже когда электронная система 2300 отключается от питания. Некоторые примеры осуществления изобретения в качестве энергонезависимого запоминающего устройства 2335 используют запоминающие устройства большой емкости (такие как магнитный или оптический диск и их соответствующие дисководы).

Другие примеры осуществления в качестве энергонезависимого запоминающего устройства используют сменные запоминающие устройства (такие как флоппи-диск, флэш-память и пр.). Подобно энергонезависимому запоминающему устройству 2335, системная память 2325 является запоминающим устройством чтения и записи. Однако в отличие от запоминающего устройства 2335, системная память является энергозависимым запоминающим устройством чтения и записи, таким как запоминающее устройство с произвольной выборкой. В системной памяти хранятся некоторые из команд и данных, которые необходимы процессору во время исполнения. В некоторых примерах осуществления, процессы изобретения хранятся в системной памяти 2325, энергонезависимом запоминающем устройстве 2335 и/или постоянном запоминающем устройстве 2330. Из этих различных блоков запоминающих устройств процессор 2310 выбирает команды для исполнения и данные для обработки, с тем, чтобы исполнять процессы некоторых примеров осуществления.

Шина 2305 подсоединена также к устройствам ввода и вывода 2340 и 2345. Устройства ввода предоставляют пользователю возможность передавать информацию и выбирать команды на электронную систему. Устройства вода 2340 содержат алфавитно-цифровые клавиатуры и позиционирующие устройства (называемые также "устройства управления курсором"). Устройства вывода 2345 воспроизводят изображения, сгенерированные электронной системой. Устройства вывода содержат принтеры и дисплеи, какие как дисплеи на ЭЛТ или дисплеи на жидких кристаллах. Некоторые примеры осуществления содержат такое устройство, как сенсорная панель, которая функционирует как устройство ввода, так и устройство вывода.

Наконец, как показывается на Фиг. 23, шина 2305 подсоединяет также электронную систему 2300 к сети 2365 через сетевой адаптер (не показан). Подобным образом, компьютер может быть частью сети компьютеров (такой как локальная сеть ("LAN"), глобальной сети ("WAN") или внутрикорпоративной сети, или сетью сетей, такой как Интернет. В связи с этим изобретением могут быть использованы любые или все компоненты электронной системы 2300.

Некоторые примеры осуществления содержат электронные компоненты, такие как микропроцессоры, память и запоминающие устройства, которые хранят команды компьютерных программ в носителе, считываемом сетевой станцией или считываемом компьютером (альтернативно именуется как носитель записи, считываемый компьютером, носитель, считываемый сетевой станцией, или носитель записи, считываемый сетевой станцией). Некоторыми примерами таких считываемых компьютером носителей являются ЗУПВ, ПЗУ, компакт-диски только чтение (CD-ROM), перезаписываемые компакт-диски (CD-R), многократно перезаписываемые компакт-диски (CD-RW), цифровые видеодиски только чтение (например, DVD-ROM, двухслойные DVD-ROM), различные записываемые/перезаписываемые DVD (например, DVD-RAM, DVD-RW, DVD+RW и пр.), флэш-память (например, карты SD, карты мини-SD, карты микро-SD и пр.), магнитные и/или твердотельные накопители на жестких дисках, постоянные и перезаписываемые диски Blu-Ray^®, оптические диски ультравысокой плотности и любые другие оптические или магнитные носители, и флоппи-диски. Носитель, считываемый компьютером, может хранить компьютерную программу, которая исполняется, по меньшей мере, одним обрабатывающим блоком и содержит набор команд для выполнения различных операций. Примерами компьютерных программ, или компьютерных кодов, являются машинный код, такой как код, создаваемый компилятором, и файлы, содержащие код высокого уровня, который исполняется компьютером, электронным компонентом или микропроцессором, используя интерпретатор.

Хотя проведенное обсуждение относится к микропроцессору или многоядерным процессорам, которые исполняют программное обеспечение, некоторые примеры осуществления реализуются одной или более интегральными схемами, какими как проблемно-ориентированные интегральные схемы (ASIC) или программируемые логические матрицы (FPGA). В некоторых примерах осуществления такие интегральные схемы исполняют команды, которые хранятся на самих схемах.

Как использовано в этом описании, все термины "компьютер", "сервер", "процессор" и "запоминающее устройство" относятся к электронным устройствам или устройствам с другой технологией. Эти термины исключают людей или группы людей. С целью описания термины дисплей или воспроизведение означают воспроизведение на электронном устройстве. Как использовано в этом описании, термины "среда, считываемая компьютером", "носитель, считываемый компьютером" или "носитель, считываемый сетевой станцией" полностью ограничены материальными, физическими объектами, которые хранят информацию в форме, допускающей считывание компьютером. Эти термины исключают любые беспроводные сигналы, сигналы, подаваемые по проводам, и любые другие эфемерные сигналы.

Хотя изобретение было описано со ссылками на многочисленные специфические детали, любой рядовой специалист в этой области техники понимает, что это изобретение может быть осуществлено в других определенных формах, без отклонения от объема изобретения. Кроме того, несколько рисунков (включая Фиг. 20 и Фиг. 21) иллюстрируют процессы концептуально. Определенные операции этих процессов могут не выполняться в точном описанном и показанном на них порядке. Эти определенные операции могут не выполняться в одних непрерывных последовательностях операций, а различные определенные операции могут быть исполнены в различных примерах осуществления. Кроме того, процесс может быть реализован с использованием нескольких подпроцессов или как часть большого макропроцесса.

Также выше было описано несколько примеров осуществления, в которых пользователь предоставляет совокупности LDP в терминах данных LCP. Однако в других примерах осуществления пользователь может предоставлять совокупности LDP в терминах данных LFP. Кроме того, выше было описано несколько примеров осуществления, в которых экземпляр контролера предоставляет данные РСР на переключающий элемент для управления этим переключающим элементом. Однако в других примерах осуществления экземпляр контролера может предоставлять переключающему элементу данные физической плоскости продвижения данных. В таких примерах осуществления, структура данных реляционной базы данных будет хранить данные физической плоскости продвижения данных, а приложение виртуализации будет генерировать такие данные.

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

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

1. Сетевая система управления для генерации данных плоскости физического управления для управления совокупностью управляемых элементов продвижения данных, которая реализует операции продвижения данных, связанные с совокупностью логических информационных каналов, где система содержит:
первый экземпляр контроллера для (i) получения входных данных, определяющих совокупность логических информационных каналов и выполнения первого преобразования данных совокупности логических информационных каналов для генерации кортежей промежуточных данных совокупности логических информационных каналов, и (ii) распределения кортежей промежуточных данных на совокупность хостов, на которых работает совокупность управляемых элементов продвижения данных; и
второй экземпляр контроллера, работающий на определенном одном из хостов для (i) получения кортежей промежуточных данных совокупности логических информационных каналов и (ii) преобразования кортежей промежуточных данных в данные плоскости физического управления для использования управляемым элементом продвижения данных, работающим на определенном хосте, при этом второй экземпляр контроллера содержит механизм отображения таблиц для отображения кортежей промежуточных данных в данные плоскости физического управления.

2. Сетевая система управления по п. 1, отличающаяся тем, что определенный хост является первым хостом, а управляемый элемент продвижения данных является первым управляемым элементом продвижения данных, при этом сетевая система управления также содержит третий экземпляр контроллера, работающего на втором одном из хостов, для (i) получения кортежей промежуточных данных совокупности логических информационных каналов и (ii) преобразования кортежей промежуточных данных в данные физической плоскости управления для использования вторым управляемым элементом продвижения данных, работающим на втором хосте.

3. Сетевая система управления по п. 2, отличающаяся тем, что данные плоскости физического управления для использования первым управляемым элементом продвижения данных, работающим на первом хосте, содержат данные, отличные от данных плоскости физического управления для использования вторым управляемым элементом продвижения данных, работающим на втором хосте.

4. Сетевая система управления по п. 2, отличающая тем, что дополнительно содержит:
четвертый экземпляр контроллера для получения кортежей промежуточных данных от первого экземпляра контроллера и распределения кортежей промежуточных данных на второй экземпляр контроллера; и
пятый экземпляр контроллера для получения кортежей промежуточных данных от первого экземпляра контроллера и распределения кортежей промежуточных данных на третий экземпляр контроллера.

5. Сетевая система управления по п. 4, отличающаяся тем, что первый экземпляр контроллера является экземпляром задающего контроллера для совокупности логических информационных каналов, четвертый экземпляр контроллера является экземпляром задающего контроллера для первого управляемого элемента продвижения данных, а пятый экземпляр контроллера является экземпляром задающего контроллера для второго управляемого элемента продвижения данных.

6. Сетевая система управления по п. 5, отличающаяся тем, что дополнительно содержит администратор координации для идентификации различных экземпляров контроллеров в качестве задающих контроллеров различных совокупностей логических информационных каналов и различных управляемых элементов продвижения данных.

7. Сетевая система управления по п. 1, отличающаяся тем, что входные данные являются данными логической плоскости управления, кортежи промежуточных данных являются данными универсальной плоскости физического управления (UPCP), а данные плоскости физического управления для использования управляемым элементом продвижения данных являются данными заказной плоскости физического управления (СРСР).

8. Сетевая система управления по п. 7, отличающаяся тем, что данные UPCP содержат кортежи данных, записанных в терминах общих выражений атрибута каждой из совокупности управляемых элементов продвижения данных, а данные СРСР содержат заказное выражение атрибута, специфичного для определенного управляемого элемента продвижения данных.

9. Сетевая система управления по п. 1, отличающаяся тем, что несколько управляемых элементов продвижения данных являются программными виртуальными переключателями.

10. Сетевая система управления по п. 1, отличающаяся тем, что кортежи промежуточных данных являются первой совокупностью кортежей промежуточных данных, при этом первый экземпляр контроллера содержит:
приложение управления для преобразования входных данных во вторую совокупность кортежей промежуточных данных для совокупности логических информационных каналов; и
приложение виртуализации для преобразования второй совокупности кортежей промежуточных данных в первую совокупность кортежей промежуточных данных.

11. Сетевая система управления по п. 10, отличающаяся тем, что входные данные содержат данные логической плоскости управления, вторая совокупность кортежей промежуточных данных содержит данные логической плоскости продвижения данных, первая совокупность кортежей промежуточных данных содержит данные универсальной плоскости физического управления, а данные плоскости физического управления для использования управляемым элементом продвижения данных содержат данные заказной плоскости физического управления.

12. Сетевая система управления по п. 1, отличающаяся тем, что кортежи промежуточных данных определяют общие поведения продвижения совокупности управляемых элементов продвижения данных для реализации совокупности логических элементов продвижения данных для совокупности логических информационных каналов, отличающаяся тем, что совокупность логических элементов продвижения данных логически связывает между собой несколько сетевых станций.

13. Сетевая система управления по п. 1, отличающаяся тем, что второй экземпляр контроллера также содержит интерфейс связи с управляемым элементом продвижения данных для распределения данных плоскости физического управления на управляемый элемент продвижения данных внутри хоста.

14. Сетевая система управления по п. 13, отличающаяся тем, что имеется также интерфейс для получения данных, специфичных для управляемого элемента продвижения данных, от управляемого элемента продвижения данных для генерации данных плоскости физического управления.

15. Сетевая система управления по п. 14, отличающаяся тем, что данные, специфичные для управляемого элемента продвижения данных, содержат номер физического порта.

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

17. Первый экземпляр контроллера по п. 16, отличающийся тем, что второй и третий экземпляры контроллеров являются теми же самыми.

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

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

20. Первый экземпляр контроллера по п. 16, отличающийся тем, что имеется также интерфейс управляемого элемента продвижения данных для получения данных, специфичных для управляемого элемента продвижения данных, от управляемого элемента продвижения данных внутри главной сетевой станции для генерации данных плоскости физического управления.