Приводимое в действие контроллером оам для openflow

Приводимое в действие контроллером оам для openflow

Иллюстрации

Показать все

Реферат

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННУЮ ЗАЯВКУ

Настоящая заявка испрашивает приоритет по предварительной заявке 61/505,617 на выдачу патента США, озаглавленной «ПРИВОДИМОЕ В ДЕЙСТВИЕ КОНТРОЛЛЕРОМ OAM ДЛЯ OPENFLOW» («CONTROLLER DRIVEN OAM FOR OPENFLOW»), поданной 08 июля 2011 года.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

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

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

Фиг. 3A - схема первого варианта осуществления коммутационного модуля OpenFlow.

Фиг. 3B - схема второго варианта осуществления коммутационного модуля OpenFlow.

Фиг. 4 − схема структуры сопоставления Openflow.

Фиг. 5 - схема одного из вариантов осуществления формата сообщения OpenFlow из контроллера в коммутатор.

Фиг. 6 - схема одного из вариантов осуществления формата действия внедрения.

Фиг. 7A - блок-схема последовательности операций одного из вариантов осуществления процесса для вставки пакета OAM OpenFlow коммутационным модулем OpenFlow.

Фиг. 7B - блок-схема последовательности операций одного из вариантов осуществления процесса для подготовки пакета OAM OpenFlow виртуальным портом элемента сети.

Фиг. 8 - блок-схема последовательности операций одного из вариантов осуществления процесса для демультиплексирования.

Фиг. 9 - схема одного из вариантов осуществления сети OpenFlow, поддерживающей OAM.

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

Фиг. 11 - блок-схема последовательности операций одного из вариантов осуществления процесса для обработки запроса функции OAM.

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

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

Фиг. 14 - блок-схема последовательности операций одного из варианта осуществления процесса для поддержки OAM в коммутаторе OpenFlow.

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

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

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

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

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

Варианты осуществления изобретения предусматривают способ и систему для устранения недостатков предшествующего уровня техники. Большинство технологий плоскости данных, таких как Ethernet или многопротокольная коммутация по меткам (MPLS), используемых в комбинации с OpenFlow, определили решения OAM, которые характерны для этих технологий. Решения OAM, определенные этими технологиями плоскости данных, предусматривают механизм для идентификации, внедрения и демультиплексирования пакетов OAM в/из потока данных. К тому же, эти решения OAM обеспечивают правильное предварительно определенное совместное использование для пакетов OAM, где пакеты OAM пересылаются таким же образом, что и служебные пакеты пересылаются через сеть. Однако, OpenFlow не предусматривает поддержку ни для какого механизма, который дает возможность идентификации, внедрения или демультиплексирования пакетов OAM. Это делает реализацию любого решения OAM в домене OpenFlow невозможной. Реализация предварительно определенного совместного использования для технологии OAM, которая должна использоваться в OpenFlow, требует специального соображения об идентификации пакетов OAM, которая не поддерживается техническими условиями OpenFlow 1.1.

Кроме того, OpenFlow 1.1 не определяет никаких средств для конфигурирования коммутатора OpenFlow для выполнения функций OAM. Нет установленных сообщений управления для отправки конфигурационной информации в коммутаторы OpenFlow или каких бы то ни было сообщений управления для ввода в действие имеющих отношение к OAM функциональных возможностей в коммутаторах OpenFlow. Подобным образом, нет сообщений управления для приема имеющих отношение к OAM данных из коммутаторов OpenFlow. Отсутствие какой бы то ни было поддержки OAM в OpenFlow требует элементов сети, реализующих коммутаторы OpenFlow для полной реализации функциональных возможностей OAM других технологий плоскости данных, таких как Ethernet и MPLS, что повышает стоимость элемента сети.

Варианты осуществления изобретения преодолевают эти недостатки предшествующего уровня техники. Варианты осуществления изобретения. Варианты осуществления изобретения предусматривают процесс и системы для предоставления пакетам OAM (то есть, размеченным кадрам) возможности вставляться в поток данных OpenFlow и демультиплексироваться из потока данных OpenFlow. Процесс и система поддерживают предварительно определенное совместное использование для пакетов OAM OpenFlow, которое обеспечивает, чтобы пакеты OAM OpenFlow двигались по тому же самому маршруту через сеть между источником и пунктом назначения потока данных, что и другие пакеты данных потока данных (то есть, информационного потока). Чтобы проводить различие пакетов OAM OpenFlow (то есть, размеченных кадров) от других пакетов данных OpenFlow, поле сопоставления, которое не принимается во внимание во время сопоставления для обработки пакетов данных OpenFlow, используется для идентификации пакетов OAM. Нераспределенное значение области выбранного поля используется для идентификации пакетов OAM (размеченных кадров). Для вставки пакетов OAM (размеченных кадров) в любой каскад конвейера обработки пакетов, новый логический модуль добавлен в коммутационный модуль OpenFlow. Новый логический модуль в материалах настоящей заявки обозначается как ‘логика внедрения пакетов’ (‘Packet Inject Logic’, PIL). Два примерных варианта реализации описаны в материалах настоящей заявки. В первой примерной реализации, PIL выполнена с возможностью справляться с внедрением пакетов OAM (размеченных кадров) на попакетной основе; во второй примерной реализации, PIL принимает инструкции, управляющие внедрением пакета OAM (размеченного кадра), из других коммутационных модулей элемента сети благодаря метаданным, прикрепленным к пакету OAM. В других примерных вариантах осуществления, процесс демультиплексирования проводит различие между пакетами данных OpenFlow и пакетами OAM OpenFlow (размеченными пакетами) с использованием внутреннего коммутатора и/или варианта оконечной части контроллера. Протокол OpenFlow расширен, для того чтобы поддерживать удаленное инструктирование PIL, имеющее отношение к идентификации, внедрению и демультиплексированию пакетов OAM OpenFlow.

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

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

С использованием информации обратной связи, предоставляемой коммутаторами OpenFlow, имеющей отношение к контролю пакетов OAM и ассоциированную с потоком данных OpenFlow, контроллер OpenFlow может реализовывать стандартные функции OAM, подобные проверке возможности соединения (CV), прослеживанию линии связи (LT), измерению задержки (DM), измерения потерь (LM) для любого потока данных OpenFlow.

АРХИТЕКТУРА OPENFLOW

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

В технических условиях OpenFlow 1.1, были определены два типа таблиц, таблица потоков и групповая таблица. В таблице потоков, поле правил содержит в себе вектор атрибутов из заголовка. Вектор содержит переменные заголовков Ethernet, MPLS, IP (межсетевого протокола) и TCP/UDP (протокола управления передачей/протокола дейтаграмм пользователя). Правило групповой таблицы является индексом, идентифицирующим действие в списке действий, которые должны выполняться для пакета. Групповая таблица, тем самым, поддерживает сложные действия, такие как многоадресная передача и защита.

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

Заключительная таблица в конвейере обработки пакетов является групповой таблицей. Групповая таблица состоит из групповых записей. Возможность пакетов в конкретном потоке данных (то есть, конкретном потоке) указывать на группу дает OpenFlow возможность представлять дополнительные способы пересылки пакетов такого потока (например, выбор, все, преодоление отказа, и подобные действия). Есть сегменты действий (Action Buckets), ассоциированные с записью групповой таблицы, где каждый сегмент действий содержит в себе набор действий для выполнения. Запись групповой таблицы определяет, какой сегмент действий следует выполнять, где возможные действия подобны определенным в таблицах потоков.

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

АРХИТЕКТУРА ЭЛЕМЕНТА СЕТИ

Варианты осуществления изобретения реализованы в элементе сети, таком как маршрутизатор или коммутатор в глобальной сети, такой как сеть Интернет или подобная сеть. Примерный элемент сети проиллюстрирован на фиг. 2. Элемент 201 сети может включать в себя сетевой процессор 203, который обрабатывает пакеты, принимаемые из входных физических портов 221 и передаваемые выходными физическими портами 223, каждый из которых присоединяет элемент сети к сети или набору сетей. ‘Набор’ (‘set’) в качестве используемого в материалах настоящей заявки обозначает положительное целое число элементов, включая один элемент.

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

Сетевой процессор 203 может включать в себя набор коммутационных модулей, виртуальных портов и агентов протокола в числе других компонентов. Такие компоненты, существенные для понимания процесса OAM OpenFlow, проиллюстрированы и обсуждены наряду с тем, что другие компоненты опущены в целях ясности. Коммутационные модули могут включать в себя коммутационные модули 205 не-OpenFlow и коммутационные модули 209 OpenFlow. Коммутационные модули 205 не-OpenFlow могут быть любым количеством модулей, выделенных под обработку пересылки и обработки пакетов данных, в том числе, например, создания или прекращения действия кадров OAM. Коммутационный модуль 209 OpenFlow описан в материалах настоящей заявки подробнее со ссылкой на фиг. 3A и 3B. Коммутационный модуль 209 OpenFlow реализует таблицу потоков и управляет пересылкой и обработкой всех пакетов данных OpenFlow.

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

В одном из вариантов осуществления, виртуальные порты 211A и 211B по выбору могут предусматривать предварительную обработку пакетов OAM, принятых элементом 201 сети. Пакеты OAM могут направляться в эти виртуальные порты для обработки и обновления метаданных этих пакетов OAM. В одном из вариантов осуществления, пакеты OAM могут направляться в эти виртуальные порты источниками пакетов OAM, в каком случае, метаданные пакетов OAM обновляются портом по мере того, как направляются источником, чтобы обеспечить надлежащую пересылку или обработку коммутационным модулем OpenFlow.

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

ИДЕНТИФИКАЦИЯ ПАКЕТОВ

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

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

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

ВНЕДРЕНИЕ ПАКЕТОВ

В одном из примеров, любой коммутатор OpenFlow, который управляется директивами контроллера OpenFlow, или другой источник для внедрения пакетов (обозначаемых как размеченные пакеты), таких как пакеты OAM, в поток данных имеет дело с пакетами, которые должны внедряться, которые сформированы объектом (то есть, источником), который может не быть частью механизма пересылки OpenFlow. Таким объектом, например, может быть внешний модуль OAM, прикрепленный к коммутатору (например, коммутационному модулю 205 не-OpenFlow) или контроллеру OpenFlow. размеченные пакеты, сформированные такими объектами, могут приниматься коммутационным модулем OpenFlow через виртуальные порты. В одном из вариантов осуществления, любые пакеты, поступающие в коммутационный модуль OpenFlow через физический или виртуальны порт, должны отправляться через весь конвейер обработки пакетов.

Фиг. 3A и 3B - схемы двух примерных вариантов осуществления обработки, внедрения и обнаружения пакетов OAM OpenFlow в коммутационном модуле OpenFlow. Процессы, реализованные этими примерными коммутационными модулями, каждый начинается с начальной обработки потоков данных в первой таблице потоков. В одной из примерных конфигураций, проиллюстрированных на фиг. 3A, пакеты данных разных меньших потоков могут агрегироваться в общий больший поток. Запись о потоке будет определена в таблице потоков для каждого меньшего потока; действия этих записей будут управлять обновлением пакетов данных, чтобы приспосабливать их под новый агрегированный поток. Вторая запись о потоке может быть размещена в последующей таблице, которая будет описывать общий поток.

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

В первом примерном варианте осуществления на фиг. 3A, PIL 301 использует способность расширяемого сопоставления OpenFlow 1.1 для реализации основанного на анализе PIL процесса обработки пакетов. Модуль 301 PIL реализован первой таблицей потоков, а другие таблицы потоков смещены в ближайшую следующую таблицу потоков. Например, первая таблица потоков фактически реализована второй таблицей потоков, и так далее. Может быть продумано сопоставление, выполняемое каждой таблицей потоков, исследует метаданные, предусмотренные вместе с данными пакета и/или полями заголовка пакета данных. В этом последнем случае, новый тип сопоставления может определяться, если стандартные типы сопоставления не могут сопоставляться с требуемыми полями пакета. В этом примерном варианте осуществления анализа PIL, новая таблица 303 сопоставления PIL перечисляет все пакеты, которые должны вставляться в более поздние каскады конвейера, наряду с тем, что действие по умолчанию для такой таблицы (то есть, что делать с пакетами без сопоставления), должно отправлять эти пакеты без сопоставления в следующую таблицу.

Во втором примерном варианте осуществления, проиллюстрированном на фиг. 3B, модуль 301 PIL реализует управляемый метаданными процесс работа пакетов данных. Модуль 301 PIL принимает метаданные, передаваемые вместе с пакетом данных, где эти метаданные явным образом определяют, в каком каскаде конвейера пакет должен быть включен в общий поток данных. В этом варианте осуществления, модуль 301 PIL считывает метаданные каждого пакета данных и переправляет пакет данных в надлежащую таблицу потоков или в групповую таблицу, чтобы присоединить пакет данных к общему потоку. В этом примерном варианте осуществления управляемого метаданными обработки пакетов, метаданные или данные пакета могут включать в себя любое количество атрибутов, таких как атрибут, который является (1) идентификатором таблицы потоков (0-255 согласно OpenFlow 1.1), в которую должен пересылаться пакет данных. В случае, когда пакет отправляется непосредственно в групповую таблицу, тогда атрибутом может быть (2) ID (идентификатор) таблицы, установленный в значение из области идентификаторов таблиц потоков (например, 256 в случае OpenFlow 1.1). Другие атрибуты могут включать в себя (3) идентификатор группы (Group ID), где идентификатор таблицы может быть установлен в постоянную групповой таблицы (Group Table), иначе, он может не рассматриваться), и другие (4) метаданные, которые должны использоваться во время сопоставления.

Для осуществления первого примерного основанного на анализе PIL варианта осуществления, проиллюстрированного на фиг. 3A, содержимое пакетов OAM OpenFlow (размеченных пакетов) используется (то есть, используется для сопоставления), чтобы определять, какие пакеты OAM должны обрабатываться. В случае пакетов OAM, содержимое пакета OAM должно проверяться (например, идентификаторы MEP) для выбора надлежащей таблицы или группы. Для сопоставления на этих полях, коммутационный модуль OpenFlow может реализовывать новый тип сопоставления. Более того, эти новые типы сопоставления характерны типу размеченного пакета. В некоторых ограниченных сценариях, текущая реализация коммутатора может поддерживать внедрение пакетов без каких бы то ни было значительных обновлений аппаратных средств. Скорее, функциональные возможности, описанные в материалах настоящей заявки, могут быть частично или полностью реализованы в конфигурации программного обеспечения посредством выполнения коммутационного модуля 109 OpenFlow с возможностью переключать стандартную обработку таблицы потоков и вставлять PIL в первую таблицу потоков.

Во второй управляемой метаданными реализации, проиллюстрированной на фиг. 3B, необходимы расширения для коммутационного модуля 109 OpenFlow. Однако, эти расширения не являются характерными решению. Поскольку решение о том, что делать с пакетом, фактически определяется модулем, внешним по отношению к коммутационному модулю OpenFlow, изменения в отношении коммутационного модуля OpenFlow, чтобы включал в себя модуль 301 PIL, могут быть общими для всех сценариев.

Что касается конфигурации коммутационного модуля 109 OpenFlow, первый основанный на анализе PIL вариант осуществления по фиг. 3A требует непрерывного сопровождения и конфигурирования первой таблицы (то есть модуля 301 PIL). Для вставки нового класса размеченного пакета в модуле 301 PIL, первая таблица должна быть расширена надлежащими правилами потока, чтобы сопоставлять и обрабатывать новый класс размеченного пакета. Во второй управляемой метаданными реализации по фиг. 3B, нет необходимости выполнять непрерывное управление конфигурацией.

ВИРТУАЛЬНЫЕ ПОРТЫ

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

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