RU2576473C2 - Сетевая система и способ маршрутизации - Google Patents

Сетевая система и способ маршрутизации Download PDF

Info

Publication number
RU2576473C2
RU2576473C2 RU2013132519/08A RU2013132519A RU2576473C2 RU 2576473 C2 RU2576473 C2 RU 2576473C2 RU 2013132519/08 A RU2013132519/08 A RU 2013132519/08A RU 2013132519 A RU2013132519 A RU 2013132519A RU 2576473 C2 RU2576473 C2 RU 2576473C2
Authority
RU
Russia
Prior art keywords
terminal
switches
received packet
switch
identifier
Prior art date
Application number
RU2013132519/08A
Other languages
English (en)
Other versions
RU2013132519A (ru
Inventor
Масанори ТАКАСИМА
Томохиро КАСЕ
Original Assignee
Нек Корпорейшн
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Нек Корпорейшн filed Critical Нек Корпорейшн
Publication of RU2013132519A publication Critical patent/RU2013132519A/ru
Application granted granted Critical
Publication of RU2576473C2 publication Critical patent/RU2576473C2/ru

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/52—Multiprotocol routers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/70—Virtual switches
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/72—Routing based on the source address
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

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

Description

ОБЛАСТЬ ТЕХНИКИ
Настоящее изобретение относится к сетевой системе. Более конкретно, настоящее изобретение относится к способу маршрутизации для сетевой системы.
УРОВЕНЬ ТЕХНИКИ
Способ управления коммутатором, оконечным устройством (терминалом) и так далее (плоскость пользователя) с внешнего контроллера (плоскость управления) называется архитектурой разделения CU (C:плоскость управления/U:плоскость пользователя). Сеть связи, имеющая конфигурацию, основанную на архитектуре разделения CU, называется сетью связи с разделением CU.
Как пример сети связи с разделением CU предоставлена сеть связи OpenFlow, в которой применен протокол OpenFlow. Протокол OpenFlow реализует сетевую маршрутизацию путем управления коммутатором с контроллера. В настоящем документе сеть связи OpenFlow является лишь одним примером.
[Разъяснение сети связи OpenFlow]
В сети связи OpenFlow контроллер, подобный OFC (контроллеру OpenFlow), управляет функционированием коммутатора подобно OFS (коммутатору OpenFlow), оперируя таблицей потоков коммутатора.
Таблица потоков является таблицей, в которой регистрируют запись, где запись задает заранее заданный объем обработки (действие), который должен быть выполнен над пакетом (передаваемыми данными), который удовлетворяет заранее заданному условию согласования (правилу). Пакет может быть заменен кадром. Группа пакетов, удовлетворяющих правилу, называется потоком.
Правила потока задаются, используя разные сочетания любого или всего из адреса получателя (DA), адреса отправителя (SA), порта получателя (DP) и порта отправителя (SP), включенных в поле заголовка каждого иерархического уровня протокола пакета и могущих быть различимыми. В настоящем документе перечисленные выше адреса включают в себя MAC-адрес (адрес управления доступом к среде передачи) и IP-адрес (адрес протокола Интернет). Дополнительно, информация о входном порте может быть доступна для правила потока.
Действием потока обычно является пересылка пакетов в заранее заданном направлении пересылки. Разумеется, отбрасывание пакета может быть определено как действие потока.
В сети связи OpenFlow обычно при приеме пакета, не имеющего соответствующей записи, коммутатор передает вопрос (запрос записи) относительно данного пакета в контроллер. Обычно коммутатор передает пакет в контроллер как вопрос относительно этого пакета.
В сети связи OpenFlow обычно контроллер соединен с коммутаторами в подчинении контроллера посредством соединения по защищенному каналу. При приеме вопроса относительно пакета от коммутатора под управлением контроллера контроллер вычисляет путь группы пакетов (потока) и регистрирует запись "группа пакетов (поток) пересылается в заранее заданном направлении пересылки" в таблице потоков коммутатора на основании данного пути. Здесь, контроллер передает сообщение управления для регистрации записи в таблицу потоков в коммутатор.
Подробности протокола OpenFlow описаны в непатентной литературе 1 и 2.
СПИСОК ЛИТЕРАТУРЫ
Непатентная литература
[NPL 1] "The OpenFlow Switch Consortium", <http://www.openflowswitch.org/>
[NPL 2] "OpenFlow Switch Specification Version 1.0.0 (WireProtocol0x01) December 31, 2009", <http://www.openflowswitch.org/documents/openflow-spec-vl.0.0.pdf>
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
В технологии OpenFlow способы регистрации записи в таблицу потоков коммутатора разделены на две основные категории: "упреждающего вида" и "реактивного вида".
При "упреждающем виде" контроллер вычисляет путь заранее заданной группы пакетов (потока) "предварительно" (до начала передачи данных) и регистрирует запись в таблице потоков коммутатора. То есть термин "упреждающий вид" в настоящем документе означает "предварительную регистрацию записи", которую контроллер выполняет по своему желанию.
При "реактивном виде", "при приеме вопроса относительно первого пакета (нового пакета, для которого нет соответствующей записи) от коммутатора" контроллер вычисляет путь группы пакетов (потока) и регистрирует запись в таблице потоков данного коммутатора. То есть термин "реактивный вид" в настоящем документе означает "регистрацию записи в реальном времени", которую контроллер выполняет в ответ на вопрос от коммутатора в текущей передаче данных.
В сетях связи OpenFlow, как правило, является в основном используемым "реактивный вид", в котором, при приеме вопроса относительно первого пакета от коммутатора, контроллер регистрирует запись относительно принятого пакета.
Однако в фактическом аппаратном обеспечении (HW), с целью снижения частоты обработки таблицы потоков для решения проблемы производительности, "упреждающий вид" является предпочтительным. К примеру, для того, чтобы сделать контроллер способным обработать первые пакеты, даже когда большой объем первых пакетов достигает контроллера, "упреждающий вид" является более предпочтительным, чем другой. Однако считается, что поскольку число записей становится огромным, если полностью упреждающий вид фактически применяется, реактивный вид частично применяют, чтобы скомпенсировать ограничение числа записей.
Дополнительно, считается, что если упреждающий вид применен, проблему возникновения потоков большого объема, вызываемую вирусом, подобным Nimda, несанкционированного доступа, вызываемого неизвестным пакетом и так далее, можно избежать, поскольку потоки заданы до начала передачи данных.
Таким образом, в сети связи OpenFlow, практический способ для достижения "упреждающего вида" является желательным.
Сетевая система в соответствии с настоящим изобретением включает в себя множество коммутаторов и контроллер. Каждый из множества коммутаторов исполняет при приеме пакета, который удовлетворяет правилу в записи, зарегистрированной в его собственной таблице потоков, операцию, основанную на действии, заданном в данной записи. Контроллер регистрирует запись, в которой идентификатор, уникальный для пути, вычисленного на основании физической топологии сети связи, состоящей из множества коммутаторов, задан в качестве правила, а вывод из заранее заданного выходного порта - в качестве действия, в каждом из множества коммутаторов прежде, чем передача данных начнется среди множества коммутаторов.
В способе маршрутизации в соответствии с настоящим изобретением каждый из множества коммутаторов исполняет при приеме пакета, который удовлетворяет правилу в записи, зарегистрированной в его собственной таблице потоков, операцию, основанную на действии, заданном в данной записи. Контроллер регистрирует запись, в которой идентификатор, уникальный для пути, вычисленного на основании физической топологии сети связи, состоящей из множества коммутаторов, задан в качестве правила, а вывод из заранее заданного выходного порта - в качестве действия, в каждом из множества коммутаторов прежде, чем передача данных начнется среди множества коммутаторов.
Программа в соответствии с настоящим изобретением является программой, предписывающей компьютеру исполнить операции контроллера в упомянутом выше способе маршрутизации. Здесь, программа в соответствии с настоящим изобретением может быть сохранена в запоминающем устройстве и носителе данных.
Это может достичь "упреждающего вида" и решить аппаратную (HW) проблему производительности в сетях связи OpenFlow.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Фиг.1 является изображением, показывающим пример конфигурации сетевой системы в соответствии с настоящим изобретением;
Фиг.2 является изображением для объяснения обработки при обнаружении топологии;
Фиг.3 является изображением для объяснения обработки при обнаружении станций (используя запрос ARP);
Фиг.4 является изображением для объяснения обработки при обнаружении станций (используя отклик ARP);
Фиг.5 является изображением для объяснения обработки при передаче данных после того, как регистрация записи завершена; и
Фиг.6 является изображением для объяснения обработки при вопросе о пакете к контроллеру.
ОПИСАНИЕ ПРИМЕРНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
Настоящее изобретение ориентировано на сети связи с разделением CU. В настоящем документе сеть связи OpenFlow, которая является одной из сетей связи с разделением CU, будет описана в качестве примера. Однако, на самом деле, сети связи с разделением CU не ограничиваются сетями связи OpenFlow.
(Первый примерный вариант осуществления)
Первый примерный вариант осуществления настоящего изобретения будет описан со ссылкой на прилагаемые чертежи.
[Базовая конфигурация]
Как показано на фиг.1, сетевая система в соответствии с настоящим изобретением включает в себя коммутаторы 10 (10-i, i=1 до n: n является числом коммутаторов) и контроллер 20.
Коммутаторы 10 (10-i, i=1 до n) и контроллер 20 составляют сеть связи OpenFlow. Коммутаторы 10 (10-i, i=1 до n) являются узлами в сети связи OpenFlow.
[Коммутатор]
Каждый из коммутаторов 10 (10-i, i=1 до n) содержит таблицу потоков и пересылает пакет на основании записи, зарегистрированной в таблице потоков контроллером 20.
[Контроллер]
Контроллер 20 выполняет обнаружение топологии (конфигурации сетевых соединений), чтобы обнаружить коммутаторы 10 (10-i, i=1 до n), составляющие сеть связи, и вычисляет путь для каждого потока. Таким образом, контроллер 20 узнает идентификационную информацию (ID коммутатора, MAC-адрес и так далее) всех коммутаторов, составляющих сеть связи, и конфигурацию соединений каждого из коммутаторов, и определяет следующий коммутатор каждого коммутатора.
В настоящем документе контроллер 20 сопоставляет ID коммутатора (64 бита) каждого коммутатора с ID узла (16 бит), первоначально заданным посредством взаимно-однозначного соответствия, до начала передачи данных. В настоящем документе число битов является всего лишь одним примером. То есть контроллер 20 назначает ID узла каждому коммутатору. Кроме того, контроллер 20 вычисляет путь между подключаемыми к терминалам краевыми коммутаторами и регистрирует центральную запись (запись ретрансляции) в таблицу потоков каждого из центральных коммутаторов (центр), являющихся передающими коммутаторами на пути, где центральная запись (запись передачи) обозначает "когда заранее заданный ID узла является описанным в, по меньшей мере, части поля информации об адресате принятого пакета, данный принятый пакет должен быть переслан следующему коммутатору (из заранее заданного выходного порта)". То есть центральный коммутатор судит, может ли пересылка или нет быть выполнена на основании ID узла, описанного в поле информации об адресате принятого пакета, ввиду условия соответствия (правила). Очевидно, контроллер 20 может задать другую информацию, описанную в поле информации об адресате принятого пакета, в качестве условия соответствия (правила) вместо ID узла.
В частности, контроллер 20 может фактически зарегистрировать центральную запись в таблице потоков каждого из центральных коммутаторов (Центр), где центральная запись обозначает "(независимо от ID узла), принятый пакет необходимо переслать следующему коммутатору (из заранее заданного выходного порта)". В этом случае центральный коммутатор (Центр) пересылает принятые пакеты следующему коммутатору без условий.
Также, контроллер 20 выполняет обнаружение станций (обнаружение терминалов), чтобы обнаружить терминалы 30 (30-j, j=1 до m: m является числом терминалов), узнает информацию об адресате (MAC-адрес и так далее) для терминалов и конфигурацию соединений и сопоставляет терминал и ID пользователя посредством взаимно-однозначного соответствия. То есть контроллер 20 назначает ID пользователя каждому терминалу. В настоящем документе контроллер 20 обнаруживает краевые коммутаторы, подключенные к терминалам 30 (30-j, j=1 до m).
При этом контроллер 20 регистрирует выходную запись (запись вывода) в таблицу потоков краевого коммутатора, где выходная запись обозначает "когда ID узла данного краевого коммутатора и ID пользователя терминала, находящегося под управлением, описаны в, по меньшей мере, части поля информации об адресате принятого пакета, информация об адресате принятого пакета должна быть восстановлена так, чтобы адресатом был терминал в качестве пункта назначения, а принятый пакет был переслан данному терминалу", до начала передачи данных.
В настоящем документе причина, почему ID пользователя терминала, находящегося под управлением, является условием соответствия (правилом), состоит в том, что может существовать множество терминалов, находящихся под управлением. Кроме того, поскольку сочетание ID узла краевого коммутатора и ID пользователя терминала являются условиями соответствия (правилом), может быть использован ID пользователя, дублированный среди краевых коммутаторов. Однако для каждого терминала под управлением одного и того же краевого коммутатора продублированный ID пользователя не может быть использован.
Кроме того, контроллер 20 регистрирует входную запись (запись ввода) в таблице потоков входного краевого коммутатора (Вход), где входная запись обозначает "при приеме предварительно заданного пакета информации об адресате необходимо использовать как поисковый ключ, ID узла выходного краевого коммутатора (Выход) и ID пользователя терминала-адресата должны быть описаны в, по меньшей мере, части поля информации об адресате принятого пакета, а принятый пакет должен быть переслан следующему коммутатору". В настоящем документе описанный выше "предварительно заданный пакет" может быть заменен на "пакет, который соответствует заранее заданному условию соответствия (правилу)". В настоящем изобретении, поскольку входной краевой коммутатор (Вход), прежде всего, определяет поток, входная запись определяет правило соответствия пакета, подобно обычной OpenFlow, и вышеупомянутое действие по отношению к удовлетворяющему пакету.
[Время осуществления регистрации входной записи]
В частности, два случая, которые являются "до начала передачи данных" (предварительная регистрация) и "когда передача данных фактически выполняется" (регистрация в реальном времени), рассматриваются как время, когда контроллер 20 регистрирует запись в таблицу потоков входного краевого коммутатора.
В случае "до начала передачи данных" (предварительная регистрация) контроллер 20 предварительно определяет терминал (терминал предполагаемого адресата), который является адресатом передачи заранее заданного пакета, до начала передачи данных. Затем, до начала передачи данных, контроллер 20 регистрирует входную запись в таблице потоков краевого коммутатора, который может быть входным краевым коммутатором, где входная запись обозначает "когда принят заранее заданный пакет, информация об адресате должна быть использована как поисковый ключ, ID узла краевого коммутатора, подключенного к терминалу предполагаемого адресата, и ID пользователя терминала предполагаемого адресата должны быть описаны в, по меньшей мере, части поля информации об адресате принятого пакета, и принятый пакет необходимо переслать следующему коммутатору". В настоящем примерном варианте осуществления, этот случай будет описан.
В случае "когда передача данных фактически выполняется" (регистрация в реальном времени), контроллер 20 вычисляет, когда входной краевой коммутатор принимает пакет от терминала источника передачи, и затем контроллер 20 принимает вопрос относительно принятого пакета, путь группы данного принятого пакета (потока). Затем, на основании этого пути, контроллер 20 регистрирует входную запись в таблице потоков входного краевого коммутатора, где входная запись обозначает "когда принят заранее заданный пакет, информация об адресате должна быть использована как поисковый ключ, ID узла краевого коммутатора, подключенного к терминалу предполагаемого адресата, и ID пользователя терминала предполагаемого адресата должны быть описаны в, по меньшей мере, части поля информации об адресате принятого пакета, и данный принятый пакет необходимо переслать следующему коммутатору". Этот случай будет описан во втором примерном варианте осуществления.
[Установление пути]
Кроме того, когда имеется множество коммутаторов, следующих за каждым коммутатором (когда существует множество путей), контроллер 20 задает резервный ID для каждого пути. Поскольку каждый следующий коммутатор существует на каждом пути, каждый следующий коммутатор сопоставляется с каждым резервным ID. Контроллер 20 регистрирует центральную запись в таблице потоков центрального коммутатора (Центр), где центральная запись обозначает "когда (заранее заданный ID узла и) резервный ID описан в, по меньшей мере, части поля информации об адресате принятого пакета, принятый пакет необходимо переслать следующему коммутатору, соответствующему резервному ID". Кроме того, контроллер 20 регистрирует входную запись в таблице потоков входного краевого коммутатора, где входная запись обозначает "когда принят заранее заданный пакет, информация об адресате должна быть использована как поисковый ключ, ID узла выходного краевого коммутатора, резервный ID и ID пользователя терминала-адресата должны быть описаны в, по меньшей мере, части поля информации об адресате принятого пакета, и принятый пакет необходимо переслать следующему коммутатору". Резервный ID может быть частью ID узла выходного краевого коммутатора. К примеру, начальные или заключительные несколько битов поля ID узла могут быть использованы как поле резервного ID.
[Пример аппаратного обеспечения]
Как примеры каждого из коммутаторов 10 (10-i, i=1 до n) могут быть рассмотрены сетевой коммутатор, маршрутизатор, прокси-сервер, шлюз, межсетевой экран, распределитель нагрузки, устройство управления трафиком, SCADA (устройство диспетчерского управления и сбора данных), контроллер шлюза, базовая станция, AP (точка доступа), CS (спутник связи), вычислительное устройство, имеющее множество портов связи, и тому подобное. Кроме того, каждый из коммутаторов 10 (10-i, i=1 до n) может быть виртуальным коммутатором, выполненным на физическом устройстве.
Как примеры каждого из контроллера 20 и терминалов 30 (30-j, j=1 до m) могут предполагаться PC (персональный компьютер), программно-аппаратный комплекс, тонкий клиент терминального сервера, рабочая станция, универсальный компьютер, супер-ЭВМ и тому подобное. Корме того, каждый из контроллера 20 и терминалов 30 (30-j, j=1 до m) может быть виртуальной машиной (VM), выполненной на физическом устройстве.
В частности, каждый из терминалов 30 (30-j, j=1 до m) может быть сотовым телефоном, смартфоном, портативным компьютером, автомобильной навигационной системой, переносным устройством для видеоигр, домашним устройством для видеоигр, переносным музыкальным проигрывателем, портативным терминалом, гаджетом (электронным устройством), интерактивным телевизором, цифровым тюнером, цифровым записывающим устройством, информационным бытовым прибором, устройством OA (автоматизации делопроизводства) или тому подобным. Кроме того, каждый из терминалов 30 (30-j, j=1 до m) может быть предусмотрен на подвижном объекте, таком как наземное транспортное средство, корабль или самолет.
Даже если это не показано в настоящем документе, каждый из коммутаторов 10 (10-i, i=1 до n), контроллера 20 и терминалов 30 (30-j, j=1 до m) реализуется посредством процессора, управляемого на основании программы для исполнения заранее заданной обработки, запоминающего устройства, в котором сохранена данная программа, и различного вида интерфейсов передачи данных и связи для подключения к сети связи.
Как примеры упомянутого выше процессора могут быть рассмотрены: CPU (центральный процессор), микропроцессор, микроконтроллер, IC (интегральная микросхема), имеющая определенные функции, и тому подобное.
Как примеры упомянутого выше запоминающего устройства могут быть рассмотрены: полупроводниковое запоминающее устройство, такое как RAM (Оперативное Запоминающее Устройство), ROM (Постоянное Запоминающее Устройство), EEPROM (Электрически Стираемое и Программируемое Постоянное Запоминающее Устройство) и флэш-память, внешнее запоминающее устройство, такое как HDD (накопитель на жестком диске) и SSD (твердотельный накопитель), съемный диск, такой как DVD (универсальный цифровой диск), носитель информации, такой как карта памяти SD (карта памяти Secure Digital) или тому подобное.
К тому же упомянутый выше процессор и упомянутое выше запоминающее устройство могут быть объединенными. К примеру, в последние годы однокристальная интеграция микрокомпьютера или тому подобного была улучшена. Таким образом, может быть рассмотрен случай, в котором однокристальная микро-ЭВМ, установленная в электронном устройстве, включает в себя процессор и запоминающее устройство.
Как примеры упомянутого выше интерфейса связи могут рассматриваться монтажная плата, отвечающая за передачу данных по сети (материнская плата, I/O плата), полупроводниковая микросхема, такая как интегральная микросхема, сетевой адаптер, такой как NIC (сетевая интерфейсная плата) и сходная карта расширения, устройство связи, такое как антенна, порт связи, такой как коннектор.
Кроме того, как примеры сети связи могут рассматриваться сеть Интернет, LAN (локальная сеть), беспроводная LAN, WAN (глобальная сеть), магистральная сеть, линия кабельного телевидения (CATV), сеть стационарной телефонии, сеть сотовой связи, WiMAX (IEEE 802.16a), 3G (3-е поколение), выделенная линия, IrDA (Ассоциация передачи данных в инфракрасном диапазоне), Bluetooth (зарегистрированный товарный знак), шина последовательного интерфейса, шина данных и тому подобные.
Внутренние составляющие элементы каждого из коммутаторов 10 (10-i, i=1 до n), контроллера 20 и терминалов 30 (30-j, j=1 до m) могут быть модулем, компонентом, специализированным устройством или активируемой (вызываемой) программой соответственно.
Однако вышеприведенные конфигурации не ограничиваются этими примерами, на самом деле.
Со ссылкой на фиг.2 будет описана обработка при обнаружении топологии.
Контроллер 20 обнаруживает физическую топологию сети связи путем использования LLDP (Протокол канального уровня для обнаружения). Протокол LLDP предназначен для сбора аппаратной информации о соседних устройствах путем регулярной посылки и приема управляющих кадров.
Предварительно, управляющий терминал или тому подобный задает внутреннюю/внешнюю конфигурацию (информацию настроек) каждому из коммутаторов 10 (10-i, i=1 до n). Или контроллер 20 устанавливает внутреннюю/внешнюю конфигурацию на каждом из коммутаторов 10 (10-i, i=1 до n), которые находятся под управлением посредством использования подключения по защищенному каналу.
"Внутренняя конфигурация" является информацией настроек для установления связи внутри сети связи. "Внешняя конфигурация" является информацией настроек для установления связи за пределами сети связи.
Каждый из коммутаторов 10 (10-i, i=1 до n) сохраняет внутреннюю/внешнюю конфигурацию как информацию о состоянии (PortStat) порта. По умолчанию, каждый из коммутаторов 10 (10-i, i=1 до n) сохраняет внутреннюю конфигурацию как информацию о состоянии (PortStat) порта.
Поскольку каждый из коммутаторов 10 (10-i, i=1 до n) имеет внутренние/внешние настройки, заданные ранее, контроллер 20 может увеличить скорость обнаружения топологии.
Контроллер 20 обнаруживает топологию, собирает информацию о состоянии (PortStat) портов, включенных в каждый из коммутаторов 10 (10-i, i=1 до n), и судит, какой из портов, включенных в каждый из коммутаторов 10 (10-i, i=1 до n), является внутренним или внешним.
Контроллер 20 распознает порт, который является явно заданным как внутренний в информации о состоянии данного порта, как "внутренний порт". Кроме того, контроллер 20 распознает порт, который является явно заданным как внешний в информации о состоянии данного порта, как "внешний порт".
Контроллер 20 посылает управляющий кадр LLDP порту (не установленному порту или тому подобному), который не задан явно как внутренний порт и внешний порт. Затем, контроллер 20 обнаруживает физическую топологию сети связи на основании отклика на управляющий кадр LLDP и создает информацию о топологии.
В это же время контроллер 20 запрашивает ID коммутатора каждого из коммутаторов 10 (10-i, i=1 до n), находящихся под управлением, и сопоставляет ID коммутатора каждого из коммутаторов 10 (10-i, i=1 до n) с ID узла. На настоящий момент ID коммутатора только для коммутатора (краевого коммутатора), включающего в себя внешний порт, может быть сопоставлен с ID узла. В настоящем документе в качестве ID коммутаторов показаны "DPID: #1 до #6". Фактически, "DPID: #1 до #6" могут быть использованы как ID узлов без изменений.
Кроме того, ID узла включает в себя суб-ID узла и резервный ID. Суб-ID узла является существенной частью ID узла для определения коммутатора. Суб-ID узла может быть идентификационной информацией, способной определить коммутатор самостоятельно. Или суб-ID узла может быть информацией, представляющей собой ID узла, которая способна однозначно определить коммутатор посредством объединения с резервным ID. Резервный ID является идентификационной информацией для определения пути. Каждый из коммутаторов 10 (10-i, i=1 до n) может определить порт для пересылки пакета следующему коммутатору на основании резервного ID и послать принятый пакет в данный порт. Фактически, если взаимозависимость с ID узла поддерживается и может быть указана в качестве резервного ID, то резервный ID может быть сохранен в другом поле.
Контроллер 20 вычисляет путь между коммутаторами (краевыми коммутаторами), включающими в себя внешний порт, и регистрирует центральную запись в таблицу потоков каждого центрального коммутатора (Центр) на данном пути, где центральная запись обозначает "когда заранее заданный ID узла (ID узла краевого коммутатора, включающего в себя внешний порт) является описанным в, по меньшей мере, части поля информации об адресате принятого пакета, данный принятый пакет необходимо переслать следующему коммутатору на данном пути". То есть центральный коммутатор судит, будет ли или нет пакет переслан, используя ID узла, описанный в поле информации об адресате принятого пакета как условие соответствия (правило). Очевидно, контроллер 20 может задать другую информацию (VTNID, ID пользователя и тому подобное), описанную в поле информации об адресате принятого пакета, как условие соответствия (правило).
В частности, контроллер 20 может фактически зарегистрировать центральную запись в таблице потоков каждого из центральных коммутаторов (Центр), где центральная запись обозначает "(независимо от ID узла), принятый пакет необходимо переслать следующему коммутатору (из заранее заданного выходного порта)". В этом случае центральный коммутатор (Центр) перешлет принятый пакет следующему коммутатору без условий. Входной краевой коммутатор (Вход) и выходной краевой коммутатор (Выход) решают, должен или нет принятый пакет быть переадресован.
Здесь, контроллер 20 вычисляет путь между всеми коммутаторами, включающими в себя внешний порт, и регистрирует упомянутую выше центральную запись в таблицу потоков каждого центрального коммутатора (Центр) на пути.
[Конфигурационный пример записи]
Конфигурационный пример записи будет описан ниже.
Запись включает в себя поля хранения данных, такие как "Порт", "DA" (Адрес получателя), "SA" (адрес источника), "OPort" (выходной порт) и "Mod" (модификация).
Поле "Port" является полем хранения информации, обозначающей входной порт принятого пакета. Поле "DA" является полем хранения информации об адресате принятого пакета. Поле "SA" является полем хранения информации об источнике передачи принятого пакета. Поле "OPort" является полем хранения информации, обозначающей выходной порт принятого пакета. Поле "Mod" является полем хранения информации, задающей обработку, выполняемую над принятым пакетом.
Поля "Port", "DA" и "SA" представляют условие соответствия (правило). Кроме того, поля "OPort" и "Mod" представляют обработку содержимого (действие).
"Групповой ID", хранящийся в "DA", является информацией, такой как "ID узла", "VTN ID" и "ID пользователя". Поле "ID узла" является полем хранения идентификационной информации для назначения коммутатора (узла, включающего в себя внешний порт) быть выходным краевым коммутатором. Поле "VTN ID" является полем хранения идентификационной информации о VN (виртуальной сети связи), такой как VTN (Виртуальная Арендуемая Сеть), к которой группа пакетов (поток) проходит путь между коммутаторами, которым принадлежит внешний порт. Поле "ID пользователя" является полем хранения идентификационной информации ID пользователя для назначения терминала (терминал подключен или будет подключен к коммутатору с внешним портом) быть адресатом. Сопоставление терминала с ID пользователя будет выполнено путем применения "обнаружения станций", описанного ниже.
[Обнаружение станций]
Со ссылкой на фиг.3 и 4 обработка в обнаружении станций будет описана.
Контроллер 20 выполняет обнаружение станций, используя управляющий кадр ARP (протокола разрешения адресов), который посылается для разрешения адреса терминалом.
В данном случае управляющий кадр ARP является всего лишь одним примером. К примеру, управляющий кадр DHCP (протокола динамической конфигурации сетевого узла) может быть использован. Кроме того, настоящий примерный вариант осуществления не ограничивается управляющим кадром.
В настоящем документе терминал 30-1 и терминал 30-2 предполагаются являющимися "терминалом A" и "терминалом B", соответственно.
(1) Использование ARP_Req (Запрос ARP)
Как показано на фиг.3, когда терминал A сообщается с терминалом B, если MAC-адрес терминала B не известен, а известен только IP-адрес терминала B, терминал A посылает ARP_Req (Запрос ARP) для разрешения адреса терминала B, посредством широковещательной передачи.
Краевой коммутатор 10-1, к которому терминал A подключен, пересылает ARP_Req (запрос ARP) контроллеру 20 через соединение по защищенному каналу. В этот момент контроллер 20 действует как ARP-прокси.
Приняв ARP_Req (запрос ARP) от краевого коммутатора 10-1, к которому подсоединен терминал A, контроллер 20 получает MAC-адрес (и IP-адрес) терминала A из информации об источнике передачи ARP_Req (запроса ARP), и назначает ID пользователя терминалу A. Таким образом, контроллер 20 сопоставляет MAC-адрес (и IP-адрес) терминала A с ID пользователя.
Контроллер 20 регистрирует выходную запись в таблице потоков краевого коммутатора 10-1, к которому подсоединен терминал A, где выходная запись обозначает "когда (ID узла краевого коммутатора и) ID пользователя терминала A, находящегося под управлением, описано в, по меньшей мере, части поля информации об адресате принятого пакета, информация об адресате принятого пакета должна быть восстановлена так, чтобы адресатом являлся MAC-адрес терминала A, а принятый пакет должен быть переслан на MAC-адрес терминала A".
Чтобы разрешить адрес терминала B, являющийся целью, в качестве ARP-прокси, контроллер 20 посылает ARP_Req (запрос ARP) каждому из коммутаторов 10 (10-i, i=1 до n), находящихся под управлением, посредством широковещательной передачи через соединение по защищенному каналу. На настоящий момент, MAC-адресом источника передачи ARP_Req (запроса ARP) является MAC-адрес терминала A.
Краевой коммутатор 10-6, к которому подсоединен терминал B, пересылает ARP_Req (запрос ARP), посланный посредством широковещательной передачи, терминалу B.
Здесь, как упрощение объяснения, только терминал B предполагается являющимся терминалом-адресатом. Однако схожая с вышеописанной обработка выполняется на краевых коммутаторах, к которым подсоединены другие терминалы-адресаты.
(2) Использование ARP_Rep (ответ ARP)
Как показано на фиг.4, терминал В посылает ARP_Rep (ответ ARP), в котором адресатом является терминал A, как отклик на ARP_Req (запрос ARP).
Краевой коммутатор 10-6, к которому подключен терминал В, пересылает ARP_Rep (ответ ARP) контроллеру 20 через соединение по защищенному каналу. На настоящий момент контроллер 20 действует как ARP-прокси.
Приняв ARP_Rep (ответ ARP) от краевого коммутатора 10-6, к которому подсоединен терминал В, контроллер 20 получает MAC-адрес (и IP-адрес) терминала В из информации об источнике передачи ARP_Rep (ответа ARP) и назначает ID пользователя терминалу B. Таким образом, контроллер 20 сопоставляет MAC-адрес (и IP-адрес) терминала В с ID пользователя.
Контроллер 20 регистрирует выходную запись в таблице потоков краевого коммутатора 10-6, к которому подсоединен терминал B, где выходная запись обозначает "когда (ID узла краевого коммутатора и) ID пользователя терминала В, находящегося под управлением, является описанным в, по меньшей мере, части поля информации об адресате принятого пакета, информация об адресате данного пакета должна быть восстановлена так, чтобы адресатом являлся MAC-адрес терминала B, а принятый пакет необходимо переслать по MAC-адресу терминала B".
На настоящий момент контроллер 20 может судить, что передача данных между терминалом A и терминалом В может быть произведена и регистрирует входную запись в таблице потоков краевого коммутатора 10-1, к которому подключен терминал A, где входная запись обозначает "когда принят пакет, чьим адресатом является терминал B, групповой ID (ID узла краевого коммутатора, к которому подключен терминал B, VTN ID данного потока, ID пользователя терминала B) должен быть описан в, по меньшей мере, части поля информации об адресате принятого пакета, и принятый пакет необходимо переслать следующему коммутатору". Этот способ регистрации записи является "упреждающим видом" (способ, в котором входная запись должна быть зарегистрирована заранее).
При пересылке ARP_Rep (ответа ARP) терминалу A контроллер 20 в качестве ARP-прокси, посылает ARP_Rep (ответ ARP) краевому коммутатору 10-1, к которому подсоединен терминал A, через соединение по защищенному каналу. При этом MAC-адресом источника передачи ARP_Rep (ответа ARP) является MAC-адрес терминала B.
Краевой коммутатор 10-1, к которому подсоединен терминал A, пересылает ARP_Rep (ответ ARP), принятый от контроллера 20, терминалу A.
Терминал A получает MAC-адрес терминала В из ARP_Rep (ответа ARP), принятого в качестве отклика на ARP_Req (запрос ARP).
[Передача данных после завершения регистрации записи]
Со ссылкой на фиг.5 будет описана обработка при передаче IP-пакетов и тому подобного между коммутаторами после завершения регистрации записи.
В настоящий момент предполагается, что необходимая регистрация была завершена для всех коммутаторов между коммутаторами. То есть работа контроллера 20 была завершена.
Терминал A описывает MAC-адрес (IP-адрес) терминала В, являющегося адресатом, в поле информации об адресате пакета и посылает пакет, чьим адресатом является терминал B.
При приеме пакета, чьим адресатом является терминал B на входном порте 1, краевой коммутатор 10-1, к которому подсоединен терминал A, подтверждает, зарегистрирована или нет запись, которой соответствует принятый пакет, в своей таблице потоков.
Входная запись является зарегистрированной в своей таблице потоков, где входная запись обозначает "когда принят пакет, чьим адресатом является терминал B, групповой ID (ID узла краевого коммутатора 10-6, к которому подсоединен терминал B, VTN ID потока, ID пользователя терминала B), должен быть описан в, по меньшей мере, части поля информации об адресате данного принятого пакета, а принятый пакет необходимо переслать следующему коммутатору". Таким образом, краевой коммутатор 10-1, к которому подсоединен терминал A, описывает групповой ID в, по меньшей мере, части поля информации об адресате принятого пакета и пересылает принятый пакет следующему коммутатору. В настоящем документе краевой коммутатор 10-1 заменяет MAC-адрес терминала В, описанный в информации об адресате принятого пакета, на групповой ID (перезаписывает групповой ID вместо информации об адресате), пересылает измененный пакет (здесь и далее именуемый как ID-фицированный пакет) в выходной порт 2 и пересылает ID-фицированный пакет из выходного порта 2 следующему коммутатору 10-2.
При приеме ID-фицированного пакета на входном порту 3 краевой коммутатор 10-2 подтверждает, зарегистрирована или нет запись, которой соответствует ID-фицированный пакет, в своей таблице потоков.
Центральная запись является зарегистрированной в своей таблице потоков, где центральная запись обозначает "когда ID узла краевого коммутатора 10-6 является описанным в, по меньшей мере, части поля информации об адресате принятого пакета, принятый пакет необходимо переслать следующему коммутатору (из заранее заданного выходного порта)". Таким образом, краевой коммутатор 10-2 пересылает ID-фицированный пакет на выходной порт 4 и пересылает ID-фицированный пакет из выходного порта 4 следующему коммутатору 10-3. В настоящем документе краевой коммутатор 10-2 определяет, куда переслать ID-фицированный пакет, на выход 4 или на выход 5, основываясь на значении "OPort" центральной записи.
При этом, когда ID-фицированный пакет включает в себя резервный ID, краевой коммутатор 10-2 извлекает центральную запись, соответствующую ID-фицированному пакету, используя значение резервного ID в качестве поискового ключа.
При приеме ID-фицированного пакета на входном порту 10 краевой коммутатор 10-3 подтверждает, зарегистрирована или нет запись, которой соответствует ID-фицированный пакет, в своей таблице потоков.
Центральная запись является зарегистрированной в своей таблице потоков, где центральная запись обозначает "когда ID узла краевого коммутатора 10-6 является описанным в, по меньшей мере, части поля информации об адресате принятого пакета, принятый пакет необходимо переслать следующему коммутатору (из заранее заданного выходного порта)". Таким образом, краевой коммутатор 10-3 пересылает ID-фицированный пакет на выходной порт 12 и пересылает ID-фицированный пакет из выходного порта 12 следующему коммутатору 10-6.
При приеме ID-фицированного пакета на входном порту 13 краевой коммутатор 10-6 подтверждает, зарегистрирована или нет запись, которой соответствует ID-фицированный пакет, в своей таблице потоков.
Выходная запись является зарегистрированной в своей таблице потоков, где выходная запись обозначает "когда (ID узла краевого коммутатора 10-6 и) ID пользователя терминала В, находящегося под управлением, описан в, по меньшей мере, части поля информации об адресате принятого пакета, информацию об адресате принятого пакета необходимо восстановить так, чтобы адресатом являлся MAC-адрес терминала B, и принятый пакет необходимо переслать по MAC-адресу терминала B." Таким образом, краевой коммутатор 10-6, к которому подсоединен терминал B, заменяет групповой ID, описанный в поле информации об адресате ID-фицированного пакета, на MAC-адрес терминала В в качестве адресата (перезаписывает информацию об адресате MAC-адресом терминала B) и пересылает измененный пакет (первоначальный принятый пакет) на выходной порт 14 и пересылает данный пакет из выходного порта 14 терминалу B.
В данном случае, в вышеприведенном описании, "поле MAC-адреса" использовалось как пример поля информации об адресате. Однако "поле IP-адреса" может быть доступным. Иначе говоря, "поле адреса адресата" может быть доступным.
(Второй примерный вариант осуществления)
Второй примерный вариант осуществления настоящего изобретения будет описан ниже.
В настоящем примерном варианте осуществления будет описан случай, в котором "входную запись" необходимо зарегистрировать в таблице потоков входного краевого коммутатора не когда выполняется обнаружение станций, а когда пересылка IP-пакета или тому подобного начинается между коммутаторами.
Здесь, предполагается ситуация, в которой только обработка, при которой "выходная запись" должна быть зарегистрирована в краевом коммутаторе, выполняется при обнаружении станций (используя запрос ARP), как показано на фиг.3, или ситуация, в которой обработка, при которой "входную запись" необходимо зарегистрировать в краевом коммутаторе, не выполняется, когда обнаружение станций (используя отклик ARP) выполняется, как показано на фиг.4.
[Вопрос о пакете]
Со ссылкой на фиг.6 будет описана обработка при вопросе о пакете, когда передача данных начата.
По приему вопроса о принятом пакете от коммутатора, находящегося под управлением, контроллер 20 регистрирует входную запись как отклик через соединение по защищенному каналу.
Прежде всего, терминал A описывает MAC-адрес (и IP-адрес) терминала В, который является адресатом, в поле информации об адресате пакета и передает пакет, чьим адресатом является терминал B.
По приему пакета, чьим адресатом является терминал B, краевой коммутатор 10-1, к которому подсоединен терминал A, подтверждает, зарегистрирована или нет запись, которой соответствует данный пакет, в своей таблице потоков. На настоящий момент в краевом коммутаторе 10-1, к которому подсоединен терминал A, данная запись (входная запись), которой соответствует данный пакет, является не зарегистрированной. Таким образом, краевой коммутатор 10-1, к которому подсоединен терминал A, пересылает пакет, чьим адресатом является терминал В, контроллеру 20 через соединение по защищенному каналу.
Контроллер 20 получает MAC-адрес (и IP-адрес) терминала В из информации об адресате пакета, чьим адресатом является терминал B, и устанавливает ID пользователя терминала В и ID узла краевого коммутатора 10-6, к которому подсоединен терминал B, из информации о топологии и информации о станциях, которую имеет контроллер 20.
Контроллер 20 регистрирует входную запись в таблице потоков краевого коммутатора 10-1, к которому подсоединен терминал A, где входная запись обозначает "когда принят пакет, чьим адресатом является терминал B, групповой ID (ID узла краевого коммутатора, к которому подсоединен терминал B, VTN ID потока, ID пользователя терминала B) должен быть описан в, по меньшей мере, части поля информации об адресате принятого пакета, и принятый пакет должен быть переслан следующему коммутатору". Этот способ регистрации записи относится к "реактивному виду" (способ регистрирования входной записи, когда встречен первый пакет).
(Взаимоотношение между соответствующими примерными вариантами осуществления)
В частности, описанные выше соответствующие примерные варианты осуществления могут быть объединены и выполнены. К примеру, в сетевой системе в соответствии с настоящим изобретением коммутаторы, соответствующие первому примерному варианту осуществления, и коммутаторы, соответствующие второму примерному варианту осуществления, могут быть смешаны. Кроме того, когда существует множество VTN, примерные варианты осуществления могут быть разделены для соответствующих VTN.
(Дополнительное примечание)
Все или часть примерных вариантов осуществления, раскрытых выше, могут быть описаны, но не ограничиваясь этим, как нижеследующие дополнительные примечания.
(Дополнительное примечание 1: конфигурация системы)
Сетевая система, содержащая:
множество коммутаторов, каждый из которых выполнен с возможностью осуществлять в отношении принятого пакета, который удовлетворяет правилу в записи, зарегистрированной в его собственной таблице потоков, операцию на основе действия, заданного в этой записи; и
контроллер, выполненный с возможностью регистрировать запись, в которой идентификатор, уникальный для пути, вычисленного на основе физической топологии сети связи, состоящей из множества коммутаторов, задан в качестве правила, а вывод из заранее заданного выходного порта - в качестве действия, в каждом из множества коммутаторов до начала осуществления связи среди множества коммутаторов.
(Дополнительное примечание 2: регистрация центральной записи)
Сетевая система в соответствии с дополнительным примечанием 1, в которой контроллер включает в себя:
модуль сбора информации о портах, выполненный с возможностью устанавливать информацию о настройке внутренних и внешних портов в каждом из множества коммутаторов и собирать информацию о портах в каждом коммутаторе при обнаружении топологии до начала осуществления связи;
модуль определения коммутатора, выполненный с возможностью определять внутренний порт и внешний порт и определять краевой коммутатор и центральный коммутатор на основе информации о портах каждого коммутатора;
модуль посылки управляющего кадра, выполненный с возможностью посылать управляющий кадр для сбора информации о соседних коммутаторах в порт, в котором нет явной настройки относительно внутреннего и внешнего порта;
модуль создания информации о топологии, выполненный с возможностью обнаруживать физическую топологию сети связи на основе отклика на управляющий кадр и создавать информацию о топологии;
модуль обработки назначения ID узла, выполненный с возможностью сопоставлять каждый коммутатор с ID узла в качестве уникального идентификатора; и
модуль регистрации записи о ретрансляции, выполненный с возможностью вычислять путь между коммутаторами, включающими в себя внешний порт, и регистрировать запись о ретрансляции в таблице потоков центрального коммутатора, где запись о ретрансляции обозначает, что когда ID узла краевого коммутатора описан в поле информации об адресате принятого пакета, принятый пакет должен быть переслан следующему коммутатору.
(Дополнительное примечание 3: регистрация входящей записи о передаче)
Сетевая система в соответствии с дополнительным примечанием 2, в которой контроллер включает в себя:
модуль определения терминала источника передачи, выполненный с возможностью определять, на основе запроса ARP от терминала источника передачи, информацию об адресате терминала источника передачи при обнаружении станций до начала осуществления связи;
модуль обработки назначения ID пользователя источнику передачи, выполненный с возможностью сопоставлять терминал источника передачи с ID пользователя в качестве уникального идентификатора; и
модуль регистрации выходной записи терминала источника передачи, выполненный с возможностью регистрировать выходную запись в таблице потоков краевого коммутатора, к которому подсоединен терминал источника передачи, где выходная запись обозначает, что когда ID узла краевого коммутатора и ID пользователя терминала источника передачи описаны в поле информации об адресате принятого пакета, информация об адресате терминала источника передачи должна быть описана в поле информации об адресате принятого пакета, и принятый пакет должен быть переслан терминалу источника передачи.
(Дополнительное примечание 4: регистрация выходной записи о приеме)
Сетевая система в соответствии с дополнительным примечанием 3, в которой контроллер включает в себя:
модуль определения терминала-адресата, выполненный с возможностью определять, на основе ответа ARP от терминала-адресата, информацию об адресате терминала-адресата при обнаружении станций до начала осуществления связи;
модуль обработки назначения ID пользователя адресату, выполненный с возможностью сопоставлять ID пользователя в качестве уникального идентификатора с терминалом-адресатом; и
модуль регистрации выходной записи терминала-адресата, выполненный с возможностью регистрировать выходную запись в таблице потоков краевого коммутатора, к которому подсоединен терминал-адресат, где выходная запись обозначает, что когда ID узла краевого коммутатора и ID пользователя терминала-адресата описаны в поле информации об адресате принятого пакета, информация об адресате терминала-адресата должна быть описана в поле информации об адресате принятого пакета и принятый пакет должен быть переслан терминалу-адресату.
(Дополнительное примечание 5: регистрация входной записи о передаче (упреждающий вид))
Сетевая система в соответствии с дополнительным примечанием 4, в котором контроллер включает в себя:
модуль суждения о доступности связи, выполненный с возможностью решать, возможна или нет связь между терминалом источника передачи и терминалом-адресатом на основе ответа ARP от терминала-адресата при обнаружении станций до начала передачи данных; и
модуль регистрации входной записи о терминале источника передачи, выполненный с возможностью регистрировать входную запись в таблице потоков краевого коммутатора, к которому подсоединен терминал источника записи, где входная запись обозначает, что когда пакет к терминалу-адресату принят, ID узла краевого коммутатора, к которому терминал-адресат подсоединен, и ID пользователя терминала-адресата должны быть описаны в, по меньшей мере, части поля информации об адресате принятого пакета и принятый пакет необходимо переслать следующему коммутатору.
(Дополнительное примечание 6: регистрация входной записи о передаче (реактивный вид))
Сетевая система в соответствии с дополнительным примечанием 4, в котором контроллер включает в себя:
модуль суждения о доступности связи, выполненный с возможностью решать, возможна или нет связь между терминалом источника передачи и терминалом-адресатом на основе вопроса о пакете от краевого коммутатора, к которому подключен терминал источника передачи, когда передача данных начата; и
модуль регистрации входной записи о терминале источника передачи, выполненный с возможностью регистрировать входную запись в таблице потоков краевого коммутатора, к которому подсоединен терминал источника записи, где входная запись обозначает, что когда пакет к терминалу-адресату принят, ID узла краевого коммутатора, к которому терминал-адресат подсоединен, и ID пользователя терминала-адресата должны быть описаны в, по меньшей мере, части поля информации об адресате данного принятого пакета и принятый пакет необходимо переслать следующему коммутатору.
Хотя настоящее изобретение было описано выше применительно к нескольким примерным вариантам его осуществления, будет очевидным, что настоящее изобретение не ограничивается этими примерными вариантами осуществления и может быть изменено и усовершенствовано, не выходя за рамки объема и сущности данного изобретения.
Эта заявка основана и имеет приоритет заявки на патент Японии No. 2011-005137, раскрытие которой включено в настоящий документ полностью посредством ссылки.

Claims (10)

1. Сетевая система, содержащая:
множество коммутаторов, каждый из которых выполнен с возможностью выполнять, в отношении принятого пакета, удовлетворяющего правилу из записи, зарегистрированной в его собственной таблице потоков, операцию на основе действия, заданного в этой записи; и
контроллер, выполненный с возможностью регистрировать запись, в которой идентификатор, уникальный для пути, вычисленного на основе физической топологии сети, состоящей из упомянутого множества коммутаторов, задан в качестве правила, а вывод из заранее заданного выходного порта - в качестве действия, в каждом из упомянутого множества коммутаторов до начала осуществления связи среди этого множества коммутаторов,
при этом контроллер включает в себя:
средство для обнаружения физической топологии сети и классифицирования упомянутого множества коммутаторов на краевые коммутаторы и центральные коммутаторы при обнаружении топологии до начала осуществления связи,
средство для назначения уникального идентификатора каждому из краевых коммутаторов, и
средство для вычисления пути между краевыми коммутаторами и для регистрации записи о ретрансляции в таблице потоков центрального коммутатора, где запись о ретрансляции обозначает, что когда идентификатор заранее заданного краевого коммутатора описан в поле информации об адресате принятого пакета, этот принятый пакет должен быть переслан следующему коммутатору.
2. Сетевая система по п. 1, в которой контроллер дополнительно включает в себя:
средство для получения информации об адресате терминала источника передачи при обнаружении станций до начала осуществления связи,
средство для назначения уникального идентификатора терминалу источника передачи, и
средство для регистрации выходной записи в таблице потоков краевого коммутатора, к которому подсоединен терминал источника передачи, где выходная запись обозначает, что когда идентификатор краевого коммутатора и идентификатор терминала источника передачи описаны в поле информации об адресате принятого пакета, информация об адресате терминала источника передачи должна быть описана в поле информации об адресате этого принятого пакета и данный принятый пакет должен быть переслан терминалу источника передачи.
3. Сетевая система по п. 2, в которой контроллер дополнительно включает в себя:
средство для задания информации об адресате терминала-адресата при обнаружении станций до начала осуществления связи,
средство для назначения идентификатора в качестве уникального идентификатора терминалу-адресату, и
средство для регистрации выходной записи в таблице потоков краевого коммутатора, к которому подсоединен терминал-адресат, где выходная запись обозначает, что когда идентификатор данного краевого коммутатора и идентификатор терминала-адресата описаны в поле информации об адресате принятого пакета, информация об адресате для терминала-адресата должна быть описана в поле информации об адресате этого принятого пакета и данный принятый пакет должен быть передан терминалу-адресату.
4. Сетевая система по п. 3, в которой контроллер дополнительно включает в себя:
средство для подтверждения того, возможно ли или нет осуществление связи между терминалом источника передачи и терминалом-адресатом, и
средство для регистрации, когда осуществление связи между терминалом источника передачи и терминалом-адресатом оценено как возможное, входной записи в таблице потоков краевого коммутатора, к которому подсоединен терминал источника передачи, где входная запись обозначает, что когда пакет, направленный к терминалу-адресату, принят, идентификатор краевого коммутатора, к которому подсоединен терминал-адресат, и идентификатор терминала-адресата должны быть описаны в, по меньшей мере, части поля информации об адресате этого принятого пакета и данный принятый пакет должен быть переслан следующему коммутатору.
5. Контроллер, выполненный с возможностью использования для сетевой системы по любому из пп. 1-4.
6. Способ маршрутизации, содержащий этапы, на которых
каждый из множества коммутаторов выполняет в отношении принятого пакета, удовлетворяющего правилу из записи, зарегистрированной в его собственной таблице потоков, операцию на основе действия, заданного в этой записи; и
контроллер регистрирует запись, в которой идентификатор, уникальный для пути, вычисленного на основе физической топологии сети, состоящей из упомянутого множества коммутаторов, задан в качестве правила, а вывод из заранее заданного выходного порта - в качестве действия, в каждом из этого множества коммутаторов до начала осуществления связи среди упомянутого множества коммутаторов,
при этом способ маршрутизации дополнительно содержит этапы, на которых контроллер
обнаруживает физическую топологию сети и классифицирует упомянутое множество коммутаторов на краевые коммутаторы и центральные коммутаторы при обнаружении топологии до начала осуществления связи,
назначает уникальный идентификатор каждому из краевых коммутаторов, и
вычисляет путь между краевыми коммутаторами и регистрирует запись о ретрансляции в таблице потоков центрального коммутатора, где запись о ретрансляции обозначает, что когда идентификатор заранее заданного краевого коммутатора описан в поле информации об адресате принятого пакета, этот принятый пакет должен быть переслан следующему коммутатору.
7. Способ маршрутизации по п. 6, дополнительно содержащий этапы, на которых контроллер
задает информацию об адресате терминала источника передачи при обнаружении станций до начала осуществления связи,
назначает уникальный идентификатор терминалу источника передачи, и
регистрирует выходную запись в таблице потоков краевого коммутатора, к которому подсоединен терминал источника передачи, где выходная запись обозначает, что когда идентификатор краевого коммутатора и идентификатор терминала источника передачи описаны в поле информации об адресате принятого пакета, информация об адресате терминала источника передачи должна быть описана в поле информации об адресате принятого пакета и данный принятый пакет должен быть переслан терминалу источника передачи.
8. Способ маршрутизации по п. 7, дополнительно содержащий этапы, на которых контроллер
задает информацию об адресате терминала-адресата при обнаружении станций до начала осуществления связи,
назначает идентификатор в качестве уникального идентификатора терминалу-адресату, и
регистрирует выходную запись в таблице потоков краевого коммутатора, к которому подсоединен терминал-адресат, где выходная запись обозначает, что когда идентификатор краевого коммутатора и идентификатор терминала-адресата описаны в поле информации об адресате принятого пакета, информация об адресате для терминала-адресата должна быть описана в поле информации об адресате этого принятого пакета и данный принятый пакет должен быть передан терминалу-адресату.
9. Способ маршрутизации по п. 8, дополнительно содержащий этапы, на которых контроллер
подтверждает, возможно ли или нет осуществление связи между терминалом источника передачи и терминалом-адресатом, и
регистрирует, когда осуществление связи между терминалом источника передачи и терминалом-адресатом оценено как возможное, входную запись в таблице потоков краевого коммутатора, к которому подсоединен терминал источника передачи, где входная запись обозначает, что когда пакет, направленный к терминалу-адресату, принят, идентификатор краевого коммутатора, к которому подсоединен терминал-адресат, и идентификатор терминала-адресата должны быть описаны в, по меньшей мере, части поля информации об адресате этого принятого пакета и данный принятый пакет должен быть переслан следующему коммутатору.
10. Носитель информации, включающий в себя программу, предписывающую компьютеру выполнять работу контроллера в способе маршрутизации по любому из пп. 6-9.
RU2013132519/08A 2011-01-13 2011-12-27 Сетевая система и способ маршрутизации RU2576473C2 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2011005137 2011-01-13
JP2011-005137 2011-01-31
PCT/JP2011/080325 WO2012096131A1 (ja) 2011-01-13 2011-12-27 ネットワークシステム、及び経路制御方法

Publications (2)

Publication Number Publication Date
RU2013132519A RU2013132519A (ru) 2015-02-20
RU2576473C2 true RU2576473C2 (ru) 2016-03-10

Family

ID=46507042

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2013132519/08A RU2576473C2 (ru) 2011-01-13 2011-12-27 Сетевая система и способ маршрутизации

Country Status (9)

Country Link
US (3) US9787580B2 (ru)
EP (2) EP2665229B1 (ru)
JP (3) JP5585664B2 (ru)
KR (3) KR101624474B1 (ru)
CN (2) CN105262683B (ru)
ES (1) ES2706416T3 (ru)
RU (1) RU2576473C2 (ru)
TW (1) TWI489821B (ru)
WO (1) WO2012096131A1 (ru)

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102938794B (zh) * 2012-11-14 2016-01-13 华为技术有限公司 地址解析协议arp消息转发方法、交换机和控制器
JP6024761B2 (ja) 2012-11-27 2016-11-16 日本電気株式会社 制御装置、通信システム、通信方法及びプログラム
CN103905577A (zh) * 2012-12-28 2014-07-02 中兴通讯股份有限公司 一种地址解析协议报文的处理方法和系统
US8929356B2 (en) * 2013-02-05 2015-01-06 Anue Systems, Inc. Mobile user identification and tracking for load balancing in packet processing systems
CN103179046B (zh) * 2013-04-15 2016-03-30 昆山天元昌电子有限公司 基于openflow的数据中心流量控制方法及系统
US9210074B2 (en) * 2013-05-03 2015-12-08 Alcatel Lucent Low-cost flow matching in software defined networks without TCAMs
CN104243319B (zh) * 2013-06-06 2018-01-09 新华三技术有限公司 一种邻居发现的方法及装置
CN103346922B (zh) * 2013-07-26 2016-08-10 电子科技大学 基于sdn的确定网络状态的控制器及其确定方法
US10356037B2 (en) * 2013-08-01 2019-07-16 Hewlett Packard Enterprise Development Lp Address resolution rewriting
CN104348727B (zh) * 2013-08-05 2018-05-15 新华三技术有限公司 OpenFlow网络中的流表表项处理方法及设备
US9426060B2 (en) 2013-08-07 2016-08-23 International Business Machines Corporation Software defined network (SDN) switch clusters having layer-3 distributed router functionality
US10498669B2 (en) 2013-08-20 2019-12-03 Nec Corporation Communication system, switch, controller, ancillary data management apparatus, data forwarding method, and program
JP6417086B2 (ja) * 2013-09-06 2018-10-31 エヌ・ティ・ティ・コミュニケーションズ株式会社 接続制御装置、中継装置、接続制御方法、及びプログラム
CN103458479A (zh) * 2013-09-17 2013-12-18 清华大学 Wsn中基于内容的路由表的数据路由方法及系统
US20150098475A1 (en) * 2013-10-09 2015-04-09 International Business Machines Corporation Host table management in software defined network (sdn) switch clusters having layer-3 distributed router functionality
JP6524911B2 (ja) * 2013-11-20 2019-06-05 日本電気株式会社 ネットワーク制御装置、ネットワーク制御方法およびプログラム
WO2015080092A1 (ja) 2013-11-26 2015-06-04 日本電気株式会社 ネットワーク制御装置、ネットワークシステム、ネットワーク制御方法、および、プログラム
TWI513260B (zh) * 2013-12-13 2015-12-11 Inventec Corp 路由控制方法與裝置
WO2015118811A1 (ja) * 2014-02-10 2015-08-13 日本電気株式会社 通信システム、パケット転送装置、パケット転送方法およびパケット転送用プログラム
CN104954281B (zh) * 2014-03-31 2018-08-03 中国移动通信集团公司 通信方法、系统、资源池管理系统、交换机和控制装置
CN105531967B (zh) * 2014-04-21 2020-06-16 华为技术有限公司 一种报文传输方法、设备及通信系统
CN105409169B (zh) * 2014-05-30 2019-01-18 华为技术有限公司 一种多路径转发规则的构造方法、装置及系统
WO2015184586A1 (zh) * 2014-06-03 2015-12-10 华为技术有限公司 开放流通信方法、系统、控制器和业务网关
US9774502B2 (en) * 2014-06-25 2017-09-26 Ciena Corporation Systems and methods for combined software defined networking and distributed network control
EP3142310B1 (en) * 2014-06-30 2022-06-15 Huawei Technologies Co., Ltd. Method, device, and system for configuring flow entries
US9813301B2 (en) * 2014-08-20 2017-11-07 Nec Corporation Optimization framework for multi-tenant data centers
US9876712B2 (en) * 2014-09-05 2018-01-23 Kt Corporation Method and device for processing address resolution protocol in software-defined networking environment
WO2016090552A1 (zh) 2014-12-09 2016-06-16 华为技术有限公司 一种自适应流表的处理方法及装置
JP2016116024A (ja) * 2014-12-12 2016-06-23 日立金属株式会社 タグ変換装置
KR101989333B1 (ko) * 2014-12-17 2019-09-30 후아웨이 테크놀러지 컴퍼니 리미티드 소프트웨어 정의 네트워킹에서의 데이터 전달 방법, 기기 및 시스템
CN104639438A (zh) * 2015-01-05 2015-05-20 北京交通大学 一种OpenFlow网络中数据流的新标识和控制方法
JP2016181819A (ja) * 2015-03-24 2016-10-13 富士通株式会社 ネットワークの制御装置及び制御方法、並びに、ネットワークスイッチ
JP6525256B2 (ja) * 2015-05-29 2019-06-05 Ｎｅｃプラットフォームズ株式会社 仮想ネットワークシステムおよび仮想ネットワーク経路設定方法
KR101674177B1 (ko) 2015-07-07 2016-11-09 주식회사 케이티 멀티노드간 이더넷 가상연결서비스를 제공하는 트랜스포트 sdn 컨트롤러 및 멀티노드간 이더넷 가상연결서비스 제공 방법
CN106411746A (zh) * 2015-08-03 2017-02-15 上海宽带技术及应用工程研究中心 基于Vlan的SDN网络数据传输系统及方法
US10003537B2 (en) 2015-10-01 2018-06-19 Keysight Technologies Singapore (Holding) Pte Ltd Egress port overload protection for network packet forwarding systems
JP6701779B2 (ja) * 2016-02-15 2020-05-27 株式会社リコー 通信システム
JP2017175522A (ja) * 2016-03-25 2017-09-28 日本電気株式会社 ネットワークシステム、制御装置、方法およびプログラム
KR101870146B1 (ko) * 2016-10-12 2018-06-25 아토리서치(주) 리프-스파인 구조의 소프트웨어 정의 네트워킹에서 목적지 기반 패킷 전송 제어 방법 및 장치
KR102342734B1 (ko) * 2017-04-04 2021-12-23 삼성전자주식회사 Sdn 제어 장치 및 이의 데이터 패킷의 전송 룰 설정 방법
CN112039772B (zh) * 2017-06-29 2024-04-09 华为技术有限公司 一种传输路径的确定方法及节点
KR102001487B1 (ko) * 2017-11-22 2019-07-17 아토리서치(주) 소프트웨어 정의 네트워킹 제어 방법 및 이를 수행하는 컴퓨팅 장치
CN112187643B (zh) * 2017-11-28 2021-12-10 华为技术有限公司 报文转发的方法、控制面网关和用户面网关
PL3531622T3 (pl) * 2018-02-23 2020-06-29 Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Sposób obsługi przepływu pakietów w programowalnej sieci komputerowej SDN, produkt programu komputerowego oraz programowalna sieć komputerowa SDN
CN110460456B (zh) * 2018-05-08 2020-10-20 大唐移动通信设备有限公司 一种管理信息库mib同步生成网络拓扑的方法及装置
CN110838979B (zh) * 2018-08-17 2022-02-08 中国电信股份有限公司 流量转发控制方法、装置、系统和计算机可读存储介质
JP2019092233A (ja) * 2019-03-26 2019-06-13 Ｎｅｃプラットフォームズ株式会社 仮想ネットワークシステムおよび仮想ネットワーク経路設定方法
KR102207290B1 (ko) * 2019-04-12 2021-01-25 아토리서치(주) 소프트웨어 정의 네트워크에서 vlan을 지원하는 방법
CN112887741A (zh) * 2021-01-08 2021-06-01 武汉球之道科技有限公司 一种篮球比赛进球视频无线分享系统
CN115134299A (zh) * 2021-03-25 2022-09-30 华为技术有限公司 通信方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2189072C2 (ru) * 1996-01-31 2002-09-10 Ипсилон Нетуоркс, Инк. Усовершенствованный способ и устройство для динамического смещения между пакетами маршрутизации и коммутации в сети передачи данных

Family Cites Families (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6876654B1 (en) * 1998-04-10 2005-04-05 Intel Corporation Method and apparatus for multiprotocol switching and routing
US6526052B1 (en) * 1998-12-23 2003-02-25 Enterasys Networks, Inc. Virtual local area networks having rules of precedence
US7200144B2 (en) * 2001-10-18 2007-04-03 Qlogic, Corp. Router and methods using network addresses for virtualization
US20030156541A1 (en) * 2002-02-21 2003-08-21 Zheng Haihong Method and system for reserving resources on an MPLS path
US8050180B2 (en) 2003-10-31 2011-11-01 Brocade Communications Systems, Inc. Network path tracing method
JP3760167B2 (ja) * 2004-02-25 2006-03-29 株式会社日立製作所 通信制御装置、通信ネットワークおよびパケット転送制御情報の更新方法
JP4332079B2 (ja) * 2004-07-01 2009-09-16 株式会社日立製作所 モジュール型パケット通信ノード装置
JP4598462B2 (ja) * 2004-09-16 2010-12-15 富士通株式会社 Ｌ２−ｖｐｎサービスを提供するプロバイダ網、及びエッジルータ
US7801125B2 (en) 2004-10-22 2010-09-21 Cisco Technology, Inc. Forwarding table reduction and multipath network forwarding
JP4715750B2 (ja) * 2004-11-04 2011-07-06 パナソニック株式会社 マルチインタフェース通信装置、端末、および経路切替方法
US7827402B2 (en) * 2004-12-01 2010-11-02 Cisco Technology, Inc. Method and apparatus for ingress filtering using security group information
JP4680866B2 (ja) * 2006-10-31 2011-05-11 株式会社日立製作所 ゲートウェイ負荷分散機能を備えたパケット転送装置
JP4680942B2 (ja) * 2007-01-18 2011-05-11 株式会社日立製作所 パケット転送装置
JP4555311B2 (ja) * 2007-01-31 2010-09-29 日本電信電話株式会社 トンネル通信システム、制御装置およびトンネル通信装置
US20080189769A1 (en) * 2007-02-01 2008-08-07 Martin Casado Secure network switching infrastructure
US20090063438A1 (en) 2007-08-28 2009-03-05 Iamg, Llc Regulatory compliance data scraping and processing platform
JP5076768B2 (ja) 2007-09-21 2012-11-21 日本電気株式会社 ネットワークシステム、ネットワーク管理装置、通信装置、パス設定方法及びプログラム
US9083609B2 (en) 2007-09-26 2015-07-14 Nicira, Inc. Network operating system for managing and securing networks
GB2458154B (en) * 2008-03-07 2012-06-27 Hewlett Packard Development Co Routing across a virtual network
US20090249471A1 (en) * 2008-03-27 2009-10-01 Moshe Litvin Reversible firewall policies
EP2296788B1 (fr) 2008-05-16 2012-02-29 Eurecat S.A. Procede de sulfuration ou presulfuration de particules solides d'un catalyseur ou d'un adsorbant
JP5242301B2 (ja) * 2008-09-01 2013-07-24 株式会社東芝 メッセージを転送する装置、出力方法および出力プログラム
US8761152B2 (en) * 2008-10-14 2014-06-24 William Marsh Rice University Method and system for scalable ethernet
JP2010193019A (ja) * 2009-02-16 2010-09-02 Panasonic Corp 通信装置及び通信装置の遠隔起動方法
JP5408243B2 (ja) 2009-03-09 2014-02-05 日本電気株式会社 ＯｐｅｎＦｌｏｗ通信システムおよびＯｐｅｎＦｌｏｗ通信方法
JP5423787B2 (ja) * 2009-03-26 2014-02-19 日本電気株式会社 経路設定サーバ、経路設定方法、及び経路設定プログラム
CN104702537B (zh) * 2009-04-01 2018-07-10 Nicira股份有限公司 用于实现和管理虚拟交换机的方法和装置
US9497039B2 (en) * 2009-05-28 2016-11-15 Microsoft Technology Licensing, Llc Agile data center network architecture
US9210065B2 (en) * 2009-06-22 2015-12-08 Alcatel Lucent Providing cloud-based services using dynamic network virtualization
JP4933592B2 (ja) 2009-06-29 2012-05-16 京楽産業．株式会社 遊技機、認証方法、プログラム
EP2482496B1 (en) * 2009-09-24 2018-11-28 Nec Corporation Identification system for inter-virtual-server communication and identification method for inter-virtual-server communication
WO2011037105A1 (ja) * 2009-09-25 2011-03-31 日本電気株式会社 コンテンツベーススイッチシステム、及びコンテンツベーススイッチ方法
US8369333B2 (en) * 2009-10-21 2013-02-05 Alcatel Lucent Method and apparatus for transparent cloud computing with a virtualized network infrastructure
JP5392137B2 (ja) * 2010-02-17 2014-01-22 富士通株式会社 通信処理のためのプログラム、コンピュータ及び方法
US8571040B2 (en) * 2010-03-01 2013-10-29 Deutsche Telekom Ag Apparatus, method, manufacture, and system for providing network services from building blocks
US8817629B2 (en) * 2010-03-16 2014-08-26 Deutsche Telekom Ag Method for routing-assisted traffic monitoring
US8504718B2 (en) * 2010-04-28 2013-08-06 Futurewei Technologies, Inc. System and method for a context layer switch
US8503307B2 (en) * 2010-05-10 2013-08-06 Hewlett-Packard Development Company, L.P. Distributing decision making in a centralized flow routing system
US8989187B2 (en) * 2010-06-04 2015-03-24 Coraid, Inc. Method and system of scaling a cloud computing network
US8897134B2 (en) * 2010-06-25 2014-11-25 Telefonaktiebolaget L M Ericsson (Publ) Notifying a controller of a change to a packet forwarding configuration of a network element over a communication channel
US9680750B2 (en) * 2010-07-06 2017-06-13 Nicira, Inc. Use of tunnels to hide network addresses
US8880468B2 (en) * 2010-07-06 2014-11-04 Nicira, Inc. Secondary storage architecture for a network control system that utilizes a primary network information base
CN101917492B (zh) * 2010-08-06 2013-06-05 北京乾唐视联网络科技有限公司 一种新型网的通信方法及系统
US20120099591A1 (en) * 2010-10-26 2012-04-26 Dell Products, Lp System and Method for Scalable Flow Aware Network Architecture for Openflow Based Network Virtualization
CA2814830A1 (en) * 2010-10-28 2012-05-03 Nec Corporation Network system and communication traffic controlling method
US9001827B2 (en) * 2010-12-17 2015-04-07 Big Switch Networks, Inc. Methods for configuring network switches
US8559335B2 (en) * 2011-01-07 2013-10-15 Jeda Networks, Inc. Methods for creating virtual links between fibre channel over ethernet nodes for converged network adapters

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2189072C2 (ru) * 1996-01-31 2002-09-10 Ипсилон Нетуоркс, Инк. Усовершенствованный способ и устройство для динамического смещения между пакетами маршрутизации и коммутации в сети передачи данных

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Nick McKeon et al, OpenFlow: Enabling Innovation in Campus Networks, 14.03.2008, 6 c., [онлайн], [найдено 10.02.2015]. Найдено в Интернет: . IEEE Standard for Local and metropolitan area networks Virtual Bridged Local Area Networks, 2005, 6 c, [онлайн], найдено [13.02.2015]. Найдено в Интернет: . *

Also Published As

Publication number Publication date
JP5594552B2 (ja) 2014-09-24
TW201246843A (en) 2012-11-16
US20210029027A1 (en) 2021-01-28
JP5585664B2 (ja) 2014-09-10
ES2706416T3 (es) 2019-03-28
TWI489821B (zh) 2015-06-21
JP2014168285A (ja) 2014-09-11
KR20130121921A (ko) 2013-11-06
KR20160021309A (ko) 2016-02-24
JPWO2012096131A1 (ja) 2014-06-09
WO2012096131A1 (ja) 2012-07-19
KR101624474B1 (ko) 2016-05-26
CN103329488B (zh) 2016-05-04
KR101574167B1 (ko) 2015-12-03
US11552885B2 (en) 2023-01-10
JP5594551B2 (ja) 2014-09-24
KR20150054006A (ko) 2015-05-19
EP3461077A1 (en) 2019-03-27
CN103329488A (zh) 2013-09-25
US10819625B2 (en) 2020-10-27
RU2013132519A (ru) 2015-02-20
EP2665229A4 (en) 2016-12-07
US9787580B2 (en) 2017-10-10
EP2665229A1 (en) 2013-11-20
US20130279371A1 (en) 2013-10-24
EP2665229B1 (en) 2018-10-17
CN105262683B (zh) 2021-03-30
CN105262683A (zh) 2016-01-20
US20180041429A1 (en) 2018-02-08
JP2014168286A (ja) 2014-09-11

Similar Documents

Publication Publication Date Title
RU2576473C2 (ru) Сетевая система и способ маршрутизации
RU2562438C2 (ru) Сетевая система и способ управления сетью
US20130346585A1 (en) Network system, and policy route setting method
EP2696537B1 (en) Network system, switch, and connection terminal detection method
US9246815B2 (en) Load reducing system and load reducing method
CN112887229B (zh) 一种会话信息同步方法及装置
US9203758B2 (en) Network system, packet processing method and recording medium
US20140310377A1 (en) Information processing method and information processing apparatus
JP5966488B2 (ja) ネットワークシステム、スイッチ、及び通信遅延短縮方法
EP3262802A1 (en) Automatic discovery and provisioning of multi-chassis etherchannel peers
CN102546546B (zh) 标识网中实现QoS的方法和系统