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

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

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ

Настоящее изобретение относится к сетевой системе. Более конкретно, настоящее изобретение относится к способу маршрутизации для сетевой системы.

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

Способ управления коммутатором, оконечным устройством (терминалом) и так далее (плоскость пользователя) с внешнего контроллера (плоскость управления) называется архитектурой разделения 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 след