СИСТЕМА СВЯЗИ, УЗЕЛ, УСТРОЙСТВО УПРАВЛЕНИЯ, СПОСОБ СВЯЗИ И ПРОГРАММА
COMMUNICATION SYSTEM, NODE, CONTROL DEVICE, COMMUNICATION METHOD AND PROGRAM

Область техники, к которой относится изобретение
(Описание связанной заявки)
Настоящее изобретение испрашивает приоритет по заявке на патент Японии 2010-123054 (поданной 28 мая 2010 г.), содержимое которой включено в настоящий документ во всей своей полноте посредством ссылки на данное описание.
Настоящее изобретение относится к системе связи, узлу, устройству управления, способу связи и программе, и, более конкретно, к системе связи, узлу, устройству управления, способу связи и программе для осуществления связи посредством перенаправления пакетов при помощи узлов, скомпонованных в сети.
Уровень техники
В последнее время предлагается технология, называемая OpenFlow, описанная в непатентной литературе 1 и 2. OpenFlow идентифицирует связь как сквозные потоки и выполняет управление трактом (передачи), восстановление после отказа, выравнивание нагрузки и оптимизацию на попоточной основе. Коммутатор OpenFlow, который функционирует в качестве узла перенаправления, имеет защищенный канал для связи с контроллером OpenFlow и работает в соответствии с потоковой таблицей, к которой добавляется информация, и содержимое которой переписывается, в соответствии с инструкцией от контроллера OpenFlow по мере необходимости. В потоковой таблице набор из следующих трех определяется для каждого потока: правило совпадения (FlowKey/ключ совпадения), с которым сопоставляется заголовок пакета, действие (Action), которое определяет содержимое обработки, и потоковая статистическая информация (Stats) (см. фиг. 30).
Фиг. 31 изображает пример имен действий и содержимого действий, определенных в непатентной литературе 2. OUTPUT представляет собой действие для вывода пакета на заданный порт (интерфейс). SET_VLAN_VID-SET_TP_DST представляют собой действия для модифицирования полей пакетного заголовка.
Например, когда принимается первый пакет, коммутатор OpenFlow выполняет поиск в потоковой таблице элемента, который имеет правило совпадения (FlowKey), которое совпадает с информацией заголовка принятого пакета. Если найден элемент, совпадающий с принятым пакетом, в результате поиска, коммутатор OpenFlow выполняет содержимое обработки, описанное в поле «Действия» элемента для принятого пакета. С другой стороны, если не найден элемент, совпадающий с принятым пакетом, в результате поиска, коммутатор OpenFlow перенаправляет принятый пакет на контроллер OpenFlow по защищенному каналу, запрашивает контроллер OpenFlow на определение пакетного тракта, основываясь на источнике/назначении передачи принятого пакета, принимает потоковый элемент для пакетного тракта  и обновляет потоковую таблицу.
Список ссылок
Патентная литература
[Непатентная литература 1]
Nick McKeown и семь других авторов, “OpenFlow: Enabling Innovation in Campus Networks” [режим онлайн], [Поиск выполнен 26 февраля 2010 г.], Интернет <URL: http://www.openflowswitch.org//documents/openflow-wp-latest.pdf>
[Непатентная литература 2]
“OpenFlow Switch Specification” Version 1.0.0 (Wire Protocol 0x01) [Поиск выполнен 1 апреля 2010 г.], Интернет <URL: http://www.openflowswitch.org/documents/openflow-spec-v1.0.0.pdf>
Сущность изобретения
Техническая проблема
Раскрытие непатентной литературы, приведенной выше, включается в настоящий документ посредством ссылки на данное описание.
Следующий анализ дается настоящим изобретателем. Контроллер OpenFlow, который принимает вышеописанный запрос на определение тракта принятого пакета (см. s2 Packet-In (ввод пакета) на фиг. 33), определяет тракт перенаправления принятого пакета. Чтобы перенаправить принятый пакет и последующие пакеты, которые принадлежат одному потоку, на хост (В), потоковый элемент должен быть установлен во всех коммутаторах OpenFlow в тракте перенаправления (узел #1 и узел #2 на фиг. 33). Кроме того, основываясь на инструкции от сетевого администратора, контроллер OpenFlow должен иногда менять действие потокового элемента, который уже установлен, и в данном случае, должен изменить или удалить потоковый элемент.
Когда потоковый элемент, описанный выше, устанавливается, изменяется или удаляется при помощи протокола OpenFlow (см. “4.6 Flow Table Modification Messages” в непатентной литературе 2), задержка связи иногда генерируется между контроллером OpenFlow и коммутатором OpenFlow. Эта задержка, в свою очередь, вызывает задержку при установлении, изменении или удалении потокового элемента в некоторых из коммутаторов OpenFlow. В результате, в коммутаторе OpenFlow в тракте пакет сопоставляется с непредусмотренным потоковым элементом в потоковой таблице с проблемой, что непредусмотренное действие будет исполнено.
Фиг. 32 представляет собой схему, изображающую пример, в котором, когда коммутатор OpenFlow (узел #1) принимает пакет, который должен быть передан с хоста (А) на хост (В), и запрашивает контроллер на создание потокового элемента, вызывается задержка при установлении потокового элемента, который имеет ключ X совпадения, в ретранслирующем коммутаторе (узел #2). В примере на фиг. 32 узел #2 имеет потоковый элемент, имеющий ключ В совпадения, который конфликтует с ключом X совпадения потокового элемента, который должен быть установлен (в протоколе OpenFlow частичное совпадение с любым полем заголовка допускается в качестве ключа совпадения, и исключение конфликта между потоковыми элементами управляется в соответствии с порядком поиска потокового элемента). Поэтому, в узле #2 пакет, передаваемый с хоста (А), передается не на порт #2, на который пакет должен передаваться, но на порт #1, до того как будет завершено установление потокового элемента (ST8 на фиг. 32). Таким образом, когда используется протокол OpenFlow, непредусмотренный тракт перенаправления (исполнение действия) может легко вызываться вследствие задержки установления потокового элемента.
Один возможный способ для решения этой проблемы показан на фиг. 33. Т.е. контроллер (OpenFlow) передает потоковый элемент на узлы #1 и #2 (см. FlowMod(Add), указанный посредством s3 и s6 на фиг. 33) и одновременно передает запрос барьера (Barrier Request), определенный протоколом OpenFlow (см. “5.3.7 Barrier Message” в непатентной литературе 2 для запроса барьера; запрос/ответ барьера, указанный посредством s4 на фиг. 33). Когда принимается запрос барьера, узел завершает исполнение обработки, которая была принята перед тем, как был принят запрос барьера, и отвечает «Ответом барьера» (s5 на фиг. 33). Этот ответ позволяет контроллеру (OpenFlow) подтвердить, что потоковый элемент был правильно установлен. Проблема с этим способом заключается в том, что контроллер (OpenFlow) должен обмениваться запросом/ответом барьера со всеми узлами, в которых установлен потоковый элемент, таким образом увеличивая время, перед тем как пользовательский пакет может быть передан (s1(Пользовательский пакет)-s10(Пользовательский пакет) на фиг. 33).
Другим способом является использование запроса/ответа Stats вместо запроса/ответа барьера, описанного выше, для проверки, имеет ли каждый узел соответствующий элемент. Как и со способом, в котором используется запрос/ответ барьера, этот способ также требует обмена сообщениями во всеми узлами, в которых установлен потоковый элемент, для проверки, правильно ли установлен потоковый элемент, таким образом увеличивая время, перед тем как пользовательский пакет может быть передан (s1(Пользовательский пакет)-s10(Пользовательский пакет) на фиг. 33).
Кроме того, если некоторые потоковые элементы потеряны из-за отказа узла, после того как потоковые элементы установлены, как способ, в котором используется запрос/ответ барьера, так и способ, в котором используется запрос/ответ Stats, не могут предотвратить исполнение непредусмотренного действия.
Задачей настоящего изобретения является обеспечение системы связи, узла, устройства управления, способа связи и программы для предотвращения проблем, таких как те, которые описаны выше, в которых правило некорректной обработки (потоковый элемент) попадает в узел, и исполняется непредусмотренная обработка.
Решение проблемы
Согласно первому аспекту настоящего изобретения обеспечивается система связи, содержащая узел(-ы), который обрабатывает принятый пакет; и устройство управления, которое устанавливает правило обработки в узле, причем правило обработки задает правило совпадения и обработку для пакета, который согласуется с правилом совпадения, в которой узел удерживает идентификатор в ассоциации с правилом обработки и определяет, выполнять ли обработку для принятого пакета в зависимости от того, соответствует ли идентификатор принятого пакета идентификатору, ассоциированному с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом, причем обработка выполняется в соответствии с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом.
Согласно второму аспекту настоящего изобретения обеспечивается узел, который удерживает правило обработки в ассоциации с идентификатором, причем правило обработки задает правило совпадения и обработку для пакета, который согласуется с правилом совпадения, и определяет, выполнять ли обработку для принятого пакета в зависимости от того, соответствует ли идентификатор принятого пакета идентификатору, ассоциированному с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом, и, таким образом, обрабатывает принятый пакет, причем обработка выполняется в соответствии с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом.
Согласно третьему аспекту настоящего изобретения обеспечивается устройство управления, которое генерирует правило обработки, которое задает правило совпадения и обработку для пакета, который согласуется с правилом совпадения, генерирует идентификатор, который ассоциируется с правилом обработки, и который позволяет узлу(-ам) определить, выполнять ли обработку для принятого пакета, причем обработка выполняется в соответствии с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом, и устанавливает правило обработки и идентификатор в узле(-ах), который скомпонован в системе связи, для обработки принятого пакета.
Согласно четвертому аспекту настоящего изобретения обеспечивается способ связи, содержащий этапы: удержания правила обработки в ассоциации с идентификатором, причем правило обработки задает правило совпадения и обработку для пакета, который согласуется с правилом совпадения; и определения, выполнять ли обработку для принятого пакета в зависимости от того, соответствует ли идентификатор принятого пакета идентификатору, ассоциированному с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом, и, таким образом, обработкой принятого пакета, причем обработка выполняется в соответствии с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом. Этот способ объединяется с конкретной машиной, названной узлом, для обработки принятого пакета.
Согласно пятому аспекту настоящего изобретения обеспечивается способ связи, содержащий этапы генерирования правила обработки, которое задает правило совпадения и обработку для пакета, который согласуется с правилом совпадения; генерирования идентификатора, который ассоциируется с правилом обработки, и который позволяет узлу(-ам) определять, выполнять ли обработку для принятого пакета, причем обработка выполняется в соответствии с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом; и установления правила обработки и идентификатора в узле(-ах), который скомпонован в системе связи, для обработки принятого пакета. Этот способ объединяется с конкретной машиной, называемой устройством управления, которое устанавливает правило обработки в узле(-ах), который обрабатывает принятый пакет.
Согласно шестому аспекту настоящего изобретения обеспечивается программа, побуждающая узел(-ы), обеспечиваемый в системе связи для обработки принятого пакета, к выполнению обработки сохранения правила обработки в ассоциации с идентификатором, причем правило обработки задает правило совпадения и обработку для пакета, который согласуется с правилом совпадения; и определения, выполнять ли обработку для принятого пакета в зависимости от того, соответствует ли идентификатор принятого пакета идентификатору, ассоциированному с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом, причем обработка выполняется в соответствии с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом. Эта программа может записываться на считываемый компьютером носитель записи, который может быть не временным. Т.е. настоящее изобретение может быть воплощено в виде компьютерного программного продукта.
Согласно седьмому аспекту настоящего изобретения обеспечивается программа, побуждающая устройство управления, обеспечиваемое в системе связи для управления узлом(-ами), который обрабатывает принятый пакет, к выполнению обработки генерирования правила обработки, которое задает правило совпадения и обработку для пакета, который согласуется с правилом совпадения; генерирования идентификатора, который ассоциируется с правилом обработки, и который позволяет узлу(-ам) определять, выполнять ли обработку для принятого пакета, причем обработка выполняется в соответствии с правилом обработки, соответствующим правилу совпадения, которое согласуется с принятым пакетом; и установления правила обработки и идентификатора в узле(-ах). Эта программа может записываться на считываемый компьютером носитель записи. Т.е. настоящее изобретение может быть воплощено в виде компьютерного программного продукта.
Полезные эффекты изобретения
Согласно настоящему изобретению исполнение непредусмотренной обработки может предотвращаться в узле(-ах), скомпонованном в сети перенаправления данных.
Краткое описание чертежей
Фиг. 1 представляет собой схему, изображающую краткое содержание настоящего изобретения.
Фиг. 2 представляет собой другую схему, изображающую краткое содержание настоящего изобретения.
Фиг. 3 представляет собой схему, изображающую конфигурацию системы связи в первом примерном варианте осуществления настоящего изобретения.
Фиг. 4 представляет собой блок-схему, изображающую конфигурацию устройства управления (контроллера) в первом примерном варианте осуществления настоящего изобретения.
Фиг. 5 представляет собой схему, изображающую информацию, удерживаемую в базе данных (DB) потоковых элементов устройства управления (контроллера), показанного на фиг. 4.
Фиг. 6 представляет собой схему, изображающую информацию, удерживаемую в DB информации верификации устройства управления (контроллера), показанного на фиг. 4.
Фиг. 7 представляет собой блок-схему, изображающую конфигурацию узла в первом примерном варианте осуществления настоящего изобретения.
Фиг. 8 представляет собой схему, изображающую информацию, удерживаемую в потоковой таблице узла, показанного на фиг. 7.
Фиг. 9 представляет собой схему, изображающую пример пакета, который включает в себя информацию верификации (или к которому добавлена информация верификации).
Фиг. 10 представляет собой схему, изображающую пример конфигурации дополнительного заголовка с добавленной информацией верификации, показанного на фиг. 9.
Фиг. 11 представляет собой блок-схему последовательности операций, изображающую работу устройства управления (контроллера) в первом примерном варианте осуществления настоящего изобретения.
Фиг. 12 представляет собой блок-схему последовательности операций, изображающую работу узла(-ов) в первом примерном варианте осуществления настоящего изобретения.
Фиг. 13 представляет собой типовую схему, изображающую последовательность потока в системе связи в первом примерном варианте осуществления настоящего изобретения.
Фиг. 14 представляет собой диаграмму последовательности, изображающую последовательность потока в системе связи в первом примерном варианте осуществления настоящего изобретения.
Фиг. 15 представляет собой схему, изображающую информацию, удерживаемую в DB потоковых элементов устройства управления (контроллера) во втором примерном варианте осуществления настоящего изобретения.
Фиг. 16 представляет собой схему, изображающую информацию, удерживаемую в DB информации верификации устройства управления (контроллера) во втором примерном варианте осуществления настоящего изобретения.
Фиг. 17 представляет собой блок-схему, изображающую конфигурацию узла во втором примерном варианте осуществления настоящего изобретения.
Фиг. 18 представляет собой схему, изображающую информацию, удерживаемую в потоковой таблице узла, показанного на фиг. 17.
Фиг. 19 представляет собой схему, изображающую пример пакета, в который включена (внедрена) информация верификации.
Фиг. 20 представляет собой блок-схему последовательности операций, изображающую работу устройства управления (контроллера) во втором примерном варианте осуществления настоящего изобретения.
Фиг. 21 представляет собой блок-схему последовательности операций, изображающую работу узла во втором примерном варианте осуществления настоящего изобретения.
Фиг. 22 представляет собой схему, изображающую информацию, удерживаемую в DB потоковых элементов устройства управления (контроллера) в третьем примерном варианте осуществления настоящего изобретения.
Фиг. 23 представляет собой схему, изображающую информацию, удерживаемую в DB информации верификации устройства управления (контроллера) в третьем примерном варианте осуществления настоящего изобретения.
Фиг. 24 представляет собой схему, изображающую информацию, удерживаемую в потоковой таблице узла в третьем примерном варианте осуществления настоящего изобретения.
Фиг. 25 представляет собой схему, изображающую информацию, удерживаемую в DB потоковых элементов устройства управления (контроллера) в четвертом примерном варианте осуществления настоящего изобретения.
Фиг. 26 представляет собой схему, изображающую информацию, удерживаемую в DB информации верификации устройства управления (контроллера) в четвертом примерном варианте осуществления настоящего изобретения.
Фиг. 27 представляет собой схему, изображающую информацию, удерживаемую в потоковой таблице узла в четвертом примерном варианте осуществления настоящего изобретения.
Фиг. 28 представляет собой схему, изображающую пример пакета, используемого в пятом примерном варианте осуществления настоящего изобретения.
Фиг. 29 представляет собой схему, изображающую пример конфигурации дополнительного заголовка с добавленной информацией верификации по фиг. 28.
Фиг. 30 представляет собой схему, изображающую конфигурацию потокового элемента, описанного в непатентной литературе 2.
Фиг. 31 представляет собой схему, изображающую имена действий и содержимое действий, описанных в непатентной литературе 2.
Фиг. 32 представляет собой схему, изображающую работу контроллера OpenFlow (контроллера) и потокового коммутатора (узла), описанного в непатентной литературе 2.
Фиг. 33 представляет собой типовую схему и диаграмму последовательности, изображающие последовательность работы для надежного установления потокового элемента, используя протокол OpenFlow, описанный в непатентной литературе 2.
Описание вариантов осуществления
Сначала нижеследующее описывает краткое содержание примерного варианта осуществления настоящего изобретения. Следует отметить, что ссылочные позиции чертежей, добавленные к этому краткому содержанию, являются примерными только для того, чтобы помочь понять, но без намерения ограничить настоящее изобретение режимом, показанным на фигурах. Как показано на фиг. 1, когда принимается пакет, узел 10 (см. узел #2 на фиг. 1) системы связи примерного варианта осуществления настоящего изобретения извлекает правило обработки, которое согласуется с принятым пакетом, используя правило совпадения (ключ совпадения), включенное в правило обработки, удерживаемое в самом устройстве (этап 1). Затем узел 10 (см. узел #2 на фиг. 1) проверяет, является ли идентификатор, ассоциированный с извлеченным правилом обработки, идентичным идентификатору, включенному в принятый пакет (этап 2). Хотя в вышеприведенном описании узел 10 проверяет, что идентификатор, ассоциированный с правилом обработки, идентичен идентификатору, включенному в принятый пакет, настоящее изобретение не ограничивается этим способом. Например, настоящее изобретение включает в себя случай, в котором узел 10 проверяет, что идентификатор, ассоциированный с правилом обработки, соответствует идентификатору, включенному в принятый пакет. Это применяется также к последующим этапам и примерным вариантам осуществления. Если подтверждается в результате проверки, что идентификатор, ассоциированный с правилом обработки, совпадает с идентификатором принятого пакета, узел 10 (см. узел #2 на фиг. 1) выполняет обработку в соответствии с правилом обработки (этап 3).
Вышеописанный идентификатор представляет собой информацию, генерируемую устройством 20 управления (контроллером) в ассоциации с правилом обработки. Идентификатор генерируется и присоединяется, так что могут идентифицироваться правила обработки, которые могут согласовываться с принятым пакетом. Поэтому, если правило обработки извлекается посредством поиска, используя правило совпадения (ключ совпадения), но если идентификатор не совпадает с идентификатором принятого пакета, не выполняется действие правила обработки. Идентификатор включается в пользовательский пакет различными способами, например, идентификатор добавляется к пользовательскому пакету так, как показано на фиг. 1 и фиг. 2, или внедряется в конкретную область пользовательского пакета (см. фиг. 19).
Конфигурация, описанная выше, предотвращает исполнение непредусмотренного действия, даже когда имеет место условие, упомянутое выше в данном описании изобретения, например, когда установление правила обработки задерживается, или когда часть потокового элемента потеряна из-за ошибки в узле.
В примере на фиг. 1 узел извлекает правило обработки, которое согласуется с принятым пакетом, используя правило совпадения (ключ совпадения) и после этого проверяет, совпадает ли идентификатор, ассоциированный с извлеченным правилом обработки, с идентификатором принятого пакета. Вместо этого, другой способ также возможен, как показано на фиг. 2, в котором узел извлекает правило обработки, которое согласуется с принятым пакетом, используя идентификатор, и после этого проверяет, совпадает ли правило совпадения (ключ совпадения) извлеченного правила обработки с содержимым принятого пакета (информацией заголовка, сравниваемой с правилом совпадения (ключом совпадения)).
В данном случае, также, если правило обработки извлекается посредством поиска, используя идентификатор, но если правило совпадения (ключ совпадения) не совпадает с содержимым (информацией заголовка) принятого пакета, не выполняется действие правила обработки. Как и в конфигурации, показанной на фиг. 1, эта конфигурация также предотвращает исполнение непредусмотренного действия, например, когда задерживается установление правила обработки.
(Первый примерный вариант осуществления)
Ниже подробно описывается первый примерный вариант осуществления настоящего изобретения со ссылкой на чертежи. Фиг. 3 представляет собой схему, изображающую конфигурацию системы связи в первом примерном варианте осуществления настоящего изобретения. Как показано на фиг. 3, система связи содержит три узла 10, устройство 20 управления (контроллер) и хосты (А) и (В), которые выполняют связь друг с другом при помощи узлов 10. Хотя три узла 10, устройство 20 управления (контроллер) и два хоста (Хост(А)), Хост(В)) показаны в примере на фиг. 3, может использоваться любое количество узлов, устройств управления (контроллеров) и хостов.
Фиг. 4 представляет собой схему, изображающую подробную конфигурацию устройства 20 управления (контроллера). Как показано на фиг. 4, устройство 20 управления (контроллер) содержит базу 21 данных потоковых элементов (DB потоковых элементов), которая хранит правила обработки (потоковые элементы) и информацию верификации, связанную с правилами обработки; блок 22 управления топологией, который создает информацию сетевой топологии, основываясь на соотношении соединений узлов 10, собранных блоком 26 связи узла; блок 23 вычисления тракта/действия, который вычисляет тракт перенаправления пакета и действие, которое должно быть исполнено узлом 10 в тракте перенаправления, основываясь на информации сетевой топологии, созданной блоком 22 управления топологией; блок 24 управления потоковым элементом, который устанавливает ассоциацию между правилом обработки (потоковым элементом) и информацией верификации, которые вычисляются соответственно блоком 23 вычисления тракта/действия и блоком 28 генерирования информации верификации, регистрирует ассоциированное правило обработки (потоковый элемент) и информацию верификации в DB 21 потоковых элементов, обрабатывает запрос добавления правила обработки (потокового элемента), принятый от узла 10, и обновляет правило обработки (потоковый элемент) и информацию верификации; блок 25 обработки управляющего сообщения; блок 26 связи узла, который выполняет связь с узлом 10; и блок 28 генерирования информации верификации, который, в ответ на запрос от блока 24 управления потоковым элементом, генерирует информацию верификации, которая должны быть ассоциирована с правилом обработки, или извлекает информацию верификации из базы 27 данных информации верификации (DB информации верификации). Информация верификации ссылается на информацию, соответствующую идентификатору, используемому для верификации результата сравнения (совпадает или нет) между принятым пакетом и правилом обработки, основываясь на правиле совпадения.
Кроме того, блок 25 обработки управляющего сообщения содержит блок 251 анализа/обработки сообщения, который анализирует управляющее сообщение, принятое от узла 10, и выполняет необходимую обработку, и блок 252 генерирования сообщения, который генерирует сообщение, которое должно быть передано на узел 10.
Фиг. 5 представляет собой схему, схематически изображающую информацию, удерживаемую в DB 21 потоковых элементов (потоковый элемент и информация верификации). Например, элементы с первого по третий сверху на фиг. 5 указывают правила обработки (потоковые элементы), которые устанавливаются в узлах, DPID (идентификатор узла 10: идентификаторы тракта данных) которых равны 1-3, и информацию верификации, ассоциированную с правилами обработки (Элементы с четвертого по шестой сверху указывают подобное содержимое).
Когда принимается пакет, который совпадает с ключом «А» совпадения, узел, DPID которого равен 1 (например, узел #1 на фиг. 3), выполняет обработку, указанную первым элементом сверху. Т.е. узел добавляет заголовок, который включает в себя информацию «CA» верификации, к пакету и выводит пакет с девятого порта в соответствии с полем Действия (Действия). Аналогично, когда пакет, который совпадает с ключом «А» совпадения, принимается от узла, DPID которого равен 1 (например, узел #1 на фиг. 3), узел, DPID которого равен 2 (например, узел #2 на фиг. 3), выводит пакет с шестого порта. Когда пакет, который совпадает с ключом «А» совпадения, принимается от узла, DPID которого равен 2 (например, узел #2 на фиг. 3), узел, DPID которого равен 3 (например, узел #3 на фиг. 3), удаляет заголовок, который включает в себя информацию «CA» верификации, из пакета и выводит пакет с первого порта. В результате вышеприведенной обработки тракт перенаправления управляется таким образом, что информация «CA» верификации добавляется к пакету, который совпадает с ключом «A» совпадения, и пакет перенаправляется по заданному тракту, во время которого информация «CA» верификации используется для сопоставления. В фактической DB 21 потоковых элементов каждый из ключей «A», «B» и «X» совпадения, показанных на фиг. 5, состоит из правила (FlowKey; может использоваться специальный символ), с которым сравнивается заголовок принятого пакета, например, тот, который показан на фиг. 30.
Фиг. 6 представляет собой схему, схематически изображающую информацию (информацию верификации), удерживаемую в DB 27 информации верификации. Как показано на фиг. 6, DB 27 информации верификации хранит соответствие между ключами «A», «B», …, «X» совпадения и информацией «CA», «CB», … , «CX» верификации. Блок 28 генерирования информации верификации генерирует информацию верификации, соответствующую правилу обработки (потоковому элементу), в ответ на запрос от блока 24 управления потоковым элементом и регистрирует сгенерированную информацию верификации в DB 27 информации верификации. Такая информация верификации может генерироваться заданной функцией (хеш-функцией и т.д.), которая использует правило совпадения (ниже в данном документе называемое «ключом совпадения») или другую информацию в качестве аргумента (параметра) таким образом, что информация верификации является уникальной по меньшей мере среди многочисленных правил обработки, причем каждое соответствует многочисленным правилам совпадения, которое согласуется с принятым пакетом, т.е. таким образом, что одна и та же информация верификации не назначается по меньшей мере многочисленным правилам обработки. Статистически уникальная информация верификации также может генерироваться с использованием случайных чисел (Ниже подробно описывается пример). DB 27 информации верификации, обеспечиваемая для предотвращения дублирования информации верификации среди многочисленных правил обработки (потоковых элементов), которая может конфликтовать друг с другом, не всегда должна иметь формат, показанный на фиг. 6. Кроме того, DB 27 информации верификации может быть исключена посредством предотвращения дублирования информации верификации стохастически или статистически.
Следует отметить, что, если нет необходимости удерживать правило обработки (потоковый элемент), что устройство 20 управления (контроллер) инструктирует узел 10 на добавление или обновление, а также информацию верификации, ассоциированную с правилом обработки, может быть исключена DB 21 потоковых элементов. Аналогично, если нет необходимости удерживать информацию верификации, генерируемую в ассоциации с правилом обработки, может быть исключена DB 27 информации верификации. Кроме того, также возможна другая конфигурация, в которой DB 21 потоковых элементов и/или DB 27 информации верификации обеспечивается отдельно на внешнем сервере.
Устройство 20 управления (контроллер), описанное выше, может быть реализовано посредством добавления по меньшей мере следующих двух к контроллеру OpenFlow, описанному в непатентной литературе 1 и 2. Одним является блок 28 генерирования информации верификации, и другим – функция для установления правила обработки (потокового элемента) и информации верификации, ассоциированной с правилом обработки в узле 10.
Фиг. 7 представляет собой схему, изображающую подробную конфигурацию узла 10. Как показано на фиг. 7, узел 10 содержит блок 11 связи устройства управления, который выполняет связь с устройством 20 управления (контроллером), блок 12 управления потоковой таблицей, который управляет потоковой таблицей 13, пакетный буфер 14 и блок 15 обработки перенаправления. Следует отметить, что узел 10 не всегда должен содержать пакетный буфер 14.
Блок 15 обработки перенаправления содержит блок 153 табличного поиска и блок 154 исполнения действия. Блок 153 табличного поиска включает в себя блок 152 сопоставления информации верификации, который сравнивает информацию верификации, ассоциированную с правилом обработки (потоковым элементом), с информацией верификации, добавленной к принятому пакету, для определения, совпадают ли они. Блок 153 табличного поиска выполняет поиск в потоковой таблице 13 правила обработки (потокового элемента), которое имеет ключ совпадения, который согласуется с принятым пакетом, и информация верификации которого совпадает с информацией принятого пакета, и выводит содержимое (действие) обработки на блок 154 исполнения действия. Блок 154 исполнения действия исполняет содержимое (действие) обработки, выводимое из блока 153 табличного поиска.
Узел 10, описанный выше, может быть реализован посредством добавления блока 152 сопоставления информации верификации к коммутатору OpenFlow и посредством конфигурирования потоковой таблицы 13, так что информация верификации может удерживаться в ассоциации с правилом обработки (потоковым элементом). Блок 153 табличного поиска (потокового элемента), который включает в себя блок 152 сопоставления информации верификации, узла 10 может конфигурироваться программой, исполняемой компьютером, конфигурирующим узел 10.
Фиг. 8 представляет собой схему, схематически изображающую информацию (потоковый элемент и информацию верификации), удерживаемую в потоковой таблице 13 узла по фиг. 5 (узел #2 на фиг. 3), DPID которого равен 2. Как показано на фиг. 8, потоковая таблица 13 включает в себя потоковые элементы и информацию верификации, которые являются теми же, что и элементы в DB 21 потоковых элементов на фиг. 5 с соответствующим DPID. Для каждого из узлов на фиг. 5, DPID которого равен 1 или 3 (узлы #1 или #3), потоковая таблица 13 включает в себя потоковые элементы и информацию верификации, соответствующую каждому DPID аналогичным образом.
Фиг. 9 представляет собой схему, изображающую конфигурацию пакета с добавленной информацией верификации, созданного узлом 10, основываясь на действии («Установить заголовок», включающее в себя «CA»; см. действие (Действия) узла с DPID=1 на фиг. 5), которое устанавливается устройством 20 управления (контроллером). В примере на фиг. 9 пакет 32 с добавленной информацией верификации имеет конфигурацию, в которой дополнительный заголовок 33 с добавленной информацией верификации, который включает в себя информацию верификации, добавляется к началу пользовательского пакета 31.
Фиг. 10 представляет собой схему, изображающую пример конфигурации дополнительного заголовка 33 с добавленной информацией верификации. В примере на фиг. 10 дополнительный заголовок 33 с добавленной информацией верификации имеет конфигурацию, в которой информация верификации добавляется к адресу назначения управления доступом к среде передачи (DA MAC), адресу источника MAC (SA MAC), типу протокола более высокого уровня (типу среды) и общей длине заголовка (Общая длина). В примере на фиг. 10 значение (f(ключ совпадения, случайное число), вычисленное заданной функцией (хэш-функцией и т.д.) с ключом совпадения и случайным числом в качестве аргумента, используется в качестве информации верификации.
Далее, нижеследующее описывает работу устройства 20 управления (контроллера) и узла 10, описанного выше. Фиг. 11 представляет собой блок-схему последовательности операций, изображающую работу устройства 20 управления (контроллера). Как показано на фиг. 11, когда запрос (запрос на создание правила обработки; см. этап S111 на фиг. 12) принимается от узла 10 (этап S001; Packet-In), устройство 20 управления (контроллер) проверяет, включает ли в себя пакет запроса информацию верификации (этап S002). Если пакет запроса включает в себя информацию верификации (Да на этапе S002), правило обработки, соответствующее пакету, уже создано и, поэтому, устройство 20 управления (контроллер) извлекает правило обработки, соответствующее пакету, и информацию верификации, ассоциированную с правилом обработки, из DB 21 потоковых элементов (этап S012) и передает управление на этап S008.
С другой стороны, если пакет запроса не включает в себя информацию верификации (Нет на этапе S002), устройство 20 управления (контроллер) получает информацию сетевой топологии, составленную блоком 22 управления топологией, и вычисляет тракт перенаправления пакета (этап S003).
За исключением того, когда определяется из результата вычисления тракта перенаправления пакета, что пакет не может быть перенаправлен, так как тракт перенаправления не может быть создан, или так как отказал узел в тракте (Нет на этапе D004), устройство 20 управления (контроллер) вычисляет действие, соответствующее вычисленному тракту перенаправления (этап S005). Затем устройство 20 управления (контроллер) генерирует информацию верификации, которая ассоциируется с правилом обработки (потоковым элементом), применяемым к каждому из узлов 10 в тракте (этап S006). Кроме того, устройство 20 управления (контроллер) генерирует правило обработки (потоковый элемент), который применяется к каждому из узлов 10 в тракте, причем правило обработки (потоковый элемент) включает в себя ключ совпадения для идентификации потока, к которому принадлежит пакет запроса, и действие (этап S007).
Когда завершено получение или генерирование правила обработки (потокового элемента) и информации верификации, устройство 20 управления (контроллер) генерирует инструкцию установления (Flow Mod(Add)) для установления сгенерированного правила обработки (потокового элемента) и информации верификации (этап S008) и передает инструкцию установления (Flow Mod(Add)) для установления правила обработки (потокового элемента) и информации верификации на узлы 10 в тракте перенаправления пакета, созданном правилом обработки (потоковым элементом) (этап S009).
После этого, если узел 10 не буферизовал пакет (Нет на этапе S010), устройство 20 управления (контроллер) передает инструкцию вывода пакета (Packet-Out) (этап S011). Эта инструкция вывода пакета выполняется посредством задания пакета, который должен быть выведен (пакета, принятого посредством Packet-In на этапе S001), и действия, которое должно быть исполнено для пакета (добавление информации верификации и вывод пакета с заданного порта) или посредством задания пакета, который должен быть выведен (пакета, принятого посредством Packet-In на этапе S001), и действия, которое должно быть исполнено для пакета (поиск по потоковой таблице). Следует отметить, что, если узел 10 буферизовал пакет (Да на этапе S010), устройство 20 управления (контроллер) может побуждать узел 10 к выводу пакета, как описано ниже, и, поэтому, устройство 20 управления (контроллер) опускает эту обработку.
Фиг. 12 представляет собой блок-схему последовательности операций, изображающую работу узла 10. Как показано на фиг. 12, когда пакет принимается от хоста или другого узла 10 (этап S101), узел 10 выполняет поиск в потоковой таблице 13 правила обработки (потокового элемента), имеющего ключ совпадения, который согласуется с принятым пакетом (этап S102).
Если правило обработки (потоковый элемент) извлекается на этапе S102 (Да на этапе S103), узел 10 проверяет, включает ли в себя принятый пакет информацию верификации (этап S104). В данном примерном варианте осуществления узел 10 проверяет, имеет ли принятый пакет дополнительный заголовок, чтобы посмотреть, включена ли информация верификации.
Если принятый пакет не включает в себя информацию верификации, узел 10 исполняет действие, описанное в извлеченном правиле обработки (потоковом элементе) (этап S107).
С другой стороны, если определяется на этапе S104, что принятый пакет включает в себя информацию верификации, узел 10 сравнивает информацию верификации, включенную в принятый пакет, с информацией верификации, ассоциированной с извлеченным правилом обработки (потоковым элементом) (этап S105).
Если две порции информации верификации совпадают, узел 10 исполняет действие, описанное в извлеченном правиле обработки (потоковом элементе) (этап S107). Т.е. чтобы исполнить действие для пакета, который включает в себя информацию верификации, необходимо, чтобы совпадающее правило обработки (потоковый элемент) было найдено во время поиска с использованием ключа совпадения, и чтобы информация верификации, ассоциированная с правилом обработки (потоковым элементом), совпадала с информацией, включенной в принятый пакет.
С другой стороны, если правило обработки (потоковый элемент), которое согласуется с принятым пакетом, не находится на этапе S103, или если правило обработки (потоковый элемент), которое согласуется с принятым пакетом, находится, но две порции информации верификации не совпадают, узел 10 передает управление на этап S111 без исполнения действия, описанного в извлеченном правиле обработки (потоковом элементе) и передает запрос на устройство 20 управления (контроллер) (запрос на создание и передачу правила обработки (потокового элемента) и информации верификации, соответствующей принятому пакету).
На этапе S111 узел 10 сохраняет принятый пакет в пакетном буфере 14 и одновременно передает принятый пакет на устройство 20 управления (контроллер), запрашивая его создать правило обработки и информацию верификации. После этого, в ответ на этот запрос, устройство 20 управления (контроллер) создает и устанавливает правило обработки и информацию верификации в соответствии с процедурой, показанной на фиг. 11.
Когда инструкция установления (Flow Mod(ADD)) для установления правила обработки (потокового элемента) и информации верификации принимается от устройства 20 управления (контроллера), узел 10 устанавливает правило обработки (потоковый элемент) и информацию верификации, ассоциированную с правилом обработки, в его собственной потоковой таблице 13 в соответствии с Flow Mod(Add) (этап S112).
Затем узел 10 проверяет, сохранен ли принятый пакет в пакетном буфере 14 (этап S113). Если принятый пакет сохранен (Да на этапе S113), узел 10 считывает принятый пакет (этап S114) и исполняет содержимое обработки (действие; добавление информации верификации и вывод принятого пакета с заданного порта), определенное правилом обработки (потоковым элементом), которое было установлено, как описано выше (этап S107). Это побуждает перенаправление принятого пакета на узел следующего сегмента (транзитного участка).
С другой стороны, если узел 10 не удерживает пользовательский пакет, например, когда узел 10 не имеет пакетный буфер 14 (Нет на этапе S113), узел 10 принимает инструкцию вывода пакета (Packet-Out) от устройства 20 управления (контроллера) (этап S116).
Если пакетный буфер 14 предусмотрен, узел 10, который принял инструкцию вывода пакета (Packet-Out) проверяет, сохранен ли пакет в пакетном буфере 14 (этап S117). Если пакет сохранен (Да на этапе S117), узел 10 считывает пакет (этап S118) и исполняет содержимое обработки (действие; в данном случае добавление информации верификации к принятому пакету, вывод принятого пакета с заданного порта или поиск по потоковой таблице), принятое с инструкцией вывода пакета (Packet-Out) (этап S107). Если пакет не сохранен (Нет на этапе S117), узел 10 исполняет содержимое обработки (действие; в данном случае, добавление информации верификации к пакету и вывод пакета с заданного порта, или поиск по потоковой таблице), принятое с инструкцией вывода пакета (Packet-Out) для пакета, принятого с инструкцией вывода пакета (Packet-Out) (этап S107). Это побуждает перенаправление принятого пакета на узел следующего сегмента.
Фиг. 13 и 14 представляют собой типовую схему и диаграмму последовательности, изображающие последовательность потока от момента времени, при котором узел #1, который принял пакет, который должен быть передан от хоста (A) на хост (B), передает запрос (запрос на создание правила обработки и информации верификации) на устройство 20 управления (контроллер), до момента времени, при котором пакет доставляется на хост (B).
Как показано на фиг. 13 и 14, когда хост (A) передает пользовательский пакет, который должен быть передан на хост (B), на узел #1 (ST1; Пользовательский пакет на фиг. 13 и 14), узел #1 выполняет поиск (потокового элемента) в потоковой таблице 13 и, в результате, определяет, что пакет представляет собой неизвестный пакет, который не имеет правила обработки (потокового элемента), совпадающего с принятым пакетом (Нет на этапе S103 на фиг. 12). Узел #1 передает запрос (запрос на создание правила обработки (потокового элемента) и информации верификации) на устройство 20 управления (контроллер) (ST2; Packet-In на фиг. 13 и 14).
Когда будет принят запрос (запрос на создание правила обработки (потокового элемента) и информации верификации), устройство 20 управления (контроллер) создает правило обработки (потоковый элемент) и информацию (CA) верификации для установления в узлах #1-#3 в тракте перенаправления этого пакета в соответствии с блок-схемой последовательности операций на фиг. 11 и передает их на узлы #1-#3 (ST3-1–ST5-1; Flow Mod(Add) с CA на фиг. 13 и 14).
Каждый из узлов #1-#3 добавляет правило обработки (потоковый элемент) и информацию (CA) верификации, переданную с устройства 20 управления (контроллера), к потоковой таблице 13 своего собственного устройства и, если добавлен буферный идентификатор (ID), исполняет действие для пакета (ST3-2–ST5-2 на фиг. 13 и 14). В описании ниже изобретатели предполагают, что правило обработки (потоковый элемент) и информация (CA) верификации, переданные в ST4-1 на фиг. 13 и 14, не достигают узла #2 по некоторой причине, и, поэтому, правило обработки (потоковый элемент) и информация (CA) верификации не добавлены к потоковой таблице 13 узла #2.
И затем, узел #1 генерирует пользовательский пакет, к которому добавляется дополнительный заголовок, включающий в себя информацию (CA) верификации (см. фиг. 9), и выводит сгенерированный пакет с заданного порта (порта, подсоединенного к узлу #2) в соответствии с действием (См. действие (Действия) в элементе на фиг. 5, соответствующем DPID=1, ключ совпадения = A, и информация верификации = CA), включенным в правило обработки, принятое в ST3-1 (ST6 на фиг. 13 и 14).
Когда принимается пользовательский пакет, к которому добавляется заголовок, включающий в себя информацию (CA) верификации, узел #2 выполняет поиск в потоковой таблице 13, и, в результате, определяет, что нет правила обработки (потокового элемента), совпадающего с принятым пакетом, или что есть правило обработки (потоковый элемент), совпадающее с принятым пакетом, но информация верификации не совпадает с информацией верификации принятого пакета (Нет на этапе S103 или Нет на этапе 106 на фиг. 12). Узел #2 передает запрос (запрос на создание правила обработки (потокового элемента) и информации верификации) на устройство 20 управления (контроллер) (ST8; Packet-In на фиг. 13 и 14).
Когда принят запрос (запрос на создание правила обработки (потокового элемента) и информации верификации), устройство 20 управления (контроллер) получает правило обработки (потоковый элемент) и информацию (CA) верификации, которые должны быть установлены в узле #2 в тракте пакета (этап S012 на фиг. 11) и передает их на узел #2 в соответствии с блоком-схемой последовательности операций на фиг. 11 (ST9; Flow Mod(Add) с CA на фиг. 13 и 14).
Узел #2 добавляет правило обработки (потоковый элемент) и информацию верификации, переданную с устройства 20 управления (контроллера), к потоковой таблице 13 своего собственного устройства и, если добавлен буферный ID, исполняет действие (ST10 на фиг. 13 и 14).
И затем, узел #2 выводит пользовательский пакет, к которому добавлен дополнительный заголовок, включающий в себя информацию (CA) верификации, с заданного порта (порта, подсоединенного к узлу #3) в соответствии с действием (См. действие (Действия) в элементе на фиг. 5, соответствующем DPID=2, ключ совпадения = A, и информация верификации = CA) в правиле обработки, принятом в ST10 (ST11 на фиг. 13 и 14).
Когда принимается пользовательский пакет, к которому добавлен дополнительный заголовок, включающий в себя информацию (CA) верификации, узел #3 выполняет поиск в потоковой таблице 13, и, в результате, определяет, что одно из правил обработки (потоковых элементов) согласуется с принятым пакетом, и информация верификации также совпадает с информацией верификации принятого пакета (Да на этапе S103 и Да на этапе 106 на фиг. 12) и исполняет действие, определенное в извлеченном и подтвержденном правиле обработки (потоковом элементе) (ST12 на фиг. 13 и 14).
Более конкретно, узел #3 удаляет дополнительный заголовок, включающий в себя информацию (CA) верификации, из пользовательского пакета и выводит пакет с заданного порта (порта, подсоединенного к хосту (B)) в соответствии с действием (См. действие (Действия) в элементе на фиг. 5, соответствующем DPID=3, ключ совпадения = A, и информация верификации = CA) в правиле обработки (потоковом элементе), извлеченном и подтвержденном в ST12 (ST13 на фиг. 13 и 14).
Как описано выше, действие исполняется в данном примерном варианте осуществления при условии, что не только ключ совпадения правила обработки (потокового элемента) совпадает с информацией заголовка принятого пакета, но также информация верификации, отдельно генерируемая устройством 20 управления (контроллером), совпадает с информацией верификации принятого пакета. Таким образом, этот примерный вариант осуществления может предотвратить состояние, описанное в начале данного описания изобретения, когда исполняется непредусмотренное действие, заданное в правиле обработки (потоковом элементе).
В данном примерном варианте осуществления, если определяется на этапе S104, что информация верификации не включена в принятый пакет, действие исполняется без сравнения информации верификации, рассматривая пакет, к которому не должна добавляться информация верификации. Вместо этого, также возможно всегда предотвращать исполнение действия, если информация верификации не включена в принятый пакет.
(Второй примерный вариант осуществления)
Далее нижеследующее подробно описывает второй примерный вариант осуществления настоящего изобретения со ссылкой на чертежи. Хотя информация верификации добавляется к пакету, используя дополнительный заголовок, который включает в себя информацию верификации в первом примерном варианте осуществления настоящего изобретения, описанным выше, информация верификации также может быть включена в пакет без использования дополнительного заголовка. Нижеследующее описывает второй примерный вариант осуществления, в котором информация верификации включается в пакет без использования дополнительного заголовка. Так как базовая конфигурация узла 10 и устройства 20 управления (контроллера) во втором примерном варианте осуществления аналогична базовой конфигурации узла 10 и устройства 20 управления (контроллера) в первом примерном варианте осуществления, нижеследующее описывает конфигурацию, придавая особое значение различию.
Фиг. 15 представляет собой схему, схематически изображающую информацию (потоковые элементы), удерживаемую в DB 21 потоковых элементов устройства 20 управления (контроллера) в данном примерном варианте осуществления. Данный примерный вариант осуществления отличается от первого примерного варианта осуществления тем, что независимое поле информации верификации не включено в DB 21 потоковых элементов, но ключ совпадения, который включает в себя информацию (CA) верификации, сохраняется в поле ключа совпадения потокового элемента, и что обработка для записи информации верификации в (или восстановление) поле DA MAC определяется как действие (более строго, замена поля DA MAC значением Dn’ (см. фиг. 19) и восстановление поля DA MAC). В описании ниже значение исходного поля DA MAC указывается как «Dn», и значение поля DA MAC, преобразованное так, чтобы включать в себя информацию (CA) верификации, указано как «Dn’».
Например, когда принимается пакет, который совпадает с ключом «A» совпадения, узел на фиг. 15, DPID которого равен 1 (например, узел #1 на фиг. 3), устанавливает значение D1’, которое включает в себя информацию (CA) верификации в поле DA MAC пакета в соответствии с полем действия (Действия) и затем выводит пакет с девятого порта. Когда пакет (пакет, который совпадает с ключом A’ совпадения), поле DA MAC которого включает в себя информацию (CA) верификации, принимается от узла, DPID которого равен 1 (например, узла #1 на фиг. 3), узел, DPID которого равен 2 (например, узел #2 на фиг. 3), выводит пакет с шестого порта. Когда пакет (пакет, который совпадает с ключом A’ совпадения), поле DA MAC которого включает в себя информацию (CA) верификации, принимается от узла, DPID которого равен 2 (например, узла #2 на фиг. 3), узел, DPID которого равен 3 (например, узел #3 на фиг. 3), восстанавливает поле DA MAC до того же содержимого (D1), что и содержимое DA MAC исходного принятого пакета, и затем выводит пакет с первого порта. В результате вышеупомянутой обработки тракт перенаправления управляется таким образом, что информация «CA» верификации добавляется узлом первого сегмента в тракте перенаправления, и пакет перенаправляется по заданному тракту, во время которого информация «CA» верификации используется для сопоставления.
Фиг. 16 представляет собой схему, схематически изображающую информацию (информацию верификации), удерживаемую в DB 27 информации верификации устройства 20 управления (контроллера) в данном примерном варианте осуществления. Информация отличается от информации в первом примерном варианте осуществления тем, что добавляется содержимое исходного поля DA MAC (соответствующего D1, D2 и DX на фиг. 15) для восстановления поля DA MAC до того же содержимого, что и содержимое DA MAC исходного принятого пакета, а также номер последнего сегмента для выполнения обработки восстановления.
Фиг. 17 представляет собой схему, изображающую подробную конфигурацию узла 10а в данном примерном варианте осуществления. Конфигурация отличается от конфигурации на фиг. 7, которая изображает конфигурацию узла 10 в первом примерном варианте осуществления, тем, что блок 152a сопоставления информации верификации, блок 153a табличного поиска и блок 15a обработки перенаправления заменяют соответствующие блоки, так как информация верификации, а также операция сравнения блока 152a сопоставления информации верификации, различается в двух примерных вариантах осуществления (Подробности описаны ниже).
Фиг. 18 представляет собой схему, схематически изображающую информацию (потоковые элементы), удерживаемую в потоковой таблице 13 узла на фиг. 15, DPID которого равен 2 (узел #2 на фиг. 3). Как показано на фиг. 18, потоковые элементы соответствующих DPID, извлеченных из DB 21 потоковых элементов на фиг. 15, устанавливаются в потоковой таблице 13. В узлах, DPID которых равны 1 и 3 на фиг. 15 (узлы #1 и #3 на фиг. 3), подобно устанавливаются потоковые элементы, соответствующие каждому из DPID.
1
2
Фиг. 19 представляет собой схему, изображающую конфигурацию пакета, переписанного узлом 10, основываясь на действии (Установить DA MAC на D1’; см. действие (Действия) узла, в узле которого DPID=1 на фиг. 15), которое устанавливается устройством 20 управления (контроллером). В примере на фиг. 19, пакет 32a с добавленной информацией верификации имеет конфигурацию, в которой 48-битовая информация, показанная снизу фиг. 19, записывается в поле DA MAC пользовательского пакета 31. Хотя 8-битовые фиксированные данные, указывающие, что информация верификации включена, функция f (DPID узла последнего сегмента, исходный DA MAC) и функция f (ключ совпадения, случайное число) записываются в примере на фиг. 19, эта конфигурация является только примерной. Поле для хранения информации верификации, содержимое информации верификации и функции для уменьшения исходных данных могут изменяться по необходимости.
Далее, нижеследующее описывает работу данного примерного варианта осуществления. Фиг. 20 представляет собой блок-схему последовательности операций, описывающую работу устройства управления (контроллера) во втором примерном варианте осуществления настоящего изобретения. Работа, показанная на данной фигуре, отличается от работы на фиг. 11, которая изображает работу устройства управления (контроллера) в первом примерном варианте осуществления, в том, что, когда устройство управления проверяет, включена ли информация верификации в пакет запроса на этапе S002a, устройство управления проверяет не дополнительный заголовок, но записаны ли вышеописанные фиксированные данные (см. фиг. 19) в DA MAC. Другие этапы подобны этапам в первом примерном варианте осуществления и, поэтому, описание здесь опускается.
Фиг. 21 представляет собой блок-схему последовательности операций, изображающую работу узла 10a во втором примерном варианте осуществления настоящего изобретения. Работа отличается от работы на фиг. 12, которая изображает работу узла 10 в первом примерном варианте осуществления, тем, что, когда узел проверяет, включена ли информация верификации в принятый пакет на этапе S104a, узел проверяет, не дополнительный заголовок, но записаны ли вышеописанные фиксированные данные (см. фиг. 19) в DA MAC, и что узел последнего сегмента не удаляет дополнительный заголовок, но восстанавливает исходное поле DA MAC в соответствии с действием, за которым следует перенаправление пакета. Другие этапы аналогичны этапам в первом примерном варианте осуществления и, поэтому, описание здесь опускается.
Как описано выше, настоящее изобретение может быть реализовано в режиме, в котором информация верификации включается в конкретное поле существующего пакета.
(Третий примерный вариант осуществления)
Далее, нижеследующее подробно описывает третий примерный вариант осуществления настоящего изобретения со ссылкой на чертежи. Хотя одна и та же информация верификации сохраняется в узлах посредством ассоциирования информации верификации с потоковым элементом потоковой таблицы в первом примерном варианте осуществления настоящего изобретения, также возможна другая конфигурация, в которой узлы используют разную информацию верификации для сравнения. Нижеследующее описывает третий примерный вариант осуществления, в котором узлы используют разную информацию верификации для сравнения. Так как базовая конфигурация узла 10 и устройства 20 управления (контроллера) в третьем примерном варианте осуществления подобна конфигурации узла 10 и устройства 20 управления (контроллера) в первом примерном варианте осуществления, нижеследующее описывает конфигурацию, придавая особое значение различию.
Фиг. 22 представляет собой схему, схематически изображающую информацию (потоковый элемент и информацию верификации), удерживаемую в DB 21 потоковых элементов устройства 20 управления (контроллера) в данном примерном варианте осуществления. Отличие от первого примерного варианта осуществления заключается в том, что выполняется обработка генерирования информации верификации (этап S006 на фиг. 11) для узлов, один раз для каждого узла, и что, вместо обеспечения независимого поля информации верификации в DB 21 потоковых элементов, обработка добавляется к полю действия для добавления дополнительного заголовка, который включает в себя другую информацию верификации. (Заголовок, который включает в себя другую информацию верификации, добавляется к каждому узлу и, поэтому, информация верификации, ассоциированная с потоковым элементом, описывается в потоковом элементе. Это означает, что поле информации верификации не является обязательным, так как нет необходимости независимо поддерживать соответствие между информацией верификации и потоковыми элементами).
Например, когда принимается пакет, который совпадает с ключом «A1» совпадения, узел на фиг. 22, DPID которого равен 1 (например, узел #1 на фиг. 3), добавляет дополнительный заголовок, который хранит информацию (C2A) верификации, к принятому пакету и выводит пакет с девятого порта в соответствии с полем действия (Действия). Аналогично, когда пакет (пакет, который совпадает с ключом A2 совпадения), к которому добавляется дополнительный заголовок, хранящий информацию (C2A) верификации, принимается от узла, DPID которого равен 1 (например, узел #1 на фиг. 3), узел, DPID которого равен 2 (например, узел #2 на фиг. 3), переписывает информацию (C2A) верификации дополнительного заголовка информации (C3A) верификации и затем выводит пакет с шестого порта. И, когда пакет (пакет, который совпадает с ключом A3 совпадения), к которому добавляется дополнительный заголовок, хранящий информацию (C3A) верификации, принимается от узла, DPID которого равен 2 (например, узел #2 на фиг. 3), узел, DPID которого равен 3 (например, узел #3 на фиг. 3), удаляет дополнительный заголовок из пакета и затем выводит пакет с первого порта. В результате вышеупомянутой обработки тракт перенаправления на заданном тракте управляется таким образом, что пакет перенаправляется последовательно, начиная с узла первого сегмента в тракте перенаправления, во время которого информация верификации переписывается, и информация верификации используется для сопоставления.
Фиг. 23 представляет собой схему, схематически изображающую информацию (информацию верификации), удерживаемую в DB 27 информации верификации устройства 20 управления (контроллера) в данном примерном варианте осуществления. Отличие от первого примерного варианта осуществления заключается в том, что добавлено поле DPID, и что соотношение между ключом совпадения и информацией верификации сохраняется для каждого узла. Следует отметить, что эта конфигурация является только примерной, и что информация, содержащаяся в DB 27 информации верификации, может изменяться по мере необходимости в зависимости от функции для генерирования информации верификации.
Фиг. 24 представляет собой схему, схематически изображающую информацию (потоковые элементы и информацию верификации), удерживаемую в потоковой таблице 13 узла на фиг. 22, DPID которого равен 2 (узел #2 на фиг. 3). Как показано на фиг. 24, потоковые элементы и информация верификации соответствующих DPID извлекается из DB 21 потоковых элементов на фиг. 22 и устанавливается в потоковой таблице 13. Для каждого из узлов на фиг. 22, DPID которых равны 1 и 3 (узлы #1 и #3 на фиг. 3), устанавливаются соответственно потоковые элементы и информация верификации, соответствующая DPID.
Этот примерный вариант осуществления отличается от первого примерного варианта осуществления только тем, что устройство управления генерирует информацию верификации для каждого узла, и что отличаются действия, исполняемые в узлах. Основная работа является такой же, что и у первого примерного варианта осуществления, и, поэтому, описание опускается (см. фиг. 11 и фиг. 12).
Этот примерный вариант осуществления, в котором каждый узел переписывает информацию верификации в соответствии с действием, включенным в правило обработки, как описано выше, отличается от первого примерного варианта осуществления тем, что потоковые элементы с разными ключами совпадения могут устанавливаться в узлах в тракте для одного потока связи.
(Четвертый примерный вариант осуществления)
Далее, нижеследующее подробно описывает четвертый примерный вариант осуществления настоящего изобретения с ссылкой на чертежи. В четвертом примерном варианте осуществления настоящего изобретения, который представляет собой сочетание второго примерного варианта осуществления и третьего примерного варианта осуществления настоящего изобретения, дополнительный заголовок не используется, и каждый узел использует разную информацию верификации для сравнения. Так как базовая конфигурация узла 10 и устройства 20 управления (контроллера) в четвертом примерном варианте осуществления подобна конфигурации узла 10 и устройства 20 управления (контроллера) в первом–третьем примерных вариантах осуществления, нижеследующее описывает конфигурацию, придавая особое значению различию.
Фиг. 25 представляет собой схему, схематически изображающую информацию (потоковые элементы), удерживаемую в DB 21 потоковых элементов устройства 20 управления (контроллера) в данном примерном варианте осуществления. Этот примерный вариант осуществления отличается от третьего примерного варианта осуществления тем, что поле действия включает в себя не обработку для добавления дополнительного заголовка, включающего в себя разную информацию верификации, но обработку для перезаписи значения поля DA MAC на значение, включающее в себя информацию верификации по каждому узлу и для восстановления значения на последнем сегменте.
Например, когда принимается пакет, который совпадает с ключом «A» совпадения, узел на фиг. 25, DPID которого равен 1 (например, узел #1 на фиг. 3), устанавливает значение D1’, которое включает в себя информацию (C2A) верификации, в поле DA MAC пакета и затем выводит пакет с девятого порта в соответствии с полем действия (Действия). Аналогично, когда пакет (пакет, который совпадает с ключом A’ совпадения), поле DA MAC которого включает в себя информацию (C2A) верификации, принимается от узла, DPID которого равен 1 (например, узел #1 на фиг. 3), узел, DPID которого равен 2 (например, узел #2 на фиг. 3), переписывает поле DA MAC пакета на значение D1’’, которое включает в себя информацию (C3A) верификации, и затем выводит пакет с шестого порта. Когда пакет (пакет, который совпадает с ключом A’’ совпадения), поле DA MAC которого включает в себя информацию (C3A) верификации, принимается от узла, DPID которого равен 2 (например, узел #2 на фиг. 3), узел, DPID которого равен 3 (например, узел #3 на фиг. 3), восстанавливает поле DA MAC до такого же содержимого (D1), что и содержимое DA MAC исходного принятого пакета и затем выводит пакет с первого порта. В результате вышеописанной обработки тракт перенаправления на заданный тракт управляется таким образом, что информация верификации последовательно переписывается, и информация верификации используется для сопоставления на узле первого сегмента тракта перенаправления.
Фиг. 26 представляет собой схему, схематически изображающую информацию (информацию верификации), удерживаемую в DB 27 информации верификации устройства 20 управления (контроллера) в данном примерном варианте осуществления. Информация отличается от информации в третьем примерном варианте осуществления тем, что добавляется содержимое исходного поля DA MAC для восстановления поля DA MAC до такого же содержимого DA MAC исходного принятого пакета (соответствует D1, D2 и DX на фиг. 25) и номера узла последних сегментов, которые исполняют эту обработку восстановления. Следует отметить, что эта конфигурация является только примерной, и что информация, содержащаяся в DB 27 информации верификации, может изменяться по необходимости в зависимости от функции для генерирования информации верификации.
Фиг. 27 представляет собой схему, схематически изображающую информацию (потоковые элементы), удерживаемую в потоковой таблице 13 узла на фиг. 25, DPID которого равен 2 (узел #2 на фиг. 3). Как показано на фиг. 27, потоковые элементы соответствующих DPID извлекаются из DB 21 потоковых элементов на фиг. 25 и устанавливаются в потоковой таблице 13. Для каждого из узлов на фиг. 25, DPID которых равны 1 и 3 (узлы #1 и #3 на фиг. 3), устанавливаются соответственно потоковые элементы, соответствующие DPID.
Этот примерный вариант осуществления отличается от первого примерного варианта осуществления только тем, что устройство управления генерирует информацию верификации для каждого узла, и что отличаются действия, исполняемые в узлах. Основная работа является такой же, что и работа первого примерного варианта осуществления, и, поэтому, описание опускается (см. фиг. 11 и фиг. 12).
Этот примерный вариант осуществления, в котором каждый узел переписывает информацию верификации в соответствии с действием, включенным в правило обработки, как описано выше, отличается от второго примерного варианта осуществления тем, что потоковые элементы с разными ключами совпадения могут устанавливаться в узлах в тракте для одного потока связи.
(Пятый примерный вариант осуществления)
Далее, нижеследующее подробно описывает пятый примерный вариант осуществления настоящего изобретения со ссылкой на чертежи. Хотя только одна порция информации верификации сохраняется в дополнительном заголовке в третьем примерном варианте осуществления настоящего изобретения, описанном выше, также возможна другая конфигурация, в которой информация верификации, которая используется для сравнения узлами в тракте перенаправления, сохраняется в дополнительном заголовке, одна для каждого узла. В данной конфигурации, когда принимается пакет, в который добавляется дополнительный заголовок, узел идентифицирует информацию верификации, на которую узел ссылается для использования при операции сравнения. Нижеследующее описывает пятый примерный вариант осуществления, в котором многочисленные порции информации верификации могут сохраняться в дополнительном заголовке. Так как базовая конфигурация узла 10 и устройства 20 управления (контроллера) в пятом примерном варианте осуществления подобна конфигурации узла 10 и устройства 20 управления (контроллера) в третьем примерном варианте осуществления, описанным выше, нижеследующее описывает конфигурацию, придавая особое значение различию.
Фиг. 28 представляет собой схему, изображающую пример пакета, используемого в пятом примерном варианте осуществления настоящего изобретения. В примере на фиг. 28 пакет 32b с добавленной информацией верификации имеет конфигурацию, в которой дополнительный заголовок 33b с добавленной информацией верификации, который включает в себя информацию верификации, добавляется к началу пользовательского пакета 31.
Фиг. 29 представляет собой схему, изображающую пример конфигурации дополнительного заголовка 33b с добавленной информацией верификации, описанного выше. В примере на фиг. 29 дополнительный заголовок 33b с добавленной информацией верификации содержит адрес назначения MAC (DA MAC), адрес источника MAC (SA MAC), тип протокола более высокого уровня (Тип среды), общую длину заголовка (Общая длина) и многочисленные наборы DPID и информации верификации. В примере на фиг. 29 значение (f (ключ совпадения, случайное число), вычисленное заданной функцией (хеш-функцией и т.д.), которое использует ключ совпадения каждого узла и случайное число в качестве аргументов, используется в качестве информации верификации.
Этот примерный вариант осуществления отличается от первого примерного варианта осуществления только тем, что устройство управления генерирует информацию верификации для каждого узла, и что каждый узел извлекает свою собственную информацию верификации, используя DPID, и исполняет операцию сравнения. Основная работа является такой же, что и работа первого примерного варианта осуществления, и, поэтому, описание опускается (см. фиг. 11 и фиг. 12).
Как описано выше, настоящее изобретение может быть реализовано посредством конфигурации, в которой добавляется дополнительный заголовок, который хранит информацию верификации по индивидуальным узлам. Этот примерный вариант осуществления имеет преимущество относительно третьего примерного варианта осуществления в том, что каждый узел может пропустить обработку для перезаписи информации верификации.
Хотя были описаны предпочтительные примерные варианты осуществления настоящего изобретения, необходимо понять, что настоящее изобретение не ограничивается примерными вариантами осуществления, описанными выше, и что могут быть добавлены дополнительные модификации, замены и корректировки в пределах объема, не выходящего за основную технологическую идею настоящего изобретения. Устройства 20 и 20a управления (контроллеры) в примерных вариантах осуществления, описанных выше, могут быть реализованы посредством выделенного сервера, и узлы 10, 10a и 10b могут быть реализованы коммутатором OpenFlow, описанным выше, а также маршрутизатором в сети протокола Интернета (IP-сети) или коммутатором многопротокольной коммутации на основе меток (MPLS) в MPLS-сети. Кроме того, настоящее изобретение применимо к сети, где сервер полностью управляет узлами в сети.
В пятом примерном варианте осуществления, описанном выше, идентификаторы узла (DPID) включены в дополнительный заголовок, позволяющие каждому узлу идентифицировать информацию верификации, которая должна быть сравнена в устройстве. Также возможно использовать способ, в котором информация верификации используется, начиная с первой или последней информации верификации в дополнительном заголовке, и флаг использования устанавливается для индикации, что информация верификации уже используется, или способ, в котором каждый узел последовательно удаляет из дополнительного заголовка информацию верификации, которую он использует для сравнения.
Хотя узел последнего сегмента удаляет дополнительный заголовок, или восстанавливает поле DA MAC, в примерных вариантах осуществления, описанных выше, также возможна другая конфигурация, в которой хост выполняет эту обработку.
В качестве информации верификации, описанной в примерных вариантах осуществления, описанных выше, также может использоваться информация, генерируемая контроллером, позволяющая потоковому элементу идентифицироваться однозначно, такая как потоковый куки-файл в непатентной литературе 2.
Хотя устройство 20 управления содержит блок 28 генерирования информации верификации в примерных вариантах осуществления, описанных выше, также возможна конфигурация, в которой блок генерирования информации верификации генерируется в каждом узле, если каждый узел 10 может создавать информацию верификации посредством установления синхронизации среди узлов 10 или между узлом 10 и устройством 20 управления, или посредством назначения функции генерирования информации верификации и ее аргументов каждому узлу 10.
Наконец, нижеследующее суммирует предпочтительные режимы настоящего изобретения.
(Первый режим)
(См. систему связи в первом аспекте выше)
(Второй режим)
Система связи, описанная в первом режиме, в которой
используется идентификатор для верификации результата совпадения между принятым пакетом и правилом обработки, причем результат совпадения основан на правиле совпадения.
(Третий режим)
Система связи, описанная в первом или втором режиме, в которой
узел выполняет поиск правила обработки, соответствующего правилу совпадения, которое согласуется с принятым пакетом, посредством сравнения (совпадения) принятого пакета с правилом совпадения, и, если идентификатор принятого пакета соответствует идентификатору, ассоциированному с поисковым правилом обработки, выполняет обработку для принятого пакета в соответствии с поисковым правилом обработки.
(Четвертый режим)
Система связи, описанная в первом или втором режиме, в которой
узел выполняет поиск правила обработки, ассоциированного с идентификатором, соответствующим идентификатору принятого пакета, и, если правило совпадения, соответствующее правилу обработки, согласуется с принятым пакетом, выполняет обработку для принятого пакета в соответствии с поисковым правилом обработки.
(Пятый режим)
Система связи, описанная в одном из первого–четвертого режимов, в которой
идентификатор является уникальным по меньшей мере среди множества правил обработки, причем каждый соответствует множеству правил совпадения, которое согласуется с принятым пакетом.
(Шестой режим)
Система связи, описанная в одном из первого-четвертого режимов, в которой
идентификатор является уникальным статистически.
(Седьмой режим)
Система связи, описанная в одном из первого-шестого режимов, в которой
узел определяет, включает ли принятый пакет идентификатор принятого пакета посредством проверки, добавляется ли дополнительный заголовок, в котором хранится идентификатор, к принятому пакету.
(Восьмой режим)
Система связи, описанная в одном из первого-шестого режимов, в которой
узел определяет, включает ли принятый пакет идентификатор принятого пакета посредством проверки, хранится ли идентификатор в заданном поле принятого пакета.
(Девятый режим)
Система связи, описанная в одном из первого-шестого режимов и восьмого режима, в которой
устройство управления управляет каждым узлом таким образом, что узел, расположенный в начале тракта перенаправления пакета, заменяет информацию в заданном поле принятого пакета на информацию, включающую в себя идентификатор, после чего следует перенаправление пакета; и
узел, расположенный в конце тракта перенаправления, восстанавливает информацию в заданном поле принятого пакета до содержимого перед заменой, после чего следует перенаправление пакета.
(Десятый режим)
Система связи, описанная в одном из первого-девятого режимов, в которой
устройство управления устанавливает другой идентификатор в правиле обработки, которое устанавливается в узле в тракте перенаправления пакета, и управляет каждым узлом таким образом, что узел в тракте перенаправления последовательно переписывает идентификатор принятого пакета на идентификатор узла следующего сегмента.
(Одиннадцатый режим)
Система связи, описанная в одном из первого-седьмого режимов и десятого режима, в которой
устройство управления управляет каждым узлом таким образом, что узел, расположенный в начале тракта перенаправления пакета, добавляет дополнительный заголовок, который включает в себя идентификатор, к принятому пакету, после чего следует перенаправление пакета, и узел, расположенный в конце тракта перенаправления, удаляет дополнительный заголовок, после чего следует перенаправление пакета.
(Двенадцатый режим)
Система связи, описанная в одном из седьмого режима и одиннадцатого режима, в которой
дополнительный заголовок хранит множество идентификаторов, причем каждый используется для определения в узле в тракте перенаправления пакета.
(Тринадцатый режим)
(См. режим во втором аспекте выше)
(Четырнадцатый режим)
(См. устройство управления в третьем аспекте выше)
(Пятнадцатый режим)
(См. способ связи в четвертом аспекте выше)
(Шестнадцатый режим)
(См. способ связи в пятом аспекте выше)
(Семнадцатый режим)
(См. программу в шестом аспекте выше)
(Восемнадцатый режим)
(См. программу в седьмом аспекте выше)
Тринадцатый-восемнадцатый режимы, описанные выше, могут быть воплощены во второй-двенадцатый режимы таким же образом, что и первый режим, описанный выше.
Раскрытие непатентной литературы, приведенное выше, включено настоящим по ссылке в данное описание изобретения. Примерные варианты осуществления могут быть изменены и откорректированы в объеме всего раскрытия (включая формулу изобретения) настоящего изобретения и основаны на основной технологической идее. С объемом формулы изобретения настоящего изобретения различные описанные элементы могут быть объединены и выбраны многочисленным образом. Т.е. очевидно, что настоящее изобретение включает в себя различные модификации и изменения, которые могут быть сделаны специалистом в данной области техники согласно всему раскрытию, включая формулу изобретения, и его технологическим идеям.
Список ссылочных позиций
10, 10a, 10b – узел
11 – блок связи устройства управления
12 – блок управления потоковой таблицей
13 – потоковая таблица
14 – пакетный буфер
15, 15a – блок обработки перенаправления
20 – устройство управления
21 – база данных потоковых элементов (DB потоковых элементов)
22 – блок управления топологией
23 – блок вычисления тракта/действия
24 – блок управления потоковым элементом
25 – блок обработки управляющего сообщения
26 – блок связи узла
27 – база данных информации верификации (DB информации верификации)
28 – блок генерирования информации верификации
31 – пользовательский пакет
32, 32a, 32b – пакет с добавленной информацией верификации
33, 33b – дополнительный заголовок с добавленной информацией верификации
152, 152a – блок сопоставления информации верификации
153, 153a – блок табличного поиска
154 – блок исполнения действия
251 – блок анализа/обработки сообщения
252 – блок генерирования сообщения