ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННУЮ ЗАЯВКУ
Настоящая заявка испрашивает приоритет по предварительной заявке 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. Этот вариант осуществления внешнего источника не требует никаких обновлений конфигурации существующих процедур конфигурирования виртуального порта OpenFlow.
В варианте осуществления с внутренним определением, метаданные для пакета данных формируются самим виртуальным портом. В этом варианте осуществления, детализация определения метаданных привязывается к принимающему виртуальному порту, то есть, все пакеты из одного и того же виртуального порта будут обрабатываться одинаковым образом; каждый из пакетов данных будет задан одними и теми же данными и, как результат, будет внедряться посредством PIL в один и тот же каскад конвейера. Конфигурирование этих виртуальных портов может быть специализированным процессом или протоколом, управляемым контроллером OpenFlow.
Что касается обработки пакетов OAM, контроллер OpenFlow является одним из источников (размеченных) пакетов OAM. Например, контроллеру OpenFlow может потребоваться проверить, сконфигурирован ли поток данных OpenFlow надлежащим образом. Если система использует вариант осуществления управляемого метаданными обработки пакетов, то источник пакета данных должен также предусматривать метаданные. Чтобы заставить контроллер OpenFlow выполнять это требование, протокол OpenFlow может быть расширен, как описано ниже в материалах настоящей заявки.
ВАРИАНТ СООБЩЕНИЯ OPENFLOW ДЛЯ ФОРМИРУЕМЫХ КОНТРОЛЛЕРОМ РАЗМЕЧЕННЫХ ПАКЕТОВ
Вариант нового сообщения OpenFlow определяет новое сообщение из контроллера в коммутатор OpenFlow, содержащее следующие поля: (1) обычный заголовок OpenFlow, который кодирует версию протокола OpenFlow, тип и длину сообщения и идентификатор транзакции; (2) идентификатор входного порта, который рассматривается во время сопоставления в качестве in_port; (3) начальный индекс таблицы, где внедряется пакет, который может быть установлен в действительный индекс таблицы или в постоянную GROUP_TABLE; (4) идентификатор группы, который действителен, если начальный индекс таблицы установлен в постоянную GROUP_TABLE, иначе, он должен быть установлен в 0 контроллером и должен игнорироваться коммутатором; (5) метаданные, которые должны использоваться во время сопоставления; и (6) пакет OAM, который должен быть вставлен. Примерная компоновка этого сообщения проиллюстрирована на фиг. 5.
Постоянная GROUP_TABLE должна быть вне индексируемой действительной таблицы потоков, чтобы избежать коллизии. В OpenFlow 1.1, таблицы потоков индексируются от 0 до 255. Значит, GROUP_TABLE может быть любым значением, большим чем 255.
ВАРИАНТ ДЕЙСТВИЯ OPENFLOW ДЛЯ ФОРМИРУЕМЫХ КОНТРОЛЛЕРОМ РАЗМЕЧЕННЫХ ПАКЕТОВ
Варианты осуществления изобретения определяют новое действие для использования при реализации контроля потоков OpenFlow и другой функции OAM. Этот вариант действия может пользоваться существующим сообщением Packet Out, специфицированным стандартом OpenFlow 1.1. Согласно стандарту, сообщение Packet Out может инструктировать коммутатор OpenFlow для отправки пакета через конвейер обработки посредством включения команды OFPAT_OUTPUT, где порт вывода установлен в виртуальный порт OFPP_TABLE. Однако, эта команда всего лишь выражает, что пакет должен отправляться через конвейер, но не дает возможности предписания, в каком каскаде в конвейере обработки коммутационного модуля OpenFlow следует его вставлять. Этот вариант осуществления определяет новое действие, которое обозначается в материалах настоящей заявки как OFPAT_INJECT_PACKET, которое содержит следующие поля: (1) индекс таблицы, кодирующий индекс таблицы потоков или индикатор, что должна использоваться групповая таблица (посредством постоянной GROUP_TABLE); (2) идентификатор групповой записи, идентифицирующий запись групповой таблицы, если индекс таблицы установлен в постоянную GROUP_TABLE, иначе, это значение установлено в ноль и должно игнорироваться PIL коммутационного модуля OpenFlow; и (3) поле метаданных, которое должно использоваться во время обработки пакета (то есть, сопоставления) в конвейере обработки. Примерная компоновка действия проиллюстрирована на фиг. 6.
Для внедрения размеченного пакета (например, пакета OAM) в конвейер обработки контроллером, сообщение вывода пакета может включать в себя действие OFPAT_INJECT_PACKET в своем поле действия, а не действие OFPAT_OUTPUT.
Фиг. 7A и 7B - блок-схемы последовательности операций одного из вариантов осуществления процессов модуля PIL и виртуального порта, соответственно, реализующих процесс внедрения пакета и систему, описанные выше в материалах настоящей заявки. Что касается модуля PIL, процесс в качестве проиллюстрированного на фиг. 7A инициируется в ответ на прием пакета данных из физического или виртуального порта (блок 701). Модуль PIL исследует каждый входящий пакет посредством использования основанного на анализе PIL обработки пакетов либо управляемого метаданными обработки пакетов. В любом случае, PIL сопоставляет данные пакета, чтобы идентифицировать пакеты для контроля потоков данных, такие как пакеты OAM, и чтобы определять, в какие из каскадов конвейера обработки пакетов отправлять пакет данных для реализации вставки пакета данных в общий поток данных (блок 703). В основанном на анализе PIL процессе, модуль PIL идентифицирует каскад конвейера на основании правил сопоставления, которые могут включать в себя любое поле пакета данных, полной структуры сопоставления, как описано выше, или любой их комбинации или подкомбинации. Сопоставление включает в себя совпадение с пакетом, включающим в себя элемент разметки, идентифицирующий пакет данных в качестве пакета OAM или подобного пакета для контроля потока данных. При управляемом метаданными анализе, правило сопоставления идентифицирует пакеты OAM на основании метки, но затем, главным образом, идентифицирует каскад конвейера для пересылки на основании идентификации метаданными каскада, который был определен портом, через который коммутатор OpenFlow принимал пакет данных. Пакеты данных, которые не помечены, пересылаются в каскад конвейера по умолчанию, который типично является следующим каскадом в конвейере.
В некоторых вариантах осуществления, перед пересылкой пакета данных в определенный каскад конвейера, действие модуля PIL, соотнесенное с правилом сопоставления, может выполняться для обновления метаданных пакета данных (блок 705). Обновление метаданных может оказывать влияние на обработку пакета данных в каскаде конвейера, в который он пересылается. После того, как метаданные обновлены, пакет данных затем пересылается в идентифицированный каскад конвейера (то есть, таблицу потоков или групповую таблицу) (блок 707).
Фиг. 7B - блок-схема последовательности операций процесса обработки пакетов на виртуальном порте. В одном из вариантов осуществления, процесс инициируется в ответ на прием сообщения внедрения пакета OpenFlow из контроллера или подобного источника пакета данных, который должен вставляться в поток данных (блок 751). Виртуальный порт может обрабатывать каждый пакет данных с использованием основанного на внешнем источнике процесса или процесса внутреннего определения. В любом случае, виртуальный порт может формировать пакет данных, которые должны вставляться в поток данных, в соответствии с указанием входящего сообщения из контроллера OpenFlow и определять метаданные для пакетов данных, которые должны отправляться в коммутационный модуль OpenFlow (блок 753). Метаданные могут определяться на основании информации, определенной во входящем сообщении (основанный на внешнем источнике процесс), или могут определяться виртуальным портом, в который направлено сообщение (внутренний процесс определения). После того, как пакет данных и метаданные были сформированы на основании основанного на внешнем источнике процесса или внутреннего процесса определения, затем, пакет данных и метаданные пересылаются в коммутационный модуль OpenFlow (блок 755).
ПРОЦЕСС ДЕМУЛЬТИПЛЕКСИРОВАНИЯ РАЗМЕЧЕННОГО ПАКЕТА
Способ демультиплексирования или удаления и обработки является процессом, реализуемым в пункте назначения или выходном коммутаторе OpenFlow. Процесс демультиплексирования дает возможность контроля потока данных OpenFlow вдоль его маршрута вплоть до коммутатора OpenFlow пункта назначения. Любой поддерживающий коммутатор OpenFlow, который идентифицирует контролируемые пакеты данных, такие как пакеты OAM, обозначается в материалах настоящей заявки как выходной коммутатор OpenFlow. В выходном коммутаторе OpenFlow могут быть определены две записи таблицы потоков: (1) первая запись таблицы потоков определяет критерии для идентификации размеченных пакетов данных и определяет их обработку, и (2) вторая запись таблицы потоков определяет обработку других пакетов данных. Обработка размеченных пакетов может кодироваться специальным действием OpenFlow либо может быть выражена отправкой размеченного пакета на вполне определенный виртуальный порт. В этом последнем случае, отправка размеченного пакета в виртуальный порт либо инициирует управляющее сообщение OpenFlow, которое кодирует информацию, имеющую отношение к размеченному пакету, либо ретранслирует размеченный пакет в специальный коммутационный модуль. Управляющее сообщение с кодированной информацией отправляется в контроллер OpenFlow, чтобы задействовать функции OAM. Два альтернативных процесса для обработки размеченных пакетов дополнительно обсуждены ниже.
ЛОКАЛЬНЫЙ ПРОЦЕСС ПРЕКРАЩЕНИЯ ДЕЙСТВИЯ КОММУТАТОРА
В этом варианте осуществления демультиплексирования размеченных пакетов данных, размеченные пакеты или кадры данных пересылаются в коммутационный модуль не-OpenFlow, который является отдельным от коммутационного модуля OpenFlow, и процесс конвейерной обработки. Коммутационный модуль не-OpenFlow и коммутационный модуль OpenFlow могут поддерживать связь друг с другом через виртуальный порт. Коммутационный модуль не-OpenFlow может пропускать метаданные в коммутационный модуль OpenFlow. Этот локальный процесс прекращения действия коммутатора предписывает, что коммутационный модуль OpenFlow способен передавать метаданные через виртуальный порт в другие коммутационные модули. Если коммутационный модуль не-OpenFlow, который способен обрабатывать метаданные, имеется в распоряжении, то виртуальный порт способен скрывать метаданные, то есть, отбрасывать их без их обработки.
ЦЕЛЕВОЙ ПРОЦЕСС КОНТРОЛЛЕРА
В этом варианте осуществления демультиплексирования размеченных пакетов данных, размеченные пакеты данных ретранслируются (то есть, пересылаются) в контроллер. Сообщение ввода пакета может использоваться для реализации этой функции без каких бы то ни было модификаций. Однако, сообщение ввода пакета не пропускает все метаданные пакета данных в контроллер, так как сообщение несет только входной порт (физический и/или виртуальный) и идентификатор таблицы. Поэтому, следующие дополнительные поля для сообщения ввода пакета определены, чтобы поддерживать этот целевой процесс контроллера, посредством добавления: (1) флаг выбора GROUP/FLOW TABLE (групповой таблицы/таблицы потоков), указывающий, что пакет данных принят после обработки посредством таблицы потоков или посредством групповой таблицы. Если этот флаг GROUP/FLOWTABLE установлен в 0, то поле table_id несет индекс таблицы потоков. Иначе, table_id должно быть установлено в 0 посредством PIL коммутационного модуля OpenFlow и должно быть опущено во время обработки контроллером; (2) поле метаданных, несущее значение поля метаданных, используемое во время обработки пакета; (3) поле идентификатора группы, которое определяет идентификатор выполняемой записи групповой таблицы. Оно несет действительную информацию, если флаг GROUP/FLOW TABLE установлен в 1. Иначе, это поле должно быть установлено в 0 и должно игнорироваться контроллером.
Фиг. 8 - блок-схема последовательности операций одного из вариантов осуществления процесса демультиплексирования. В одном из вариантов осуществления, процесс инициируется в ответ на прием пакета данных OpenFlow в коммутационном модуле OpenFlow (блок 801). Пакет данных сначала обрабатывается модулем PIL для сопоставления на идентичность пакета в качестве контролируемого (например, пакета OAM) посредством проверки заданного поля пакета данных на заданное значение, которое идентифицирует пакет в качестве контролируемого пакета данных (блок 803). Заголовок или метаданные принятого пакета могут использоваться для идентификации пакета в качестве контролируемого пакета, также могут использоваться полная структура сопоставления или любая их комбинация. В одном из вариантов осуществления, виртуальный порт, который принимал пакет данных, может модифицировать метаданные, чтобы идентифицировать пакет данных в качестве контролируемого пакета данных. В качестве отдельного или объединенного этапа, пакет данных может сопоставляться, чтобы определять, должен ли пакет данных пересылаться в коммутационный модуль не-OpenFlow или в коммутационный модуль OpenFlow (блок 805). Это может кодироваться в метаданных или заголовке пакета данных. Пакет данных может пересылаться в коммутационный модуль не-OpenFlow, чтобы обрабатываться, например, когда пакет данных является пакетом OAM, сформированным и контролируемым посредством модуля OAM, отдельного от контроллера OpenFlow. Пакет данных может отправляться в контроллер OpenFlow с использованием управляющего сообщения для предоставления полного пакета данных, включающего в себя метаданные, например, когда пакет данных является пакетом OAM, а модуль OAM является частью контроллера OpenFlow.
ПРИМЕР 1: ПОТОК ПАКЕТОВ ETHERNET
Этот раздел дает примерное использование варианта осуществления изобретения в качестве применяемого к идентификации кадров и конфигурированию внедрения и демультиплексирования кадра у кадров OAM для потока Ethernet.
ИДЕНТИФИКАЦИЯ
В первом примере, введены в действие потоки Ethernet, то есть, только поля заголовка Ethernet используются для сопоставления и обработки пакетов данных, в том числе, адресов источника и назначения MAC, и полей элементов разметки VLAN. Нет ограничений на полезную нагрузку пакета Ethernet.
DL_TYPE структуры сопоставления, которое определяет поле Ethertype пакета Ethernet, будет универсально подставляемым. Согласно этому примерному варианту осуществления изобретения, это поле DL_TYPE выбрано для распознавания пакетов данных. Для выбора надлежащего значения из имеющейся в распоряжении области (16 битов), может быть выбрано одно из нераспределенных значений Ethertype. Например, может быть выбрано значение, которое не входит в противоречие с распределенными значениями Ethertype, определенными IANA (Центром по присвоению номеров в Интернет).
На входной стороне контролируемого потока, установлена следующая конфигурация. Используется только одна таблица сопоставления. Для внедрения кадров OAM, заголовки пакетов являются такими же, как для служебных пакетов, за исключением Ethertype, которое установлено в OAM (например, 0xD001). Правило сопоставления сконфигурировано в качестве: адрес назначения Ethernet является реальным адресом назначения, в то время как другие поля являются универсально подставляемыми. Действие состоит в том, чтобы отправлять в следующую таблицу или порт вывода.
На выходной стороне, используется одиночная таблица с двумя записями о потоке. Первая запись о потоке предназначена для трафика OAM. Совпадение установлено в качестве: адрес назначения Ethernet=реальный адрес назначения, Ethertype=OAM (например, 0xD001), все другие поля являются универсально подставляемыми. Приоритет правила=101. Действие=отправить в порт OAM.
Вторая запись о потоке предназначена для служебного трафика. Совпадением является: адрес назначения Ethernet=реальный адрес назначения, все другие поля являются универсально подставляемыми. Приоритет правила=100. Действие=отправить в следующую таблицу или порт вывода.
ПРИМЕР 2: ПОТОК ПАКЕТОВ MPLS
Этот раздел дает примерное использование варианта осуществления изобретения по идентификации кадров и по конфигурированию внедрения и демультиплексирования кадра у кадров OAM для потока MPLS.
ИДЕНТИФИКАЦИЯ
Во втором примере, рассматриваются примерные потоки MPLS, и следующие совпадающие записи о потоке используются во время пересылки. Поля Ethernet могут быть или могут не быть установлены, но Ethertype установлен в 8847h или 8848h. Поле сопоставления метки MPLS установлено в действительное значение метки (между 16 и 1048576). Все другие поля сопоставления не будут рассматриваться во время сопоставления согласно стандарту OpenFlow 1.1. В таком случае, вторая метка используется для исключений пакетов. Пакеты OAM могут идентифицироваться, например, посредством установки второй метки со значением от 0-15, которое не предписано другими стандартами.
На входной стороне, используется одиночная таблица с одной записью о потоке. Для внедрения кадров OAM, заголовки пакетов являются такими же, как для служебных пакетов, за исключением того, что используется дополнительный заголовок MPLS с меткой OAM (например, 10). Запись таблицы потоков сконфигурирована в качестве совпадения: Ethertype=0×8847, MPLS=given_label (данная метка), все другие поля являются универсально подставляемыми. Действие=«вытолкнуть» given_label и отправить в следующую таблицу или порт вывода.
На выходной стороне, используются две таблицы. Первая таблица содержит в себе одиночную запись о потоке как для контролируемых, так и контролирующих пакетов. Совпадение установлено в given_label, все другие поля являются универсально подставляемыми. Действие состоит в том, чтобы удалять метку и переходить на вторую таблицу. Групповая таблица содержит в себе две записи. Первая предназначена для контролирующего пакета с совпадением Ethertype=0×8847, MPLS=OAM (например, 10), все другие поля являются универсально подставляемыми. Приоритет: 101. Действие: отправить в порт OAM. Вторая запись предназначена для контролируемого трафика, с совпадением, установленным в Metadata (метаданные)=данная метка, все другие поля являются универсально подставляемыми. Приоритет=100. Действие=отправить в следующую таблицу или порт вывода.
ПРИМЕР 3: ПОТОК ПАКЕТОВ IP
Этот раздел дает примерное использование варианта осуществления изобретения для идентификации кадров, конфигурирования внедрения кадра и внедрения кадров OAM в поток IPv4.
ИДЕНТИФИКАЦИЯ
В случае потока IP, поля Ethernet могут быть или могут не быть установлены, но Ethertype установлено в 0800h. Поля заголовка IP рассматриваются, подобно адресу IP источника и назначения, и нет ограничений на полезную нагрузку пакета IP. В таком случае, Протокол (Protocol) структуры сопоставления IP, который отражается в следующий инкапсулированный протокол пакета IP, будет универсально подставляемым. Согласно одной из примерных реализаций этого изобретения, это поле будет выбрано для распознавания определенных пакетов.
На входной стороне, используется одиночная таблица. Для внедрения кадров OAM, заголовки пакетов являются такими же, как для служебных пакетов, за исключением поля IPv4_proto, которое установлено в новый тип OAM (например, 250). Совпадение записи о потоке установлено в EtherType=0800, адрес назначения IP: данный адрес назначения, все другие поля=универсально подставляемые. Действие состоит в том, чтобы отправлять в следующую таблицу или порт вывода.
На выходной стороне, используется одна таблица с двумя записями. Первая запись о потоке предназначена для трафика OAM. Совпадением является: Ethertype=0800, адрес назначения IP: данный адрес назначения, IPv4_proto: OAM (например, 250), все другие поля являются универсально подставляемыми. Приоритет правила=101. Действие=отправить в порт OAM. Вторая запись о потоке предназначена для служебного трафика. Совпадением является: EtherType=0800, адрес назначения IP=данный адрес назначения, все другие поля являются универсально подставляемыми. Приоритет правила=100. Действие=отправить в следующую таблицу или порт вывода.
Фиг. 9 - схема одного из вариантов осуществления сети OpenFlow, поддерживающей OAM. В одном из вариантов осуществления, OAM реализованы посредством ввода в действие имеющих отношение к OAM элемента управления и логики контроллера 901 OpenFlow. Коммутаторы 907A-Z OpenFlow реализуют базовые и основополагающие функции поддержки OAM, которые снабжают контроллер 901 OpenFlow достаточной информацией о состоянии сети OpenFlow и потоках данных OpenFlow в пределах сети OpenFlow, чтобы реализовывать набор функций OAM. Фиг. 9 дополнительно иллюстрирует примерную организацию компонентов контроллера OpenFlow и коммутатора OpenFlow, и примерный набор обменов сообщениями, выполняемых между компонентами, чтобы давать возможность функций OAM. Примерная сеть включает в себя одиночный контроллер 901 OpenFlow и набор коммутаторов 907A-Z OpenFlow. Специалист в данной области техники понял бы, что любое количество контроллеров OpenFlow и коммутаторов OpenFlow могут быть организованы и выполнены с возможностью для реализации принципов и структур, описанных в материалах настоящей заявки. Ради ясности, примерная конфигурация использует один контроллер OpenFlow и четыре коммутатора OpenFlow.
Контроллер 901 OpenFlow может включать в себя модуль 903 OAM и модуль 905 соотнесения сообщений. Модуль 903 OAM может управлять реализацией функциональных возможностей OAM в пределах контроллера 903 OpenFlow. Модуль 903 OAM может принимать запросы на имеющие отношение к OAM данные или инструкции для выполнения функциональных возможностей OAM из других компонентов контроллера OpenFlow (не показаны) или из других источников, внешних по отношению к контроллеру 901 OpenFlow. Модуль 903 OAM OpenFlow может поддерживать функции OAM, в том числе, проверку возможности соединения (CV), трассировку линии связи (LT), измерение потерь (LM), измерение задержки (DM), проверки непрерывности (CC) и подобные функции OAM.
Модуль 903 OAM может выполняться с помощью коррелятора 905 сообщений. Коррелятор сообщений может быть отдельным модулем в пределах контроллера 901 OpenFlow или может быть компонентом модуля 903 OAM. Коррелятор 905 сообщений принимает и сортирует входящие сообщения ответа по контролю из коммутаторов 907A-Z OpenFlow в домене контроллера 901 OpenFlow. Коррелятор 905 сообщений сопоставляет входящие сообщения ответа по контролю с запрошенными функциями OAM, выполняемыми с помощью модуля 903 OAM. Коррелятор 905 сообщений может сопоставлять входящие сообщения ответа по контролю на основании явного идентификатора в пределах сообщения ответа по контролю, метаданных в пределах данных ответа по контролю или подобной информации в данных ответа по контролю. Модуль 903 OAM также может делать идентификаторы и метаданные, ассоциированные с каждой запрошенной функцией OAM, имеющимися в распоряжении у коррелятора 905 сообщений, чтобы давать возможность сопоставления сообщений ответа по контролю. В одном из примерных вариантов осуществления, коррелятор 905 сообщений сопоставляет сообщения ответа по контролю с запрошенными функциями OAM на основании пакета OAM или подобных данных, которые включены сообщением ответа по контролю. Принятый пакет OAM сопоставляется с пакетом OAM, сформированный модулем 903 OAM и отправленный через сообщение инициирования контроля в коммутатор 907A OpenFlow.
Модуль 903 OAM и/или коррелятор 905 сообщений реализуют общую процедуру контроля, как показанная на фигуре. Процесс может инициироваться в ответ на запрос какой-нибудь функции OAM из любого источника, в том числе, источников, внутренних и внешних по отношению к контроллеру 901 OpenFlow. Контроллер 901 OpenFlow отправляет сообщение «инициировать контроль» в коммутатор 907A OpenFlow, запрашивающий, чтобы коммутатор 907A OpenFlow отправлял пакет OAM или подобный ‘зондирующий’ пакет через конвейер 911A обработки пакетов коммутатора 901A OpenFlow. Сообщение инициирования контроля принимается в коммутаторе 907A OpenFlow агентом 909A протокола или подобным компонентом. Агент 909A протокола может формировать пакет OAM, который должен отправляться в конвейер обработки пакетов, как обсуждено выше в материалах настоящей заявки, например, посредством извлечения пакета OAM из сообщения инициирования контроля. Пакет OAM должен отправляться через конвейер 911A обработки пакетов, чтобы побуждать конвейер обработки пакетов и агент 909A протокола формировать и возвращать сообщение «ответа по контролю» в контроллер 901 OpenFlow.
Коммутатор 907A обрабатывает пакет OAM посредством конвейера обработки пакетов, реализованного коммутационным модулем OpenFlow, как описано выше в материалах настоящей заявки. Конвейер обработки пакетов собирает сопоставимые записи таблицы потоков и групповой таблицы и подобные данные показателей, ассоциированные с этими записями таблиц, из набора счетчиков и подобных механизмов, поддерживаемых коммутационным модулем OpenFlow. Коммутационный модуль OpenFlow агрегирует пакет OAM с обозначенным потоком данных OpenFlow, из условия чтобы он имел предварительно определенное совместное использование с потоком данных OpenFlow. В проиллюстрированном примере, пакет OAM будет отправляться в коммутатор 907B OpenFlow. Коммутатор 907A OpenFlow, после обработки пакета OAM в конвейере обработки пакетов, отправляет сообщение ответа по контролю в контроллер 901 OpenFlow, кодирующее сопоставимые записи таблицы потоков и записи групповой таблицы вместе с ассоциированными данными показателей. Эти данные, поставляемые сообщением ответа по контролю, собираются и вставляются в сообщение агентом 909A протокола.
Сообщение OAM и ассоциированный поток данных OpenFlow принимаются коммутатором 907B OpenFlow в промежуточном коммутаторе 907B OpenFlow. В проиллюстрированном примере, коммутатор 907B OpenFlow не реализует вариант осуществления с поддержкой OAM, описанный в материалах настоящей заявки. Таким образом, коммутатор 907B OpenFlow обрабатывает пакет 907B OAM, как если бы он был любым другим пакетом данных OpenFlow, более точно, таким же образом, как поток данных OpenFlow, с которым ассоциирован пакет OAM. В примере, коммутатор 907B OpenFlow пересылает пакет OAM и ассоциированный поток данных OpenFlow в коммутатор 907C OpenFlow.
Коммутатор 907C OpenFlow принимает пакет OAM и обрабатывает его согласно конфигурации своего конвейера 911C обработки пакетов в коммутационном модуле OpenFlow. В дополнение, агент 909C протокола отправляет копию пакета OAM в контроллер 901 OpenFlow наряду с данными сопоставимой записи таблицы потоков и записи групповой таблицы, в том числе, данные записей и ассоциированных показателей для пакета OAM и ассоциированного потока данных OpenFlow. Эта информация отправляется в контроллер 901 OpenFlow в сообщении ответа по контролю. Согласно конфигурации коммутатора 907C OpenFlow, пакет OAM затем пересылается в следующий коммутатор 907Z OpenFlow.
Коммутатор 907Z OpenFlow принимает пакет OAM и обрабатывает его согласно конфигурации своего конвейера 911Z обработки пакетов в коммутационном модуле OpenFlow. В дополнение, агент 909Z протокола отправляет копию пакета OAM в контроллер 901 OpenFlow наряду с данными сопоставимой записи таблицы потоков и записи групповой таблицы, в том числе, данные записей и ассоциированных показателей для пакета OAM и ассоциированного потока данных OpenFlow. Эта информация отправляется в контроллер 901 OpenFlow в сообщении ответа по контролю. Согласно конфигурации коммутатора 907Z OpenFlow, пакет OAM затем может отбрасываться, так как ассоциированный поток данных OpenFlow достиг оконечной точки в сети OpenFlow или последнего контролируемого элемента сети в сети OpenFlow (то есть, может контролироваться только часть маршрута через сеть OpenFlow).
В одном из вариантов осуществления, агент протокола охватывает процессы и структуры, описанные в материалах настоящей заявки со ссылкой на фиг. 1-8 для внедрения пакетов OAM в конвейер обработки пакетов коммутационного модуля OpenFlow, как описано со ссылкой на фиг. 1-8. Подобным образом, агент протокола также может охватывать процессы и структуры, описанные в материалах настоящей заявки со ссылкой на фиг. 1-8, для демультиплексирования пакетов OAM и формирования управляющих сообщений OpenFlow для заданного контроллером OpenFlow демультиплексирования. Как правило, реализация OAM, описанная со ссылкой на фиг. 9-14, может быть реализована на основе общих функций контроля пакетов, описанных со ссылкой на фиг. 1-8.
СООБЩЕНИЯ ИНИЦИИРОВАНИЯ КОНТРОЛЯ
Сообщение инициирования контроля инструктирует коммутатор OpenFlow, чтобы обрабатывал пакеты OAM в конвейере обработки пакетов коммутационного модуля OpenFlow и отправлял отчет об информации показателей обратно в контроллер OpenFlow через сообщения ответа по контролю. Сообщение инициирования контроля может нести весь пакет OAM или может идентифицировать пакет OAM, который должен формироваться коммутатором OpenFlow. Есть несколько способов для реализации сообщения инициирования контроля в OpenFlow. Сообщение инициирования контроля может быть исправленным сообщением вывода пакета (Packet Out), расширенным сообщением вывода пакета или новым типом сообщения OpenFlow.
Каждое из сообщений инициирования контроля порождает подобное поведение в коммутаторе OpenFlow. Когда коммутатор OpenFlow принимает сообщение инициирования контроля из контроллера OpenFlow, содержащего в себе пакет OAM, коммутатор OpenFlow будет отзываться сбором информации показателей об обработке пакета OAM и/или ассоциированного потока данных OpenFlow. Собранные данные могут включать в себя информацию обо всех сопоставлениях таблицы потоков и групповой таблицы, навлекаемых во время прослеживания пакета OAM коммутатора OpenFlow. Когда коммутатор OpenFlow заканчивает обработку пакета OAM, он отвечает контроллеру OpenFlow сообщением ответа по контролю, содержащим в себе собранную информацию показателей.
Сообщение инициирования контроля также может идентифицировать или определять некоторые инструкции для обработки пакета OAM. Например, сообщение инициирования контроля может запрашивать некоторые действия, которые должны выполняться над пакетом OAM, определять, через какой выходной порт пакет OAM должен отправляться, отправлять пакет через весь конвейер обработки пакетов и выдавать подобные инструкции для обработки пакета OAM.
ИСПРАВЛЕННОЕ СООБЩЕНИЕ ВЫВОДА ПАКЕТА
Сообщение вывода пакета, предписанное OpenFlow, дает контроллеру OpenFlow возможность быть способным вставлять пакеты в конвейер обработки пакетов коммутатора OpenFlow или отправлять пакет на любом порте коммутатора OpenFlow. В одном из вариантов осуществления, вариант реализации для сообщения инициирования контроля должен рассматривать сообщение вывода пакета в качестве сообщения инициирования контроля. В этом примере, коммутатор OpenFlow будет выполнен с возможностью собирать информацию показателей по всем пакетам, отправленным контроллером OpenFlow посредством использования сообщения вывода пакета, и формировать отчет о том, что случилось с пакетом, в форме сообщения ответа по контролю, включающего в себя собранные данные информации показателей.
РАСШИРЕННОЕ СООБЩЕНИЕ ВЫВОДА ПАКЕТА
В одном из вариантов осуществления, сообщение вывода пакета, предписанное OpenFlow, расширяется для реализации сообщения инициирования контроля. Сообщение вывода пакета задает новое действие, действие OFPAT_TRIG_MON. Если агент протокола коммутатора OpenFlow принимает сообщение вывода пакета и находит это новое действие в списке действий сообщения вывода пакета, то он применяет дополнительные процедуры, описанные относительно сообщения инициирования контроля. Иначе, агент протокола выполняет стандартную операцию вывода пакета, которая предписана стандартом OpenFlow.
Фиг. 10 иллюстрирует один из вариантов осуществления действия OFPAT_TRIG_MON. Поскольку существование действия в сообщении вывода пакета указывает, что процедуры сообщения инициирования контроля должны выполняться соответствующим образом, действие не несет дополнительных полей. Технические условия OpenFlow указывают, что действие должно быть по меньшей мере в 8 октетов длиной, поэтому, поле заполнения длиной 4 октета определено для приведения действия в соответствие с этим аспектом OpenFlow.
НОВОЕ СООБЩЕНИЕ OPENFLOW
В одном из вариантов осуществления, новое сообщение OpenFlow используется для реализации сообщения инициирования контроля. Это сообщение несет такие же поля, как сообщение вывода пакета. Агент протокола и конвейер обработки пакетов коммутатора OpenFlow выполнены с возможностью обрабатывать новое сообщение OpenFlow и включенный в состав пакет OAM некоторым образом, подобным сообщению вывода пакета, за исключением того, что инициируется отслеживание и предоставление отчета о показателях. Поля, их формат и ассоциированные правила обработки пакета могут быть идентичными или подобными предписанным в разделе A.3.7 технических условий OpenFlow 1.1. Чтобы различать новое сообщение OpenFlow и сообщение вывода пакета OpenFlow, может быть назначен новый тип сообщения OpenFlow.
Фиг. 11 - блок-схема последовательности операций одного из вариантов осуществления процесса для обработки запроса функции OAM. В одном из вариантов осуществления, процесс запроса функции OAM инициируется в ответ на прием запроса на функцию OAM (блок 1101). Запрос функции OAM может приниматься из любого источника, в том числе, компонентов контроллера OpenFlow и вешнего программного обеспечения администрирования сети или подобных источников. Модуль OAM контроллера OpenFlow обрабатывает запрос OAM, формируя сообщение инициирования контроля, определяющее или предписывающее действия, которые должны выполняться коммутатором OpenFlow, чтобы предоставлять показатели для потока данных OpenFlow (блок 1103). Сообщение инициирования контроля включает в себя пакет OAM, который должен пересылаться и агрегироваться с потоком данных OpenFlow. Характеристики пакета OAM, таким образом, совпадают с таковыми у потока данных OpenFlow, для обеспечения предварительно определенного совместного использования с потоком данных OpenFlow, как описано выше в материалах настоящей заявки. Действия, определенные или предписанные сообщением инициирования контроля, включают в себя действия для вставки пакета OAM в конвейер обработки пакетов коммутатора OpenFlow или действия для пересылки пакета OAM в конкретный порт.
Сформированное инициирующее сообщение отправляется в коммутатор OpenFlow, в котором должен инициироваться контроль потока данных OpenFlow (блок 1105). Это будет начинать контроль потока данных OpenFlow в каждом расположенном ниже по потоку коммутаторе OpenFlow, который был сконфигурирован для поддержки основополагающего или характерного для OAM контроля пакетов, как описано в материалах настоящей заявки. Контроллер OpenFlow ожидает имеющих отношение к OAM данных показателей, которые должны быть возвращены из каждого из поддерживающих коммутаторов OpenFlow вдоль маршрута потока данных OpenFlow. Эти данные показателей принимаются в форме сообщений ответа по контролю из каждого из поддерживающих коммутаторов OpenFlow (блок 1107). Принимаемые сообщения ответа по контролю включают в себя копию пакета OAM или его идентификатор наряду с информацией показателей.
Эти сообщения ответа по контролю сначала могут обрабатываться в контроллере OpenFlow коррелятором сообщений для соотнесения сообщений ответа по контролю с запросом функции OAM, который инициировал процесс контроля (блок 1109). Входные сообщения ответа по контролю могут сопоставляться с запрошенной функцией OAM с использованием идентификатора из сообщения инициирования контроля или пакета OAM, который отправлялся модулем OAM контроллера OpenFlow. Коррелятор сообщений может компилировать данные показателей или подобным образом предварительно обрабатывать данные перед их передачей в модуль OAM в контроллере OpenFlow. В других вариантах осуществления, данные показателей не подвергаются предварительной обработке, а только соотносятся коррелятором сообщений. В дополнительных вариантах осуществления, функция соотнесения сообщений объединена с модулем OAM.
Модуль OAM, в таком случае, обрабатывает принятые данные показателей согласно функции OAM, которая была запрошена, или набору функций OAM, которые были запрошены (блок 1111). Показатель может иметь непосредственное отношение к контролю пакета OAM или ассоциированному потоку данных OpenFlow. В любом случае, данные показателей являются представляющими поток данных OpenFlow и используются для извлечения имеющей отношение к OAM информации для потока данных OpenFlow. Результаты набора функций OAM предоставляются в источник запроса (блок 1113). Результаты могут быть одиночным ответом или могут быть продолжающимся или перемежающимся ответом по мере того, как принимаются данные контроля, зависящие от запрошенной функции OAM.
ОБНАРУЖЕНИЕ И ОБРАБОТКА ПАКЕТОВ OAM В КОММУТАТОРАХ OPENFLOW
Каждый коммутатор OpenFlow в сети OpenFlow может быть выполнен с возможностью поддерживать функциональные возможности OAM в контроллере OpenFlow посредством распознавания пакетов OAM и предоставления отчета о показателях, имеющих отношение к пакетам OAM и связанному потоку данных OpenFlow. Каждый коммутатор OpenFlow может быть выполнен с возможностью ретранслировать пакет OAM или копию пакета на агент протокола, чтобы инициировать сообщение ответа по контролю после того, как пакет OAM прошел через конвейер обработки пакетов коммутационного модуля OpenFlow.
Пакет OAM пересылается в следующий коммутатор OpenFlow, если текущий коммутатор OpenFlow не является выходным коммутатором или коммутатором пункта назначения. Если коммутатор OpenFlow является выходным коммутатором или коммутатором пункта назначения, то пакет OAM и ассоциированные показатели могут пересылаться в контроллер OpenFlow. Если коммутатор OpenFlow является просто промежуточным коммутатором, то пакет OAM может пересылаться на следующий коммутатор для дальнейшей обработки после того, как показатели были предоставлены в отчете. Если коммутаторы OpenFlow являются коммутаторами пункта назначения, то отчеты для показателей должны формироваться, и пакет OAM отбрасывается. По умолчанию, коммутатор OpenFlow будет пересылать пакет OAM подобно любому другому пакету данных в ассоциированном потоке данных OpenFlow.
Пакет OAM, например, может идентифицироваться посредством проверки некоторых добавочных полей, не рассматриваемых во время идентификации пакетов данных в ассоциированном потоке данных OpenFlow, или по характерной полезной нагрузке, присутствующей в пакете OAM, как дополнительно описано выше в материалах настоящей заявки.
Сообщение ответа по контролю отправляется агентом протокола в контроллер OpenFlow и содержит в себе информацию показателей о всех сопоставлениях таблицы потоков и групповой таблицы в коммутационном модуле OpenFlow коммутатора OpenFlow, который проходил пакет OAM. Эти сопоставления будут такими же, как для пакетов данных ассоциированного пакета данных OpenFlow, за исключением записей таблицы потоков или групповой таблицы, которые идентифицируют пакет OAM в качестве пакета OAM в целях формирования сообщения ответа по контролю. Однако, контроллер OpenFlow осведомлен об этом отличии и может игнорировать эти воздействия на показатели или корректировать показатели на эти воздействия.
СЧИТЫВАНИЕ СЧЕТЧИКОВ
В качестве части стандартной обработки пакетов OpenFlow, обнаружение пакета OAM или подобного ‘зондирующего’ или контролируемого пакета, будет побуждать наборы счетчиков для записей таблицы потоков и групповой таблицы приращиваться по мере того, как пакет проходит через конвейер обработки пакетов коммутационного пакета OpenFlow. Счетчики могут приращиваться для сопоставлений со стандартными пакетами данных, а также особо контролируемыми пакетами, такими как пакеты OAM. Обновление этих счетчиков может быть непрерывным от запуска коммутатора OpenFlow или происходить в ответ на прием сообщения из контроллера OpenFlow. Обнаружение пакета контроля может инициировать считывание счетчиков каждой сопоставимой записи таблицы потоков или групповой таблицы. Значение счетчика может быть включено в сообщение ответа по контролю в качестве элемента поля статистики данной записи таблицы потоков или подобным образом предоставляться в качестве информации показателей, которая должна предоставляться в отчете в контроллер OpenFlow.
Это считывание счетчиков может происходить после обновления счетчиков или, по выбору, перед или после выполнения действий сопоставимых записей таблицы потоков или групповой таблицы. Однако, какой бы вариант ни реализовывался, синхронизация в течение обработки в коммутаторе OpenFlow (например, посредством агента протокола) считывает счетчики в тот же самый момент времени для стандартных пакетов данных, что и для особо контролируемых пакетов, таких как пакеты OAM.
ФОРМИРОВАНИЕ МЕТКИ ВРЕМЕНИ
В одном из вариантов осуществления, обработка пакетов в коммутаторе OpenFlow также включает в себя регистрацию метки времени, когда пакет данных или контролируемый пакет совпадает с записью таблицы потоков или групповой таблицы. Например, метка времени может сохраняться в качестве 8-октетного поля с форматом, основанным на формате представления времени, определенном согласно «Стандарту для протокола точной синхронизации часов для сетевых систем измерения и управления» («Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems») IEEE 1588-2002, или подобном формате. Метка времени может прикрепляться к сообщению ответа по контролю в качестве элемента поля статистики данной записи таблицы потоков.
Это формирование метки времени может происходить в коммутационном модуле OpenFlow после совпадения пакета с записью таблицы потоков или записью групповой таблицы, по выбору, до или после обновления счетчиков и, по выбору, до или после выполнения действий записи таблицы потоков или групповой таблицы. Однако, синхронизация формирования метки времени идентична для обоих, стандартных пакетов данных и особо контролируемых пакетов, таких как пакеты OAM.
СООБЩЕНИЕ ОТВЕТА ПО КОНТРОЛЮ
В ответ на обнаружение пакета OAM или подобного контролируемого пакета, пакет OAM и сопоставимые записи таблицы потоков и групповой таблицы с ассоциированными данными информации показателей предоставляются на агент протокола коммутатора OpenFlow, как обсуждено выше в материалах настоящей заявки. Затем, агент протокола коммутатора OpenFlow формирует сообщение ответа по контролю и отправляет сообщение ответа по контролю в контроллер OpenFlow. В одном из примерных вариантов осуществления, сообщение ответа по контролю включает в себя:
пакет OAM, чтобы помогать контроллеру OpenFlow соотносить сообщения ответа по контролю, инициированные одним и тем же пакетом OAM, но сформированные разными коммутаторами,
список статистических записей, где каждая запись содержит в себе:
i. ссылку на запись таблицы потоков или групповой таблицы, например, идентификатор таблицы и данные «cookie» записи о потоке;
ii. по выбору, метку времени выполнения данной записи таблицы;
ii. по выбору, значения счетчика данной записи таблицы.
Сообщение ответа по контролю может быть реализовано в качестве расширения стандартного сообщения ввода пакета OpenFlow, нового типа сообщения OpenFlow, или оно также могло бы быть осуществлено в качестве обновления для сообщения OFPT_STATS_REPLY типа статистики потока.
РАСШИРЕННОЕ СООБЩЕНИЕ ВВОДА ПАКЕТА
Этот вариант реализации расширяет специфицированное в OpenFlow сообщение ввода пакета необязательными полями, которые переносят список записей о показателях. Фиг. 12 - схема одного из примерных вариантов осуществления сообщения предоставления отчета по контролю, реализованного в качестве расширенного сообщения ввода пакета. Поля версии, типа, длины, XID (идентификатора обмена), buffer_id (идентификатора буфера), in_port (порта ввода), in_phy_port (физического порта ввода), длины кадра, причины, table_id (идентификатора таблицы) и данных кадра остаются такими же, как у базового сообщения ввода пакета, предписанного в OpenFlow 1.1. В этом варианте осуществления, эти поля сопровождаются набором полей, которые соотносятся с записью о показателе для каждого совпадения таблицы потоков или групповой таблицы. Поле Ref_type (типа ссылки) может быть с набором индикаторных битов, где один бит поля указывает, указывает, является ли таблица, на которую ссылаются показатели, таблицей потоков или групповой таблицей, один бит указывает, есть ли packet_count (счет пакетов), один бит указывает, есть ли счет байтов, и один бит указывает, есть ли метка времени. Поля идентификатора таблицы (Table id), идентификатора группы (Group id), приоритета, структуры сопоставления и данные «cookie» идентифицируют соответствующую запись таблицы потоков и групповой таблицы. Счет пакетов и счет байтов являются частью статистики записи таблицы потоков. Счет пакетов является количеством пакетов данных OpenFlow, которые сопоставились с данной записью о потоке в таблице потоков. Счет байтов хранит общий счет байтов ассоциированного пакета данных. Эти данные могут использоваться для выполнения функций OAM.
НОВОЕ СООБЩЕНИЕ OPENFLOW
В одном из вариантов осуществления, сообщение ответа по контролю является вновь определенным сообщением OpenFlow. Фиг. 13 - схема одного из примерных вариантов осуществления сообщения предоставления отчета по контролю, реализованного в качестве нового сообщения OpenFlow. Новый тип сообщения OpenFlow вводится для этого сообщения с типом ‘контроль’ (‘monitor’). Поля версии, типа, длины и XID подобны таковым у сообщения ввода пакета или расширенного сообщения ввода пакета, как описано выше и в технических условиях OpenFlow 1.1. В этом варианте осуществления, эти поля сопровождаются набором полей, которые соотносятся с записью о показателе для каждого совпадения таблицы потоков или групповой таблицы. Поле Ref_type (типа ссылки) может быть с набором индикаторных битов, где один бит поля указывает, указывает, является ли таблица, на которую ссылаются показатели, таблицей потоков или групповой таблицей, один бит указывает, есть ли packet_count (счет пакетов), один бит указывает, есть ли счет байтов, и один бит указывает, есть ли метка времени. Поля идентификатора таблицы, идентификатора группы, приоритета, структуры сопоставления и данные «cookie» идентифицируют сопоставимую запись таблицы потоков и групповой таблицы. Счет пакетов и счет байтов являются частью статистики записи таблицы потоков. Счет пакетов является количеством пакетов данных OpenFlow, которые сопоставились с данной записью о потоке в таблице потоков. Счет байтов хранит общий счет байтов ассоциированного пакета данных. Эти данные могут использоваться для выполнения функций OAM.
СБОР ИМЕЮЩЕЙ ОТНОШЕНИЕ К ПАКЕТУ OAM ИНФОРМАЦИИ
Агент протокола каждого коммутатора OpenFlow должен быть способен получать сопоставимые записи таблицы потоков и групповой таблицы и собирать ассоциированную информацию показателей по приему пакета OAM из коммутационного модуля. Для поддержки агента протокола, коммутатор OpenFlow ведет список сопоставимых записей таблицы потоков и групповой таблицы с ассоциированными показателями для всех пакетов или некоторого специального поднабора пакетов.
В одном из вариантов осуществления, действие по умолчанию коммутатора OpenFlow состоит в том, чтобы собирать такие показатели сопоставления для всех обрабатываемых пакетов. Однако, этот вариант дает в результате дополнительную административную и вычислительную нагрузку на коммутационный модуль OpenFlow. Этот режим работы, например, может использоваться в случае краткосрочного контроля по требованию. В одном из вариантов осуществления, для ослабления этой нагрузки, коммутационный модуль OpenFlow хранит только несколько (например, 1, 2 и 3) последних записей таблицы потоков и/или групповой таблицы сопоставления с показателями. В этом варианте осуществления, всякий раз, когда сохраняется новая запись о совпадении, самая старая запись о совпадении отбрасывается, если пространство хранения показателей сопоставления на пакет является полным. Этот процесс, например, может использоваться для упреждающего контроля.
В еще одном варианте осуществления, для ослабления этой вычислительной нагрузки и нагрузки хранения, коммутационный модуль OpenFlow может собирать показатели сопоставления только распознанных или размеченных пакетов (например, пакетов OAM). Количество сопоставимых записей для обслуживания и процесс для управления ими, могут быть конфигурируемыми модулем OAM контроллера OpenFlow или конфигурируемыми подобным образом.
Когда агент протокола или подобный компонент в коммутаторе OpenFlow является источником пакетов, например, в результате сообщения инициирования контроля, коммутационный модуль OpenFlow способен определять или моет инструктироваться агентом протокола, что пакет является пакетом OAM и что могут собираться показатели сопоставления. Когда пакет OAM поступает в коммутатор OpenFlow через физический порт, он отправляется непосредственно в модуль обработки пакетов. В таком случае, коммутационный модуль OpenFlow может идентифицировать распознанные пакеты на основании этой конфигурации. В примерной реализации, как дополнительно описано выше в материалах настоящей заявки, запись таблицы потоков может формироваться для идентификации распознанного пакета, и инструкция, назначенная на запись таблицы потоков, может инструктировать коммутационный модуль OpenFlow для запуска сбора показателей сопоставления. Недостаток этого варианта состоит в том, что не будет никакой информации о сопоставимых записях до приема такой инструкции, прибывающей в коммутационный модуль OpenFlow, собирающий статистику. Предыдущая конфигурация коммутатора OpenFlow может использоваться, чтобы избегать этой проблемы.
Фиг. 14 - блок-схема последовательности операций одного из варианта осуществления процесса для поддержки OAM в коммутаторе OpenFlow. Блок-схема последовательности операций излагает ход поддержки OAM в коммутаторе OpenFlow. Этот процесс может инициироваться в ответ на прием сообщения инициирования контроля из контроллера OpenFlow (Блок 1401). Сообщение инициирования контроля может обрабатываться в коммутаторе OpenFlow агентом протокола или подобным компонентом коммутатора OpenFlow, чтобы формировать пакет OAM, который определен сообщением инициации контроля (блок 1403). Пакет OAM может быть предусмотрен в пределах сообщения инициирования контроля, в каком случае, он извлекается и вставляется в конвейер обработки пакетов или пересылается в порт в соответствии с указаниями сообщения инициирования контроля (блок 1405). Вставка пакета OAM в конвейер обработки пакетов в коммутационном модуле OpenFlow или пересылка в порт агрегирует пакет OAM с потоком данных OpenFlow, который должен контролироваться.
Пакет OAM сопоставляется с записями таблицы потоков и/или групповой таблицы в коммутационном модуле OpenFlow (блок 1407). Это побуждает соответствующие счетчики приращиваться, и регистрироваться данные показателей сопоставления. После того, как пакет OAM прошел через коммутационный модуль OpenFlow, агент протокола уведомляется, и сообщение ответа по контролю формируется агентом протокола (блок 1409). Агент протокола собирает (то есть, извлекает) данные показателей и сопоставления из коммутационного модуля OpenFlow для потока данных OpenFlow и/или пакета данных OAM (блок 1411). Эти данные показателей добавляются в сообщение ответа по контролю и отправляются в контроллер OpenFlow (блок 1413). Информация показателей затем может использоваться контроллером OpenFlow для выполнения функции OAM, которая запрашивалась, и которая инициировала сообщение инициации контроля.
РЕАЛИЗАЦИЯ ФУНКЦИЙ OAM
ПРОВЕРКА ВОЗМОЖНОСТИ СОЕДИНЕНИЯ
Для проверки возможности соединения, контроллер OpenFlow может проверять, сопоставляются ли пакеты OAM контролируемого потока данных OpenFlow и только ли с требуемыми записями таблицы потоков. Что касается функции OAM проверки возможности соединения, сопоставимые записи таблицы потоков должны идентифицироваться как на входном, так и выходном коммутаторах OpenFlow. Это решается добавлением ссылки для каждой совпадающей записи таблицы на сообщение ответа по контролю, отправленное в контроллер OpenFlow из коммутатора OpenFlow в результате контроля пакета OAM. Эта ссылка может находиться в поле данных «cookie» структуры записей о потоке OpenFlow или всей структуры сопоставления.
Как только ответ на контролируемый пакет OAM имеется в распоряжении из обоих, входного и выходного порта соответственных коммутаторов OpenFlow в контроллер OpenFlow, контроллер OpenFlow может проверять, что контролируемый пакет точно соответствовал требуемым записям таблицы потоков. Эти записи таблицы потоков являются такими же, как сопоставимые записи таблицы потоков для контролируемого потока данных OpenFlow, единственным отличием может быть запись таблицы потоков, идентифицирующая сам контролируемый пакет в качестве пакета OAM. Эта функция является однонаправленной; чтобы проверять двунаправленный поток, оба направления должны проверяться раздельно.
ТРАССИРОВКА ЛИНИИ СВЯЗИ
Для предоставления функциональных возможностей трассировки линии связи, в дополнение к функциональным возможностям проверки возможности соединения, все промежуточные коммутаторы OpenFlow должны регистрироваться по мере того, как пакет OAM проходит эти промежуточные коммутаторы OpenFlow. Контроллер OpenFlow инициирует трассировку линии связи, отправляя надлежащее сообщение OAM на входной коммутатор OpenFlow для маршрута трассировки. После пересылки пакета OAM входным коммутатором OpenFlow, все промежуточные коммутаторы OpenFlow будут отвечать контроллеру OpenFlow с использованием сообщения ответа по контролю, отправляя сопоставимые идентификаторы потока, наряду с тем, что выходной коммутатор OpenFlow будет прекращать действие пакета OAM, отправляя его в контроллер OpenFlow, также с сопоставимыми идентификаторами потока. Эта функция является однонаправленной; чтобы проверять двунаправленный поток, оба направления должны проверяться раздельно.
ИЗМЕРЕНИЕ ПОТЕРЬ
Что касается функции OAM измерения потерь, количество отправленных пакетов и принятых пакетов должно быть известно на входном коммутаторе OpenFlow и выходном коммутаторе OpenFlow. Счетчиками для записей таблицы потоков коммутационного модуля OpenFlow является каждый коммутатор OpenFlow, который может использоваться для выполнения измерения потерь. Вместо использования одиночных счетчиков только в определенных местоположениях, счетчики всех совпадающих записей таблиц используются наряду с обработкой пакета OAM. Для измерения потерь в добавление к идентификации записей о потоке, счетчики сопоставимых пакетов также добавляются в данные, которые должны отправляться в контроллер OpenFlow.
Посредством использования этих счетчиков из входного коммутатора OpenFlow и выходного коммутатора OpenFlow, контроллер OpenFlow может рассчитывать потерю кадров потока данных OpenFlow. Потерей является количество соответствующих совпадений записей таблицы потоков, подсчитанных во входном коммутаторе OpenFlow, минус соответствующие совпадения записей таблицы потоков, подсчитанных в выходном коммутаторе OpenFlow. Предыдущие значения потери могут вычитаться из текущего значения для получения потери пакетов после последнего измерения в модуле OAM контроллера OpenFlow.
В зависимости от реализации, счетчики также считают измеренные пакеты OAM. Однако, поскольку контроллер OpenFlow инициирует и прекращает действие этих сообщений, значение потери может корректироваться, чтобы содержать в себе только количество потерянных пакетов данных OpenFlow. Эта функция OAM является однонаправленной; для измерения двунаправленного потока, оба направления должны измеряться раздельно.
ИЗМЕРЕНИЕ ЗАДЕРЖКИ
В одном из вариантов осуществления, на входном коммутаторе OpenFlow контролируемого потока данных OpenFlow, метка времени должна добавляться в пакет OAM измерения задержки. На выходном коммутаторе OpenFlow, дополнительная метка времени должна добавляться в пакеты OAM измерения задержки. Посредством использования этих меток времени, задержка пакета OAM может рассчитываться контроллером OpenFlow. В одном из вариантов осуществления, можно добавлять не только одну метку времени, но каждую метку времени для совпадающей записи таблицы потоков или групповой таблицы повсюду в коммутационном модуле OpenFlow.
Для измерения задержки, в добавление к идентификации записей о потоке, добавляются метки времени по времени совпадения. Посредством использования этих меток времени из входного коммутатора OpenFlow и выходного коммутатора OpenFlow, контроллер OpenFlow может рассчитывать задержку кадра потока данных OpenFlow. Этот вариант осуществления способа рассчитывает одностороннюю задержку, которая является значимой, если синхронизируются часы коммутаторов. Двухсторонняя задержка устраняет сдвиг часов. В одном из вариантов осуществления, двухсторонняя задержка двунаправленного потока рассчитывается по односторонней задержке двух направлений потока. Это реализуется по мере того, как контроллер OpenFlow принимает кадр OAM измерения задержки с первого направления; он производит дополнительное измерение в другом направлении. Расчет двухсторонней задержки может быть реализован как в ITU-T Y.1731, единственное отличие состоит в том, что время обработки на выходном коммутаторе OpenFlow, которое будет вычитаться из задержки, будет включать в себя отправку пакета OAM в контроллер OpenFlow и прием пакета OAM с другого направления.
ВИРТУАЛЬНЫЕ MEP И MIP
Как подробнее описано выше, оконечные точки технического обслуживания (MEPs) или промежуточные точки контроля (MIPs) должны быть способны размещаться в различных местах в конвейере обработки, чтобы поддерживать многочисленные типы функций OAM. В примерной конфигурации, пакеты данных разных меньших потоков данных OpenFlow могут агрегироваться в общий больший поток. Затем, запись о потоке будет определяться для каждого меньшего потока; действия этих записей будут инструктировать обновления пакетов, чтобы встраивать их в новый агрегированный поток. Вторая запись о потоке, размещенная в последующей таблице, будет описывать общий поток. MEP могли бы быть помещены как в меньших потоках, так и в агрегированном потоке.
Вместо размещения реальных MEP в этих точках наблюдения, варианты осуществления изобретения дают возможность размещения виртуальных MEP, которые в самом деле не присутствуют в коммутаторах OpenFlow; они существуют только в логике контроллера. Конвейер обработки пакетов контролируется и предоставляет отчеты в контроллер OpenFlow с использованием этих MEPs и MIPS, так что могут достигаться функциональные возможности OAM, описанные выше. Учитывая примерную конфигурацию, приведенную выше, оба типа потоков данных OpenFlow могут контролироваться контроллером OpenFlow, так как информация показателей, отправляемая обратно в контроллер OpenFlow, содержит в себе значения для обоих из них.
Варианты осуществления изобретения описывают расширение для работы коммутатора OpenFlow, которое предоставляет возможность внедрения и демультиплексирования определенных пакетов данных (размеченных кадров) в и/или из потока пакетов данных. Такие изменения конфигурации оказывают влияние только на коммутаторы OpenFlow, вовлеченные в процессы внедрения или удаления пакетов и не делая необходимыми никакие изменения конфигурации в отношении любых промежуточных коммутаторов OpenFlow. Таким образом, в любом промежуточном узле OpenFlow, одна и та же запись о пересылке будет применяться как в нормальных пакетах данных, так и размеченных кадрах. Эта функция обеспечивает предварительно определенное совместное использование для пакетов данных, вставленных и контролируемых в потоке данных.
Варианты осуществления изобретения дают возможность легкого и гибкого ввода в действие инструментов OAM в домене OpenFlow, так как они обеспечивают не только предварительно определенное совместное использование для контролируемых пакетов данных, но варианты осуществления также представляют собой механизмы для пересылки пакета OAM в/из точек контроля независимо от того, реализованы ли механизмы в коммутаторе OpenFlow или в контроллере OpenFlow.
В дополнение, варианты осуществления изобретения реализуют инструментарий OAM в домене OpenFlow, который не зависит от типа контролируемого потока данных. Этот инструментарий OAM может использоваться для контроля Ethernet, MPLS, IP, TCP и подобных потоков данных. Реализация OAM OpenFlow является независимой от какой бы то ни было лежащей в основе технологии и может использоваться для поддержки или реализации любого из характерных для технологии решений OAM, тем самым, избегая необходимость в раздельной реализации этих решений OAM. Поскольку обработка собранных данных показателей с коммутаторов OpenFlow реализована в контроллере OpenFlow, нет необходимости вводить в действие функциональные возможности OAM или физические точки контроля внутри коммутаторов OpenFlow. Устранение физических точек контроля в коммутаторах OpenFlow дает несколько преимуществ.
Например, нет необходимости в каких бы то ни было расширениях протокола конфигурирования для ввода в действие и конфигурирования этих точек контроля. Более того, конфигурирование таких точек контроля может быть довольно сложным, например, требующим, чтобы спецификация записей о потоке оценивалась для обеспечения каждой характеристики OAM (например, потери пакетов). Таким образом, варианты осуществления изобретения упрощают реализацию функциональных возможностей OAM в коммутаторе OpenFlow, тем самым, снижая стоимость этих коммутаторов OpenFlow.
Варианты осуществления изобретения включают в себя расширения для коммутатора OpenFlow, контроллера OpenFlow и протокола OpenFlow сверх определенных в OpenFlow 1.1. Эти расширения являются обратносовместимыми с OpenFlow 1.1. Только те коммутаторы OpenFlow, которые должны предоставлять обратную связь в контроллер OpenFlow, должны поддерживать расширения наряду с тем, что другие коммутаторы могут быть стандартными коммутаторами согласно существующим техническим условиям OpenFlow.
Должно быть понятно, что вышеприведенное описание подразумевается иллюстративным, а не ограничивающим. Многие другие варианты осуществления будут очевидны специалистам в данной области техники по прочтению и осмыслению вышеприведенного описания. Объем изобретения, поэтому, должен определяться со ссылкой на прилагаемую формулу изобретения наряду с полным объемом эквивалентов, правами которых наделена такая формула изобретения.
Изобретение относится к технологиям сетевой связи. Технический результат заключается в повышении скорости обработки данных. Способ содержит этапы, на которых: принимают, посредством модуля ОАМ элемента сети, запрос на исполнение функции ОАМ; формируют сообщение инициации контроля посредством модуля ОАМ, причем сообщение инициации контроля определяет действия, которые должны выполняться коммутатором OpenFlow в поднаборе коммутаторов OpenFlow, при этом действия предназначены для предоставления показателей для потока данных OpenFlow; отправляют сообщение инициации контроля в коммутатор OpenFlow; принимают множество сообщений ответа по контролю из поднабора коммутаторов OpenFlow, причем каждое из множества сообщений ответа по контролю включает в себя показатели для потока данных OpenFlow; соотносят множество сообщений ответа по контролю с запросом функции ОАМ; исполняют запрошенную функцию ОАМ с использованием показателей потока данных OpenFlow посредством модуля ОАМ; и возвращают результат запрошенной функции ОАМ. 3 н. и 11 з.п. ф-лы, 14 ил.
1. Способ для инициирования контроля и сбора показателей потока данных OpenFlow, выполняемый элементом сети, реализующим контроллер OpenFlow, причем контроллер OpenFlow включает в себя модуль эксплуатации, администрирования и управления (ОАМ), модуль ОАМ предназначен для обслуживания запроса функции ОАМ в сети, реализующей OpenFlow, причем способ предназначен для запрашивания, чтобы поднабор коммутаторов OpenFlow в сети предоставляли отчет о показателях для потока данных OpenFlow, чтобы снабжать модуль ОАМ информацией для исполнения запрошенной функции ОАМ, причем способ содержит этапы, на которых:
принимают, посредством модуля ОАМ элемента сети, запрос на исполнение функции ОАМ;
формируют сообщение инициации контроля посредством модуля ОАМ, причем сообщение инициации контроля определяет действия, которые должны выполняться коммутатором OpenFlow в поднаборе коммутаторов OpenFlow, при этом действия предназначены для предоставления показателей для потока данных OpenFlow;
отправляют сообщение инициации контроля в коммутатор OpenFlow;
принимают множество сообщений ответа по контролю из поднабора коммутаторов OpenFlow, причем каждое из множества сообщений ответа по контролю включает в себя показатели для потока данных OpenFlow;
соотносят множество сообщений ответа по контролю с запросом функции ОАМ;
исполняют запрошенную функцию ОАМ с использованием показателей потока данных OpenFlow посредством модуля ОАМ; и
возвращают результат запрошенной функции ОАМ.
2. Способ по п. 1, в котором формирование сообщения инициации контроля дополнительно содержит этап, на котором:
определяют пакет ОАМ, который должен агрегироваться коммутатором OpenFlow с потоком данных OpenFlow.
3. Способ по п. 1, в котором формирование сообщения инициации контроля дополнительно содержит этап, на котором:
определяют действия для таблицы потоков или групповой таблицы коммутационного модуля OpenFlow в коммутаторе OpenFlow.
4. Способ по п. 1, в котором формирование сообщения инициации контроля дополнительно содержит этап, на котором:
определяют показатели, которые должны предоставляться в отчете агентом протокола коммутатора OpenFlow.
5. Способ по п. 1, в котором соотнесение множества сообщений ответа по контролю с запросом функции ОАМ дополнительно содержит этап, на котором:
сопоставляют сообщения ответа по контролю с запрошенной функцией ОАМ с использованием пакета данных ОАМ внутри сообщений ответа по контролю.
6. Способ для инициирования контроля и сбора показателей потока данных OpenFlow, выполняемый элементом сети, реализующим коммутатор OpenFlow, причем коммутатор OpenFlow включает в себя агент протокола и коммутационный модуль OpenFlow, коммутатор OpenFlow предназначен для предоставления отчета о показателях для потока данных OpenFlow в контроллер OpenFlow, при этом показатели предназначены для поддержки функциональных возможностей эксплуатации, администрирования и управления (ОАМ) контроллера OpenFlow, при этом коммутатор OpenFlow пересылает пакет ОАМ с потоком данных OpenFlow и собирает показатели для потока данных OpenFlow, причем способ содержит этапы, на которых:
принимают, посредством коммутатора OpenFlow, сообщение инициации контроля из контроллера OpenFlow;
формируют пакет ОАМ посредством агента протокола, причем пакет ОАМ определен сообщением инициации контроля;
пересылают пакет ОАМ через коммутационный модуль OpenFlow, чтобы агрегировать пакет ОАМ с потоком данных OpenFlow;
обнаруживают пакет ОАМ в коммутационном модуле OpenFlow;
формируют сообщение ответа по контролю посредством агента протокола в ответ на обнаружение пакета ОАМ;
собирают показатели из коммутационного модуля OpenFlow для потока данных OpenFlow и пакета данных ОАМ; и
отправляют сообщение ответа по контролю с показателями в контроллер OpenFlow.
7. Способ по п. 6, дополнительно содержащий этап, на котором:
добавляют действие в таблицу потоков или групповую таблицу коммутационного модуля OpenFlow, определенную в сообщении инициации контроля.
8. Способ по п. 6, дополнительно содержащий этап, на котором:
вставляют пакет ОАМ в сообщение ответа по контролю посредством агента протокола.
9. Способ по п. 6, в котором сбор показателей дополнительно содержит этапы, на которых:
считывают счетчик записей таблицы потоков или счетчик записей групповой таблицы; и
считывают метку времени исполнения записи таблицы потоков или записи групповой таблицы.
10. Элемент сети для инициирования контроля и сбора показателей потока данных OpenFlow, реализующий контроллер OpenFlow, причем контроллер OpenFlow предназначен для обслуживания запроса функции ОАМ в сети, реализующей OpenFlow, причем контроллер OpenFlow предназначен для запрашивания, чтобы поднабор коммутаторов OpenFlow в сети предоставляли отчет о показателях для потока данных OpenFlow, чтобы предоставлять информацию для исполнения запрошенной функции ОАМ, причем элемент сети содержит:
контроллер OpenFlow, включающий в себя модуль эксплуатации, администрирования и управления (ОАМ), и модуль соотнесения сообщений,
причем модуль ОАМ выполнен с возможностью обрабатывать запрос функции ОАМ посредством исполнения функции ОАМ, заданной запросом функции ОАМ, и формирования сообщения инициации контроля, причем сообщение инициации контроля определяет действия, которые должны выполняться коммутатором OpenFlow в поднаборе коммутаторов OpenFlow, при этом действия предназначены для предоставления показателей для потока данных OpenFlow, при этом модуль ОАМ выполнен с возможностью отправлять сообщение инициации контроля в коммутатор OpenFlow, исполнять запрошенную функцию ОАМ с использованием показателей потока данных OpenFlow, предоставленных модулем соотнесения сообщений, и возвращать результат запрошенной функции ОАМ,
причем модуль соотнесения сообщений соединен с возможностью связи с модулем ОАМ, модуль соотнесения сообщений выполнен с возможностью принимать множество сообщений ответа по контролю из поднабора коммутаторов OpenFlow, причем каждое из множества сообщений ответа по контролю включает в себя показатели потока данных OpenFlow, при этом модуль соотнесения сообщений выполнен с возможностью соотносить множество сообщений ответа по контролю с запросом функции ОАМ.
11. Элемент сети по п. 10, в котором модуль ОАМ дополнительно выполнен с возможностью определять пакет ОАМ, который должен пересылаться коммутатором OpenFlow с потоком данных OpenFlow.
12. Элемент сети по п. 10, в котором модуль ОАМ дополнительно выполнен с возможностью определять действия для таблицы потоков или групповой таблицы коммутационного модуля OpenFlow в коммутаторе OpenFlow.
13. Элемент сети по п. 10, в котором модуль ОАМ дополнительно выполнен с возможностью определять показатели, которые должны предоставляться в отчете агентом протокола коммутатора OpenFlow.
14. Элемент сети по п. 10, в котором модуль ОАМ дополнительно выполнен с возможностью сопоставлять сообщения ответа по контролю с запрошенной функцией ОАМ с использованием пакета данных ОАМ в пределах сообщений ответа по контролю.
| Способ приготовления лака | 1924 |
|
SU2011A1 |
| Изложница с суживающимся книзу сечением и с вертикально перемещающимся днищем | 1924 |
|
SU2012A1 |
| Способ приготовления лака | 1924 |
|
SU2011A1 |
| Пресс для выдавливания из деревянных дисков заготовок для ниточных катушек | 1923 |
|
SU2007A1 |
