УЗЕЛ СВЯЗИ, СИСТЕМА СВЯЗИ, СПОСОБ ОБРАБОТКИ ПАКЕТОВ И ПРОГРАММА
COMMUNICATION CENTER, COMMUNICATION SYSTEM, METHOD OF PROCESSING OF PACKETS AND PROGRAM

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
[0001] Ссылка на родственную заявку
Данная заявка основана и по ней испрашивается приоритет на основании заявки на патент Японии № 2013-093738, поданной 26 апреля 2013 г., содержимое которой полностью включено в настоящий документ путем ссылки на нее.
Настоящее изобретение относится к узлу связи, системе связи, способу обработки пакетов и программе. В частности, оно относится к: узлу связи, который работает на основании управляющей информации, заданной устройством(ами) управления; системе связи; способу обработки пакетов; и программе.
УРОВЕНЬ ТЕХНИКИ
[0002] Непатентные источники (NPL) 1 и 2 предлагают методику, которая называется OpenFlow и реализует тип сети с централизованным управлением, в которой плоскости управления и данных отделяются друг от друга. OpenFlow понимает связь как сквозные потоки и выполняет управление маршрутом, восстановление после сбоя, балансирование нагрузки и оптимизацию на основе потоков. Коммутатор OpenFlow, стандартизованный в NPL 2, имеет защищенный канал для связи с контроллером OpenFlow и работает в соответствии с таблицей потоков, дополняемой или перезаписываемой соответствующим образом контроллером OpenFlow. В таблице потоков для каждого потока задается набор из трех следующих элементов: условия соответствия (Match Fields), с которыми сопоставляются заголовки пакетов; статистическая информация о потоке (Counters); и команда(ы) (Instructions), которая задает содержимое обработки (см. раздел "5.2 Flow Table" в NPL 2).
[0003] Например, когда коммутатор OpenFlow принимает пакет, коммутатор OpenFlow ищет в таблице потоков запись, имеющую условия соответствия (см. "5.3 Matching" в NPL 2), которые соответствуют информации заголовка у принятого пакета. В результате поиска, если коммутатор OpenFlow находит запись, которая соответствует принятому пакету, то коммутатор OpenFlow обновляет статистическую информацию о потоке (Counters) и обрабатывает принятый пакет на основе содержимого обработки (пакетная передача из заданного порта, волновое распространение, отбрасывание и т.п.), записанного в поле команды у той записи. Если в результате поиска коммутатор OpenFlow не находит запись, которая соответствует принятому пакету, то коммутатор OpenFlow просит у контроллера OpenFlow задать запись для обработки принятого пакета, а именно передает контроллеру OpenFlow запрос передачи управляющей информации (сообщение Packet-In) по соответствующему защищенному каналу. Коммутатор OpenFlow принимает запись о потоке, в которой задается содержимое обработки, и обновляет свою таблицу потоков. Таким образом, коммутатор OpenFlow выполняет перенаправление пакетов, используя в качестве управляющей информации запись, сохраненную в таблице потоков.
[0004] Патентный источник (PTL) 1 раскрывает устройство связи (соответствующее коммутатору OpenFlow), которое выполняет высокоскоростное переключение маршрутов при возникновении сбоя или перегрузки в сети, используя вышеупомянутую OpenFlow. Точнее говоря, PTL 1 раскрывает, что это устройство связи включает в себя: блок хранения обработки (соответствующий вышеупомянутой таблице потоков), который хранит правила обработки, в которых ассоциируется друг с другом информация для идентификации принятых пакетов и обработка, выполняемая над принятыми пакетами; альтернативный блок хранения обработки (таблица, хранящая альтернативы записям в вышеупомянутой таблице потоков), который хранит правила обработки, включающие в себя обработку, которая выполняется над принятыми пакетами и которая отличается от обработки, сохраненной в блоке хранения обработки; и блок обработки, который обрабатывает принятые пакеты в соответствии с правилами обработки, полученными путем поиска в блоке хранения обработки или в альтернативном блоке хранения обработки на основе информации для идентификации принятых пакетов.
[0005] PTL 2 раскрывает контроллер OpenFlow, допускающий сокращение ненужной обработки по настройке потоков (задание управляющей информации в коммутаторах). Контроллер OpenFlow добивается этого путем задания управляющей информации (правила перенаправления) после подтверждения установления соединения между терминалами.
[0006] PTL 3 раскрывает конфигурацию, в которой множество таблиц потоков хранятся в отдельном коммутаторе OpenFlow. Таким образом, отдельному коммутатору OpenFlow разрешено хранить большее количество записей.
[0007] PTL 1: Публикация нерассмотренной заявки на патент Японии № JP2012-49674A
PTL 2: Публикация нерассмотренной заявки на патент Японии № JP2012-195807A
PTL 3: Международная публикация № 2012/032864
[0008] NPL 1: Nick McKeown и др. "OpenFlow: Enabling Innovation in Campus Networks" [электронный ресурс, найдено: 10 апреля 2013 г.], Интернет <URL:http://www.openflow.org/documents/openflow-wp-latest.pdf>
NPL 2: "OpenFlow Switch Specification" версия 1.3.1 (Wire Protocol 0x04) [электронный ресурс, найдено: 10 апреля 2013 г.], Интернет <URL: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.1.pdf>
РАСКРЫТИЕ ИЗОБРЕТЕНИЯ
[0009] Авторами настоящего изобретения проведен следующий анализ. Как подчеркнуто в абзацах 0006-0008 в PTL 1, в сети, в которой плоскости управления и данных отделены друг от друга, как представлено вышеприведенной OpenFlow, при возникновении сбоя необходимо много времени до возобновления связи, что считается проблемой. Причина в том, что управляемому в сети коммутатору (коммутаторам) нужно запрашивать устройство управления (контроллер OpenFlow), управляющее плоскостью управления, о следующей операции или об адресате перенаправления данных. В частности, если расширяется сеть и увеличивается количество коммутаторов, управляемых устройством управления, то к устройству управления одновременно передается много запросов. В результате плоскость управления перегружается, что считается проблемой.
[0010] В соответствии с PTL 1 отдельное устройство связи включает в себя по меньшей мере одну таблицу потоков, которая хранит группу основных записей о потоках, которая соответствует маршрутам, используемым во время нормальной работы, и группу альтернативных записей о потоках, которая соответствует альтернативным маршрутам, используемым при возникновении сбоев. Устройство связи осуществляет переключение маршрутов путем обращения к группе основных записей о потоках во время нормальной работы и к группе альтернативных записей о потоках, когда возникает сбой (см. абзац 0062. PLT 1 также раскрывает способ параллельного поиска двух групп записей о потоках и способ определения обработки, которую нужно выполнить с помощью соответствующего коммутатора).
[0011] Однако PTL 1 проблематична в том, что в таблице потоков область для хранения группы альтернативных записей о потоках должна быть защищенной. В частности, если таблица потоков конфигурируется с использованием CAM (ассоциативное запоминающее устройство) или т.п., записи о потоках, которые используются только тогда, когда возникает сбой, занимают ценную область.
[0012] К тому же в сети, в которой плоскости управления и данных отделяются друг от друга, желательно, чтобы выдаваемые узлам связи, например коммутаторам, команды изменялись в различные моменты, например, когда обнаруживается неисправность порта у некоторого коммутатора, когда прерывается связь с устройством управления (контроллером) или когда возникает перегрузка.
[0013] Задача настоящего изобретения состоит в создании: узла(ов) связи, которому разрешено изменять команду(ы) (управляющую информацию), выдаваемую устройством (устройствами) управления, когда происходит заданное событие, например сбой, без запроса каждый раз устройства(в) управления или без предварительного размещения в таблице потоков альтернативной записи(ей) о потоке для восстановления после сбоя, как описано выше; системы связи; способа обработки пакетов; и программы.
[0014] В соответствии с первым аспектом предложен узел связи, включающий в себя: блок обработки пакетов, который обрабатывает принятые пакеты путем обращения к первой таблице(ам), которая хранит запись(и), задающую условия соответствия, с которыми сопоставляются принятые пакеты, и содержимое обработки, применяемое к пакетам, которые соответствуют условиям соответствия; и независимый функциональный блок, который обращается ко второй таблице(ам), в которой событие(я) ассоциировано с изменением(ями), применяемым к записи(ям), сохраненной в первой таблице(ах), когда обнаружено наступление события(ий), и который перезаписывает запись(и) в первой таблице(ах) на основании наступившего события(ий).
[0015] В соответствии со вторым аспектом предложена система связи, включающая в себя вышеупомянутый узел(ы) связи и устройство(а) управления, которое задает запись(и) в первой таблице(ах) и во второй таблице(ах) в узле(ах) связи.
[0016] В соответствии с третьим аспектом предложен способ обработки пакетов, включающий в себя этапы: предписания узлу связи, включающему в себя блок обработки пакетов, который обрабатывает принятые пакеты путем обращения к первой таблице(ам), которая хранит запись(и), задающую условия соответствия, с которыми сопоставляются принятые пакеты, и содержимое обработки, применяемое к пакетам, которые соответствуют условиям соответствия, обнаружить наступление заданного события(ий); и предписания узлу связи обратиться ко второй таблице(ам), в которой событие(я) ассоциировано с изменением(ями), применяемым к записи(ям), сохраненной в первой таблице(ах), когда обнаружено наступление события(ий), и перезаписать запись(и) в первой таблице(ах) на основании наступившего события(ий). Этот способ ассоциирован с некоторым устройством(ами), а именно с узлом(ами) связи, который обрабатывает принятые пакеты путем обращения к вышеупомянутой первой таблице(ам).
[0017] В соответствии с четвертым аспектом предложена программа, предписывающая компьютеру, включающему в себя блок обработки пакетов, который обрабатывает принятые пакеты путем обращения к первой таблице(ам), которая хранит запись(и), задающую условия соответствия, с которыми сопоставляются принятые пакеты, и содержимое обработки, применяемое к пакетам, которые соответствуют условиям соответствия, выполнить обработку для: обнаружения наступления заданного события(ий); и обращения ко второй таблице(ам), в которой событие(я) ассоциировано с изменением(ями), применяемым к записи(ям), сохраненной в первой таблице(ах), когда обнаружено наступление события(ий), и перезаписи записи(ей) в первой таблице(ах) на основании наступившего события(ий). Программу можно записать на машиночитаемый (постоянный) носитель информации. А именно настоящее изобретение можно реализовать в виде компьютерного программного продукта.
[0018] В соответствии с настоящим изобретением узлу(ам) связи разрешается изменять команду(ы) (управляющую информацию), выдаваемую устройством(ами) управления, без запроса каждый раз устройства(в) управления или без предварительного размещения в таблице потоков альтернативной записи(ей) о потоке для восстановления после сбоя.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0019] Фиг. 1 иллюстрирует конфигурацию в соответствии с примерным вариантом осуществления настоящего изобретения.
Фиг. 2 иллюстрирует конфигурацию системы связи в соответствии с первым примерным вариантом осуществления настоящего изобретения.
Фиг. 3 иллюстрирует конфигурацию коммутатора OpenFlow (OFS) в соответствии с первым примерным вариантом осуществления настоящего изобретения.
Фиг. 4 иллюстрирует примерную конфигурацию таблицы событий, хранимой в коммутаторе OpenFlow (OFS), в соответствии с первым примерным вариантом осуществления настоящего изобретения.
Фиг. 5 иллюстрирует операции коммутаторов OpenFlow (OFS) в соответствии с первым примерным вариантом осуществления настоящего изобретения.
Фиг. 6 иллюстрирует операции коммутаторов OpenFlow (OFS) в соответствии с первым примерным вариантом осуществления настоящего изобретения.
Фиг. 7 иллюстрирует другую примерную конфигурацию таблицы событий, хранимой в коммутаторе OpenFlow (OFS), в соответствии с первым примерным вариантом осуществления настоящего изобретения.
Фиг. 8 иллюстрирует конфигурацию системы связи в соответствии со вторым примерным вариантом осуществления настоящего изобретения.
Фиг. 9 иллюстрирует примерную конфигурацию таблицы событий, хранимой в коммутаторе OpenFlow (OFS), в соответствии со вторым примерным вариантом осуществления настоящего изобретения.
Фиг. 10 иллюстрирует операции коммутаторов OpenFlow (OFS) в соответствии с первым примерным вариантом осуществления настоящего изобретения.
Фиг. 11 иллюстрирует операции коммутаторов OpenFlow (OFS) в соответствии со вторым примерным вариантом осуществления настоящего изобретения.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
[0020] Сначала со ссылкой на чертежи будет описано краткое содержание примерного варианта осуществления настоящего изобретения. В следующем кратком содержании различные компоненты для удобства обозначаются номерами ссылочных позиций. То есть нижеследующие номера ссылочных позиций используются лишь как примеры для упрощения понимания настоящего изобретения, а не для ограничения настоящего изобретения проиллюстрированными вариантами.
[0021] Как проиллюстрировано на фиг. 1, примерный вариант осуществления настоящего изобретения можно реализовать с помощью узла 10 связи, включающего в себя: блок 12 обработки пакетов, который обрабатывает принятые пакеты путем обращения к первой таблице 11, которая хранит запись(и), задающую условия соответствия, с которыми сопоставляются принятые пакеты, и содержимое обработки, применяемое к пакетам, которые соответствуют условиям соответствия; и независимый функциональный блок 14, который обращается ко второй таблице 13 и который перезаписывает запись(и) в первой таблице на основании наступившего события(ий).
[0022] Точнее говоря, во второй таблице 13 событие(я), которое можно обнаружить посредством узла связи, ассоциировано с изменением(ями), применяемым к записи(ям), сохраненной в первой таблице 11, когда обнаружено наступление события(ий). Независимый функциональный блок 14 перезаписывает запись(и) в первой таблице 11 на основании наступившего события(ий).
[0023] Посредством вышеупомянутой обработки узел 10 связи может без запроса устройства управления изменить обработку, применяемую к принятым пакетам, на основании наступившего события(ий).
[0024] Первый примерный вариант осуществления
Далее будет подробно описан первый примерный вариант осуществления настоящего изобретения со ссылкой на чертежи. Фиг. 2 иллюстрирует конфигурацию системы связи в соответствии с первым примерным вариантом осуществления настоящего изобретения. Как проиллюстрировано на фиг. 2, система связи включает в себя: коммутаторы 101 и 102 OpenFlow (OFS), которые размещены на границах двух сетей 301 и 302; контроллер 200 OpenFlow (OFC), который соединен с OFS 101 и 102 по каналам 501 и 502 управления и который управляет OFS 101 и 102; и терминалы 401 и 402, которые соединены соответственно с OFS 101 и 102 и которые осуществляют связь друг с другом.
[0025] OFS 101 и 102 являются коммутаторами OpenFlow, обладающими функцией Ether-OAM, и работают путем обращения к записям в таблицах потоков и событий, заданных посредством OFC 200. Функция Ether-OAM является функцией эксплуатации, администрирования и обслуживания для сети Ethernet (зарегистрированный товарный знак), определенной в ITU-T Y.1731, IEEE 802.1ag и т.п.
[0026] OFC 200 обменивается управляющими сообщениями с OFS 101 и 102 по каналам 501 и 502 управления и добавляет записи в таблицы потоков и событий (которые будут описаны ниже) в OFS 101 и 102.
[0027] Фиг. 3 иллюстрирует подробную конфигурацию OFS 101/102. Как проиллюстрировано на фиг. 3, OFS 101/102 включает в себя таблицу 111 потоков, блок 112 обработки пакетов, таблицу 113 событий, независимый функциональный блок 114, блок 115 связи по протоколу и блок 116 контроля.
[0028] Таблица 111 потоков соответствует вышеупомянутой первой таблице, хранящей запись(и), задающую условия соответствия, с которыми сопоставляются принятые пакеты, и содержимое обработки, применяемое к пакетам, которые соответствуют условиям соответствия. Может быть включено множество таблиц 111 потоков, как раскрыто в NPL 2.
[0029] При приеме пакета извне, блок 112 обработки пакетов ищет в таблице 111 потоков запись, имеющую условия соответствия, которые соответствуют входному порту или информации заголовка у принятого пакета. В результате поиска, если блок 112 обработки пакетов находит запись, имеющую условия соответствия, которые соответствуют принятому пакету, то блок 112 обработки пакетов применяет к пакету содержимое обработки, заданное в той записи. В результате поиска, если блок 112 обработки пакетов не находит запись, имеющую условия соответствия, которые соответствуют принятому пакету, то блок 112 обработки пакетов выполняет заданную операцию, например отбрасывание пакета или перенаправление пакета к OFC 200. Если блок 112 обработки пакетов принимает уведомление о сбое Ether-OAM, то блок 112 обработки пакетов выводит уведомление о сбое Ether-OAM в независимый функциональный блок 114. Работу OFS 101/102, выполняемую, когда OFS 101/102 принимает уведомление о сбое Ether-OAM, можно реализовать путем задания записи(ей), которая дает команду вывода в виртуальный порт, соединенный с независимым функциональным блоком 114 в таблице 111 потоков.
[0030] Таблица 113 событий соответствует вышеупомянутой второй таблице, хранящей записи, в которых различные типы условий событий, которые можно обнаружить посредством OFS 101/102, ассоциируются с содержимым обработки (действиями по событию), выполняемым, когда наступают соответствующие события. Предпочтительно, чтобы OFC 200 задавал запись(и) в таблице 113 событий с использованием результата вычисления маршрута при создании записи(ей) в таблице 111 потоков. Конечно, администратор сети или т.п. может вручную задать запись(и) в таблице 113 событий. Поскольку вероятно, что к таблице 113 событий обращаются или перезаписывают ее менее часто, нежели таблицу 111 потоков, таблицу 113 событий не нужно конфигурировать с помощью CAM или т.п., в отличие от таблицы 111 потоков.
[0031] Если наступает состояние (например, сбой), которое соответствует условию события, записанному в таблице 113 событий, то независимый функциональный блок 114 выполняет содержимое обработки (действие(я) по событию), заданное в соответствующей записи. К тому же если запись(и) в таблице 111 потоков изменяется в результате выполнения содержимого обработки (действие(я) по событию), заданного в записи в таблице 113 событий, то независимый функциональный блок 114 уведомляет OFC 200 о выполненном содержимом обработки или об изменении(ях), внесенном в таблицу 111 потоков. Таким образом, может поддерживаться согласованность между записью(ями) о потоке, про которую OFC 200 знает в OFS 101/102, и записью(ями) о потоке, фактически заданной в OFS 101/102.
[0032] Фиг. 4 иллюстрирует примерную конфигурацию таблицы событий, хранимой в OFS 101. В примере на фиг. 4 при приеме уведомления о сбое Ether-OAM из сети A (сеть 301 на фиг. 2) OFS 101 извлекает из таблицы 111 потоков запись, указывающую перенаправление в сеть A, и меняет записанного в той записи адресата перенаправления на сеть B (сеть 302 на фиг. 2) (см. первую запись). Также при приеме уведомления о сбое Ether-OAM из сети B (сеть 302 на фиг. 2) OFS 101 извлекает из таблицы 111 потоков запись, указывающую перенаправление в сеть B, и меняет записанного в той записи адресата перенаправления на сеть A (сеть 301 на фиг. 2) (см. вторую запись).
[0033] Блок 115 связи по протоколу является средством для осуществления связи с OFC 200 с использованием, например, протокола OpenFlow в NPL 2.
[0034] Блок 116 контроля контролирует рабочие состояния и состояния линий связи у соответствующего OFS. Если блок 116 контроля обнаруживает неисправность или восстановление, то блок 116 контроля передает уведомление о сбое Ether-OAM или уведомление о восстановлении после сбоя Ether-OAM другому OFS (другим OFS), и т.п.
[0035] Каждый блок (средство обработки) в OFS 101/102, проиллюстрированный на фиг. 3, можно реализовать с помощью компьютерной программы, которая предписывает установленному в OFS компьютеру использовать свои аппаратные средства и выполнить соответствующую обработку, как описано выше.
[0036] Далее со ссылкой на чертежи будет подробно описана работа в соответствии с настоящим примерным вариантом осуществления. Нижеследующее описание будет выполнено при условии, что каждая из таблиц 111 потоков в соответствующих OFS 101 и 102 включает в себя запись для перенаправления пакетов, передаваемых между терминалами 401 и 402 по сети 301, как указано двунаправленной стрелкой на фиг. 5.
[0037] Если в сети 301 на фиг. 5 возникает сбой и если OFS 101 принимает уведомление о сбое Ether-OAM от OFS или т.п. в сети 301, то OFS 101 начинает перенаправлять пакеты, передаваемые между терминалами 401 и 402 по сети 302, в соответствии с записью, которая соответствует соответствующему условию события в таблице 113 событий. Точнее говоря, OFS 101 обращается к соответствующей записи в таблице 111 потоков, задающей адресата перенаправления пакетов, адресованных терминалу 402 от терминала 401, и меняет адресата перенаправления с OFS, принадлежащего сети 301, например, на OFS, принадлежащий сети 302. Если входной порт в условиях соответствия в записи для обработки пакетов, адресованных терминалу 401 от терминала 402, представляет порт, соединенный с сетью 301, при необходимости, то OFS 101 меняет входной порт в записи с порта, подключенного к сети 301, на порт, соединенный с сетью 302.
[0038] OFS 102 также вносит необходимые изменения, чтобы пакеты между терминалами 401 и 402 перенаправлялись по сети 302.
[0039] Таким образом, как проиллюстрировано на фиг. 6, маршруты перенаправления пакетов между терминалами 401 и 402 можно переключать без необходимости в управлении от OFC 200. Таким образом, даже когда в сети 301 возникает сбой, можно быстро возобновить связь.
[0040] К тому же в соответствии с настоящим примерным вариантом осуществления, поскольку можно уменьшить количество управляющих сообщений, которыми обмениваются между OFC и OFS, можно, например, избежать затора в каналах 501 и 502 управления. При базовой конфигурации в NPL 2, если в сети возникает сбой и если множество OFS соединены с сетью, то эти OFS передают запрос (сообщение Packet-In) к OFC 200 для регистрации записи в их таблицах 111 потоков. В ответ OFC 200 создает запись для каждого OFS и передает им запись. В соответствии с настоящим примерным вариантом осуществления необходимо всего лишь, чтобы независимый функциональный блок 114 в отдельном OFS уведомил OFC 200 об изменении (изменениях), внесенном в таблицу 111 потоков. Таким образом, объем связи уменьшается по меньшей мере наполовину.
[0041] В результате задания записей в таблице 113 событий отдельный OFS может сам выполнять операцию восстановления из состояния, проиллюстрированного на фиг. 6, в состояние, проиллюстрированное на фиг. 5. Фиг. 7 иллюстрирует примерные записи для операции восстановления, которые хранятся в таблице событий. В примере на фиг. 7 при приеме уведомления о восстановлении после сбоя Ether-OAM из сети B (сеть 302 на фиг. 2) OFS 101 извлекает из таблицы 111 потоков запись, указывающую перенаправление в сеть B, и меняет записанного в той записи адресата перенаправления на сеть A (сеть 301 на фиг. 2) (см. первую запись на фиг. 7). Также при приеме уведомления о восстановлении после сбоя Ether-OAM из сети A (сеть 301 на фиг. 2) OFS 101 извлекает из таблицы 111 потоков запись, указывающую перенаправление в сеть A, и меняет записанного в той записи адресата перенаправления на сеть B (сеть 302 на фиг. 2) (см. вторую запись на фиг. 7).
[0042] Таким образом, маршрут перенаправления пакетов между терминалами 401 и 402 на фиг. 6 можно переключить обратно на маршрут, проиллюстрированный на фиг. 5, без управления от OFC 200. Таким образом, даже когда, например, в сети 301 возникает сбой и временно используется сеть 302, можно быстро выполнить операцию восстановления.
[0043] Второй примерный вариант осуществления
Далее будет описан второй примерный вариант осуществления. Во втором примерном варианте осуществления такие же OFS, как использовались в вышеприведенном первом примерном варианте осуществления, используются для осуществления отработки отказа между серверами. Поскольку настоящий примерный вариант осуществления можно реализовать с помощью такой же конфигурации, как и в соответствии с первым примерным вариантом осуществления, настоящий примерный вариант осуществления будет описан с сосредоточением на различии.
[0044] Фиг. 8 иллюстрирует конфигурацию системы связи в соответствии со вторым примерным вариантом осуществления настоящего изобретения. Как проиллюстрировано на фиг. 8, система связи включает в себя: коммутаторы 101 и 102 OpenFlow (OFS), которые размещаются на границах сети 301; контроллер 200 OpenFlow (OFC), который соединен с OFS 101 и 102 по каналам 501 и 502 управления и который управляет OFS 101 и 102; терминал 401, который соединен и осуществляет связь с OFS 101 и 102; сервер 701, который предоставляет услугу (услуги) в ответ на запрос (запросы) от терминала 401; и сервер 702, который может продолжить обработку вместо сервера 701.
[0045] Фиг. 9 иллюстрирует примерную конфигурацию таблицы событий, хранимой в OFS 102 на фиг. 8. В примере на фиг. 9, когда блок 116 контроля обнаруживает неисправность сервера, OFS 102 извлекает из таблицы 111 потоков запись, указывающую перенаправление к серверу 701, и меняет записанного в той записи адресата перенаправления на сервер 702 (см. первую запись).
[0046] Далее со ссылкой на чертежи будет подробно описана работа в соответствии с настоящим примерным вариантом осуществления. Нижеследующее описание будет выполнено при условии, что каждая из таблиц 111 потоков в соответствующих OFS 101 и 102 включает в себя запись для перенаправления пакетов, передаваемых между терминалом 401 и сервером 701 по сети 301, как указано двунаправленной стрелкой на фиг. 10.
[0047] При обнаружении возникновения сбоя на сервере 701 на фиг. 8 OFS 102 изменяет записи так, чтобы пакеты, адресованные серверу 701 от терминала 401, передавались серверу 702, а ответы от сервера 702 перенаправлялись в терминал 401. Точнее говоря, OFS 102 обращается к записи в таблице 111 потоков, задающей адресата перенаправления пакетов, адресованных серверу 701 от терминала 401, и меняет адресата перенаправления на порт, соединенный с сервером 702. К тому же OFS 102 добавляет в таблицу 111 потоков запись для обработки ответных пакетов, адресованных терминалу 401 от сервера 702.
[0048] Также предпочтительно, чтобы OFS 102 преобразовал адрес сервера 701, который задается как адресат или источник в заголовочной части пакета, в адрес сервера 702. Таким образом, OFS 101 не нужно изменять записи в своей таблице 111 потоков.
[0049] Следовательно, маршруты перенаправления пакетов между терминалом 401 и сервером 701 можно переключать без управления от OFC 200, как проиллюстрировано на фиг. 11. Таким образом, даже когда на сервере 701 возникает сбой, можно быстро предоставить услугу (услуги) от сервера 702 без перерыва.
[0050] Хотя таким образом описаны примерные варианты осуществления настоящего изобретения, настоящее изобретение этим не ограничено. Могут быть внесены дополнительные изменения, замены или исправления без отклонения от основной технической концепции настоящего изобретения. Например, проиллюстрированные на чертежах конфигурации сетей и элементов используются только в качестве примеров для упрощения понимания настоящего изобретения. То есть настоящее изобретение не ограничено конфигурациями, проиллюстрированными на чертежах.
[0051] Хотя в вышеприведенных примерных вариантах осуществления используются OFC и OFS в NPL 1 и 2, настоящее изобретение также применимо к типу сети с централизованным управлением, в которой, например, плоскость управления и плоскость данных отделены друг от друга.
[0052] К тому же, хотя в вышеприведенных примерных вариантах осуществления отдельный OFS использует одну таблицу событий, отдельный OFS может выбрать другую конфигурацию таблиц. Например, как и в конвейерной обработке, использующей множество таблиц потоков в NPL 2, отдельный OFS может последовательно обращаться к множеству таблиц и в конечном счете выбрать запись, которая соответствует множеству условий, чтобы определить действие(я) по событию. Таким образом, отдельная таблица событий может иметь меньший размер, и ей может быть легче управлять.
[0053] К тому же, хотя в вышеприведенных примерных вариантах осуществления переключение маршрутов и отработка отказа выполняются с использованием таблицы 113 событий, также возможны другие разновидности. Например, некоторую запись(и) в таблице(ах) потоков можно удалить или содержимое обработки в некоторой записи(ях) в таблице(ах) потоков можно перезаписать на отбрасывание пакетов (Drop).
[0054] К тому же, хотя в вышеприведенных примерных вариантах осуществления отдельный OFS обладает функцией Ether-OAM, настоящее изобретение также применимо при условии, что отдельный OFS обладает другой эквивалентной функцией. Например, похожие полезные результаты можно ожидать путем задания записи для изменения адресата перенаправления пакетов в соответствующей таблице 111 потоков в таблице 113 событий, когда обнаруживается неисправность линии связи у порта. К тому же возможна другая операция. Например, когда обнаруживается сбой в канале управления с OFC или т.п., соответствующим OFS можно управлять с помощью другого OFC (OFS перенаправляет пакеты к другому OFC и просит другой OFC передать записи о потоках).
[0055] Наконец, будут обобщены подходящие варианты настоящего изобретения.
[Вариант 1]
(см. узел связи по вышеупомянутому первому аспекту)
[Вариант 2]
Узел связи по варианту 1;
причем узел связи принимает записи для сохранения в первой таблице(ах) и второй таблице(ах) от заданного устройства(в) управления.
[Вариант 3]
Узел связи по варианту 2;
причем узел связи уведомляет заданное устройство(а) управления о перезаписанном содержимом, когда узел связи обращается ко второй таблице(ам) и перезаписывает запись(и) в первой таблице(ах).
[Вариант 4]
Узел связи по любому из вариантов 1-3;
причем во второй таблице(ах) задается запись(и) для переключения маршрута(ов) перенаправления пакетов, который затрагивается сбоем(ями), на другой маршрут(ы) при обнаружении сбоя(ев) в сети.
[Вариант 5]
Узел связи по любому из вариантов 1-3;
причем во второй таблице(ах) задается запись(и) для изменения адресата(ов) перенаправления пакетов в записи(ях) в первой таблице(ах), который затронут сбоем(ями), на альтернативное устройство(а) адресата(ов) связи, когда обнаружен сбой(и) у адресата(ов) связи.
[Вариант 6]
(см. систему связи по вышеупомянутому второму аспекту)
[Вариант 7]
(см. способ обработки пакетов по вышеупомянутому третьему аспекту)
[Вариант 8]
(см. программу по вышеупомянутому четвертому аспекту)
Варианты 6-8 можно развить точно так же, как вариант 1 развивается до вариантов 2-5.
[0056] Содержимое каждого из вышеприведенных PTL и NPL включено в настоящий документ путем ссылки на них. Возможны модификации и изменения примерных вариантов осуществления и примеров в рамках объема всего описания настоящего изобретения (включая формулу изобретения) и на основании основной технической концепции настоящего изобретения. К тому же в рамках описания настоящего изобретения возможны различные сочетания и выборки различных раскрытых элементов (включая элементы в каждом из пунктов формулы изобретения, в примерных вариантах осуществления, примерах, чертежах и т.п.). То есть настоящее изобретение, конечно, включает в себя различные изменения и модификации, которые могут внести специалисты в данной области техники в соответствии с общим описанием изобретения, включая формулу изобретения и техническую концепцию. В частности, настоящее описание раскрывает диапазоны численных значений. Однако, даже если описание подробно не раскрывает произвольные численные значения или небольшие диапазоны, включенные в те диапазоны, эти значения и диапазоны следует считать конкретно раскрытыми.
СПИСОК ССЫЛОЧНЫХ ПОЗИЦИЙ
[0057] 10 узел связи
11 первая таблица
12 блок обработки пакетов
13 вторая таблица
14 независимый функциональный блок
101, 102 коммутатор OpenFlow (OFS)
111 таблица потоков
112 блок обработки пакетов
113 таблица событий
114 независимый функциональный блок
115 блок связи по протоколу
116 блок контроля
200 контроллер OpenFlow (OFC)
301, 302 сеть
401, 402 терминал
501, 502 канал управления
701, 702 сервер