JP6191703B2 - 通信制御システム、通信制御方法および通信制御プログラム - Google Patents

通信制御システム、通信制御方法および通信制御プログラム Download PDF

Info

Publication number
JP6191703B2
JP6191703B2 JP2015561200A JP2015561200A JP6191703B2 JP 6191703 B2 JP6191703 B2 JP 6191703B2 JP 2015561200 A JP2015561200 A JP 2015561200A JP 2015561200 A JP2015561200 A JP 2015561200A JP 6191703 B2 JP6191703 B2 JP 6191703B2
Authority
JP
Japan
Prior art keywords
domain
controller
communication
adjacent
ofc
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
JP2015561200A
Other languages
English (en)
Other versions
JPWO2015118822A1 (ja
Inventor
飛 高
飛 高
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Publication of JPWO2015118822A1 publication Critical patent/JPWO2015118822A1/ja
Application granted granted Critical
Publication of JP6191703B2 publication Critical patent/JP6191703B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/48—Routing tree calculation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • 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/02—Topology update or discovery
    • H04L45/036—Updating the topology between route computation elements, e.g. between OpenFlow controllers
    • 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/02—Topology update or discovery
    • 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/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • 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/12—Shortest path evaluation
    • 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/18—Loop-free operations
    • 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

Landscapes

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

Description

本発明は、複数の通信装置を管理するコントローラ間の通信制御を行う通信制御システム、通信制御方法および通信制御プログラムに関する。
複数の通信機器を一つの制御装置で集中管理する技術として、オープンフローが広く知られている。オープンフローでは、１台以上のオープンフロースイッチ（Open Flow Switch。以下、ＯＦＳと記す。）を、オープンフローコントローラ（Open Flow Controller。以下、ＯＦＣと記す。）が制御する。また、近年、ＯＦＣが制御可能なＯＦＳの台数や、ＯＦＳの設置場所などの関係で、オープンフローを用いたネットワークを、複数のＯＦＣで管理する要求が高まっている。
特許文献１には、独自に負荷分散機能を持たないスイッチとコントローラの組合せや、メーカの違いにより負荷分散機能に互換性がないスイッチとコントローラの組合せにおいても、コントローラの負荷分散を可能にする負荷分散システムが記載されている。特許文献１に記載された負荷分散システムでは、スイッチとコントローラの間にプロキシが設置され、そのプロキシが、１つのスイッチからの接続を複数のコントローラに通知しつつ、そのスイッチに対してマスタとなる１つのコントローラを決定し、そのスイッチからの問合せメッセージを、マスタとなる１つのコントローラのみに転送する。
再特ＷＯ２０１１−０６５２６８号公報
一般にＯＦＣは、他のＯＦＣが管理するＯＦＳ群との繋がりを意識せず、自身が管理している配下のトポロジを検出する。以下、ＯＦＣが管理するＯＦＳ群のことを、ＯＦＣドメインと記す。すなわち、ＯＦＣは、ＯＦＣごとに検出された自ＯＦＣドメインのトポロジをベースとして、ＢＣＭＣ（Ｂｒｏａｄｃａｓｔ ａｎｄ Ｍｕｌｔｉｃａｓｔ）、Ｕｎｋｏｎｗｎ ｕｎｉｃａｓｔ、Ｕｎｉｃａｓｔ転送をＯｐｅｎＦｌｏｗプロトコルで制御する。しかし、ＯＦＣが自ＯＦＣドメインのトポロジのみを検出して制御を行う場合、以下の課題が発生する。
図１１は、２つのＯＦＣドメイン間を複数の回線で接続した場合の例を示す説明図である。図１１に示す例では、ＯＦＣ１ドメイン１１０と、ＯＦＣ２ドメイン１２０が、２本の回線Ｃ４１および回線Ｃ４２で接続されている。ＯＦＣ１ドメイン１１０は、ＯＦＣ１によって管理されるドメインであり、ＯＦＣ２ドメイン１２０は、ＯＦＣ２によって管理されるドメインである。
ＯＦＣ１ドメイン１１０は、４つのＯＦＳ（ＯＦＳ１〜４）を含む。ＯＦＣ１ドメイン１１０において、ＯＦＳ１とＯＦＳ２は、回線Ｃ１１で接続され、ＯＦＳ１とＯＦＳ３は、回線Ｃ１２で接続され、ＯＦＳ２とＯＦＳ４は、回線Ｃ１３で接続され、ＯＦＳ３とＯＦＳ４は、回線Ｃ１４で接続される。また、クライアントＰＣ（Personal Computer ）２１０が、ＯＦＣ１ドメイン１１０のＯＦＳ１に接続されている。
ＯＦＣ２ドメイン１２０も同様に、４つのＯＦＳ（ＯＦＳ１〜４）を含む。ＯＦＣ２ドメイン１２０において、ＯＦＳ１とＯＦＳ２は、回線Ｃ２１で接続され、ＯＦＳ１とＯＦＳ３は、回線Ｃ２２で接続され、ＯＦＳ２とＯＦＳ４は、回線Ｃ２３で接続され、ＯＦＳ３とＯＦＳ４は、回線Ｃ２４で接続される。
ＯＦＣ１は、ＯＦＣ１ドメイン１１０のトポロジを検出（ディスカバリ）し、ＯＦＣ２は、ＯＦＣ２ドメイン１２０のトポロジを検出（ディスカバリ）する。さらに、ＯＦＣ１は、自ドメイン内の回線Ｃ１４を遮断（ブロック）し、また、ＯＦＣ２は、自ドメイン内の回線Ｃ２３を遮断（ブロック）するように、論理スパニングツリーを構築している。
図１１に例示する環境の場合、ＰＣ２１０からＢＣＭＣパケットが送信されても、ＢＣＭＣパケットは、各ＯＦＳドメイン内でループされなくなる。
しかし、回線Ｃ４１、回線Ｃ２２、回線Ｃ４２および回線Ｃ１３は、遮断されていないため、ＯＦＣドメインを跨いだこれらの回線では、ループが発生する。そのため、図１１に例示するシステム全体で、ＢＣＭＣストームが発生してしまう。
このような課題を解決する方法として、ＭＣＬＡＧ（Ｍｕｌｔｉ−Ｃｈａｓｓｉｓ Ｌｉｎｋ Ａｇｇｒｅｇａｔｉｏｎ Ｇｒｏｕｐ）という技術が知られている。この技術を用いた場合、回線Ｃ４１と回線Ｃ４２を論理的に一本のリンクとして扱うことができるため、図１１に例示するループの発生を回避することは可能である。
しかし、ＭＣＬＡＧ技術を用いた場合であっても、３つ以上のＯＦＣドメインが接続されたネットワークでループを回避することは困難である。図１２は、３つのＯＦＣドメインが接続された場合の例を示す説明図である。
図１２に示す例では、ＯＦＣ１ドメイン１１０と、ＯＦＣ２ドメイン１２０に加えて、さらに、ＯＦＣ３ドメイン１３０が存在する。ＯＦＣ３ドメイン１３０は、ＯＦＣ３によって管理されるドメインである。ＯＦＣ１ドメイン１１０とＯＦＣ３ドメイン１３０は、回線Ｃ４３で接続され、ＯＦＣ２ドメイン１２０とＯＦＣ３ドメイン１３０は、回線Ｃ４４で接続される。
ＯＦＣ３ドメイン１３０も、４つのＯＦＳ（ＯＦＳ１〜４）を含む。ＯＦＳ１とＯＦＳ２は、回線Ｃ３１で接続され、ＯＦＳ１とＯＦＳ３は、回線Ｃ３２で接続され、ＯＦＳ２とＯＦＳ４は、回線Ｃ３３で接続され、ＯＦＳ３とＯＦＳ４は、回線Ｃ３４で接続される。さらに、図１２に示す例では、ＯＦＣ１ドメイン１１０とＯＦＣ２ドメイン１２０は、回線Ｃ４１および回線Ｃ４２を用いて作成されるＭＣＬＡＧで接続される。
この場合、ＰＣ１から送信されるＢＣＭＣパケットは、回線Ｃ４１および回線Ｃ４２を用いて作成されるＭＣＬＡＧ、回線Ｃ４３および回線Ｃ４４のリンクを経由することにより、ＯＦＣ１ドメイン１１０、ＯＦＣ２ドメイン１２０およびＯＦＣ３ドメイン１３０の間でループになる。そのため、図１２に例示するシステム全体で、ＢＣＭＣストームが発生してしまう。
このように、一般的な通信ネットワークでは、複数のＯＦＣドメイン間の接続を冗長構成にすることは困難である。そのため、全ＯＦＣドメイン間の繋がりを配慮し、ループ構成を排除するようなトポロジを構築することが望まれる。
また、特許文献１に記載された負荷分散システムでは、このような状況を想定していない。そのため、複数のＯＦＣを利用したオープンフローのネットワーク環境であっても、ＯＦＣドメインを跨いだ通信を複数の経路に負荷分散させたり、最適な経路を算出したりすることが望まれている。
そこで、本発明は、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる通信制御システム、通信制御方法および通信制御プログラムを提供することを目的とする。
本発明による通信制御システムは、各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段と、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成するループ解決手段と、各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定手段と、ネットワークトポロジを利用して、通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段とを備えたことを特徴とする。
本発明による他の通信制御システムは、各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、複数のオープンフローコントローラと、オープンフローコントローラからの通信が到達するように接続され、コントローラドメイン間の通信経路を示す通信ツリーを作成するトポロジマネージャとを備え、オープンフローコントローラが、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段と、特定した隣接するコントローラドメインを示す情報を、トポロジマネージャに送信する隣接ドメイン情報送信手段と、トポロジマネージャが算出したネットワークトポロジに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段とを含み、トポロジマネージャが、オープンフローコントローラから受信した情報に基づいて、各コントローラドメイン間のネットワークトポロジを特定し、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する通信ツリー作成手段と、作成した通信ツリーをオープンフローコントローラに配信するネットワークトポロジ配信手段とを含むことを特徴とする。
本発明による通信制御方法は、各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御方法であって、自コントローラドメインに隣接するコントローラドメインを特定し、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成し、各コントローラドメイン間のネットワークトポロジを特定し、ネットワークトポロジを利用して、通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御することを特徴とする。
本発明による通信制御プログラムは、各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御するコンピュータに適用される通信制御プログラムであって、コンピュータに、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定処理、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成するループ解決処理、各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定処理、および、ネットワークトポロジを利用して、通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御処理を実行させることを特徴とする。
本発明によれば、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
本発明による通信制御システムの第１の実施形態の構成例を示すブロック図である。 本実施形態の通信制御システムで用いられるＯＦＣの構成例を示すブロック図である。 パケットのタイプがＮＡＤであるＯＦＣＮＤパケットによって伝搬される情報の例を示す説明図である。 パケットのタイプがＮＲＳであるＯＦＣＮＤパケットによって伝搬される情報の例を示す説明図である。 ＯＦＣが複数のＯＦＳ群を管理している状態を示す説明図である。 ＯＦＣＴＤＤＵパケットの例を示す説明図である。 ＯＦＳＤＡパケットとＯＦＳＤＤパケットの例を示す説明図である。 本発明による通信制御システムの第２の実施形態の構成例を示す説明図である。 本発明による通信制御システムの概要を示すブロック図である。 本発明による通信制御システムの他の概要を示すブロック図である。 ２つのＯＦＣドメイン間を複数の回線で接続した場合の例を示す説明図である。 ３つのＯＦＣドメインが接続された場合の例を示す説明図である。
以下、本発明の実施形態を図面を参照して説明する。
実施形態１．
図１は、本発明による通信制御システムの第１の実施形態の構成例を示す説明図である。また、図２は、本実施形態の通信制御システムで用いられるＯＦＣの構成例を示すブロック図である。以下の説明では、通信ネットワーク内には、３つのＯＦＣドメイン（ＯＦＣドメイン１１０，１２０，１３０）と各ＯＦＣドメインにおけるＯＦＣに管理されるそれぞれ４台のＯＦＳが含まれるものとする。すなわち、以下で説明する環境は、３台のＯＦＣを含むマルチコントローラ環境である。
ただし、通信制御システムに含まれるＯＦＣドメインの数は３つに限定されず、４つ以上であってもよい。また、各ＯＦＣドメインに含まれるＯＦＳの数は４つに限定されず、１〜３つであってもよく、５つ以上であってもよい。
また、図１に例示する通信制御システムにおいて、ＰＣ２１１は、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ１のｐｏｒｔ１にｃｏｓｔ＝１で接続され、ＰＣ２１２は、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ３のｐｏｒｔ１にｃｏｓｔ＝１で接続される。また、ＰＣ２３１は、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ４のｐｏｒｔ１にｃｏｓｔ＝１で接続され、ＰＣ２３２は、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ３のｐｏｒｔ１にｃｏｓｔ＝１で接続される。
さらに、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ２のｐｏｒｔ１は、ＯＦＣ２ドメイン１２０に含まれるＯＦＳ１のｐｏｒｔ１とｃｏｓｔ＝１で接続され、ＯＦＣ２ドメイン１２０に含まれるＯＦＳ１のｐｏｒｔ１は、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ２のｐｏｒｔ１とｃｏｓｔ＝１で接続される。また、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ４のｐｏｒｔ１は、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ１のｐｏｒｔ１とｃｏｓｔ＝２で接続され、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ１のｐｏｒｔ１は、ＯＦＣ１ドメイン１１０に含まれるＯＦＳ４のｐｏｒｔ１とｃｏｓｔ＝１で接続される。また、ＯＦＣ２ドメイン１２０に含まれるＯＦＳ３のｐｏｒｔ１は、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ２のｐｏｒｔ１とｃｏｓｔ＝１で接続され、ＯＦＣ３ドメイン１３０に含まれるＯＦＳ２のｐｏｒｔ１は、ＯＦＣ２ドメイン１２０に含まれるＯＦＳ３のｐｏｒｔ１とｃｏｓｔ＝１で接続される。
図２は、本実施形態のＯＦＣの機能モジュール構成を示している。図２に例示するＯＦＣ１００は、ＯＦＣドメインを制御する。図２に例示するＯＦＣ１００は、図１に例示するＯＦＣ１、ＯＦＣ２およびＯＦＣ３に対応する。ＯＦＣ１００は、経路計算モジュール１０と、トポロジ管理モジュール２０と、メッセージ解析モジュール３０と、メッセージ送受信モジュール４０とを備えている。
メッセージ送受信モジュール４０は、オープンフローメッセージを送受信するモジュールである。
メッセージ解析モジュール３０は、メッセージ送受信モジュール４０から受信したオープンフローメッセージを解析し、上位モジュール（経路計算モジュール１０およびトポロジ管理モジュール２０）に通知する。また、メッセージ解析モジュール３０は、上位モジュール（経路計算モジュール１０およびトポロジ管理モジュール２０）から発行されたＯＦＳ制御メッセージをオープンフローメッセージに変換し、メッセージ送受信モジュール４０に通知する。
トポロジ管理モジュール２０は、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２とを含む。
トポロジ管理モジュール２０（より具体的には、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２）は、プログラム（通信制御プログラム）に従って動作するコンピュータのＣＰＵによって実現される。例えば、プログラムは、ＯＦＣ１００の記憶部（図示せず）に記憶され、ＣＰＵは、そのプログラムを読み込み、プログラムに従って、トポロジ管理モジュール２０（より具体的には、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２）として動作してもよい。
また、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２とは、それぞれが専用のハードウェアで実現されていてもよい。また、ドメイン間トポロジ管理モジュール２１と、内部ドメイントポロジ管理モジュール２２がそれぞれ行う処理を、トポロジ管理モジュール２０がまとめて行ってもよい。
内部ドメイントポロジ管理モジュール２２は、ＯＦＣドメイン内のトポロジの探索およびトポロジの維持を行う。ＯＦＣドメイン内のトポロジを検索する方法は、ＯＦＣの実装によって異なるが、内部ドメイントポロジ管理モジュール２２は、一般的に知られた方法を用いてトポロジの探索およびトポロジの維持を行えばよい。ここでは、ＯＦＣが管理するＯＦＣドメイン内のトポロジの探索方法および維持方法について、詳細な説明を省略する。
ドメイン間トポロジ管理モジュール２１は、ＯＦＣドメイン間のトポロジの探索およびトポロジの維持を行う。また、ドメイン間トポロジ管理モジュール２１は、探索したトポロジの情報を経路計算モジュール１０に通知する。
経路計算モジュール１０は、ＭＡＣ（Media Access Control）・宛先ドメインテーブル記憶部１１と、ＭＡＣローカルテーブル記憶部１２と、ドメイン間トポロジ情報記憶部１３とを含む。ＭＡＣ・宛先ドメインテーブル記憶部１１、ＭＡＣローカルテーブル記憶部１２およびドメイン間トポロジ情報記憶部１３は、例えばメモリや、磁気ディスク等により実現される。また、経路計算モジュール１０は、プログラム（通信制御プログラム）に従って動作するコンピュータのＣＰＵによって実現される。
ドメイン間トポロジ情報記憶部１３は、ドメイン間トポロジ管理モジュール２１から通知されたシステム全体におけるＯＦＣドメイン間のトポロジ情報を保持する。
ＭＡＣローカルテーブル記憶部１２は、自ＯＦＣドメイン内で学習したＭＡＣ情報を保持する。ＭＡＣ情報は、自ＯＦＣドメイン内のＯＦＳの移動や消滅、新規学習により更新される。なお、トポロジ管理モジュール２０は、ＭＡＣ情報が消滅したり、新規にＭＡＣ情報を学習した場合、ＯＦＣＳＤＡ（OFC Source Domain Advertise ）を他のＯＦＣドメインにフラディングする。
ＭＡＣ・宛先ドメインテーブル記憶部１１は、他のＯＦＣドメインから収集した情報（例えば、ＯＦＣＳＤＡ）に基づいて生成されるＭＡＣ・宛先ドメインテーブルを記憶する。
以下、ドメイン間トポロジ管理モジュール２１が行う処理を、具体的に説明する。
（１）ネーバーディスカバリ段階
ドメイン間トポロジ管理モジュール２１は、自ＯＦＣドメインに隣接するＯＦＣドメインを特定し、他のＯＦＣドメインにおけるＯＦＣに通知する。ドメイン間トポロジ管理モジュール２１は、隣接するＯＦＣドメインを探索するため、ＯＦＣＮＤ（OFC Neighbor Discovery）パケットを使用する。
ＯＦＣＮＤパケットのうち、自ＯＦＣドメインから他のＯＦＣドメインに対して送信されるパケットのタイプはＮＡＤ（Neighbor Advertise）で識別され、他のＯＦＣドメインから自ＯＦＣドメインに対して送信されるパケットのタイプはＮＲＳ（Neighbor Response）で識別される。以下の説明では、パケットのタイプがＮＡＤのＯＦＣＮＤパケットをＯＦＣＮＡＤパケットと記すことがあり、パケットのタイプがＮＲＳのＯＦＣＮＤパケットをＯＦＣＮＲＳパケットと記すことがある。
図３は、パケットのタイプがＮＡＤであるＯＦＣＮＤパケットによって伝搬される情報の例を示す説明図である。また、図４は、パケットのタイプがＮＲＳであるＯＦＣＮＤパケットによって伝搬される情報の例を示す説明図である。
ＯＦＣＮＤメッセージは、タイプを示すＴｙｐｅフィールドおよびノード（Ｎｏｄｅ）の種類を示すＮｏｄｅフィールドを含む。Ｎｏｄｅフィールドは、ＯＦＣ Ｄｏｍａｉｎ ＩＤ、ＯＦＳ Ｄｏｍａｉｎ ＩＤ、ＯＦＳ ＩＤ、ＯＦＳ Ｐｏｒｔ ＩＤおよびＰｏｒｔ Ｌｉｎｋ Ｃｏｓｔの各フィールドを含む。
図３に示す例では、ＮｏｄｅフィールドにＯＮ（Ｏｒｉｇｉｎａｌ Ｎｏｄｅ）が設定されている。また、図３に例示するＯＦＣＮＤメッセージにおいて、ＯＦＣ Ｄｏｍａｉｎ ＩＤには、送信する自ドメインＩＤ、ＯＦＳ Ｄｏｍａｉｎ ＩＤには、送信するＯＦＳのドメインＩＤ、ＯＦＳ ＩＤには、送信するＯＦＳのＩＤ、ＯＦＳ Ｐｏｒｔ ＩＤには、送信するＯＦＳのポートＩＤ、Ｐｏｒｔ Ｌｉｎｋ Ｃｏｓｔには、送信するポートのリンクコストを示す情報がそれぞれ設定されている。
図４に示す例では、ＯＮが設定されたＮｏｄｅフィールド以外に、ＮＮ（Ｎｅｉｇｈｂｏｒ Ｎｏｄｅ）が設定されたＮｏｄｅフィールドが存在する。図４に例示するＯＦＣＮＤメッセージにおいて、図３に例示するＮｏｄｅフィールドのＮｏｄｅＩＤがＮＮに設定されている。
また、ＯＮが設定されたＮｏｄｅフィールドにおいて、ＯＦＣ Ｄｏｍａｉｎ ＩＤには、ＮＡＤを受信した隣接ＯＦＣドメインＩＤ、ＯＦＳ Ｄｏｍａｉｎ ＩＤには、ＮＡＤを受信した隣接ＯＦＳのドメインＩＤ、ＯＦＳ ＩＤには、ＮＡＤを受信した隣接ＯＦＳのＩＤ、ＯＦＳ Ｐｏｒｔ ＩＤには、ＮＡＤを受信した隣接ＯＦＳのポートＩＤ、Ｐｏｒｔ Ｌｉｎｋ Ｃｏｓｔには、ＮＡＤを受信した隣接ポートのリンクコストを示す情報がそれぞれ設定されている。
なお、ＮｏｄｅフィールドのＯＦＳ Ｄｏｍａｉｎ ＩＤは、１つのＯＦＣが複数の隔離したアイランド状態のＯＦＳ群を管理する場合において、それぞれのＯＦＳ群を識別するためのフィールドである。図５は、ＯＦＣが複数のＯＦＳ群を管理している状態を示す説明図である。図５に示す例では、ＯＦＣ１が、２つのＯＦＳドメインをそれぞれ管理していることを示す。このように、各ＯＦＣが、複数の隔離された（アイランド状態）のＯＦＳ群を管理していてもよい。
ＯＦＳ Ｄｏｍａｉｎ ＩＤは、ＯＦＣドメイン内でユニークなＩＤが割り振られ、ＯＦＣによって管理される。
なお、ＯＦＣ Ｄｏｍａｉｎ ＩＤも、通信制御システム内でユニークなＩＤが割り振られる。ＯＦＣ Ｄｏｍａｉｎ ＩＤを割り振る方法は任意である。例えば、ＯＦＣ Ｄｏｍａｉｎ ＩＤを各ＯＦＣに手動で設定してもよいし、ＯＦＣ間で自動的に割り振るようにしてもよいし、集中管理機能を持つ他の装置によって自動的に割り振られるようにしてもよい。
ＯＦＣＮＤパケットのフレームは、以下の条件を満たせば、その他のフォーマット等については、特に限定されない。
・ＭＡＣＳＡ（ＭＡＣ Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ）
ＯＦＣ ＯｐｅｎＦｌｏｗ Ｃｈａｎｎｅｌとして利用するＮＩＣ（Network Interface Card）のＭＡＣ
なお、クラスタ構成の場合、共有の仮想ＭＡＣ
・ＭＡＣＤＡ（ＭＡＣ Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ）
パケットのタイプがＮＡＤの場合、ＢＣ／ＭＣ
パケットのタイプがＮＲＳの場合、受信ＮＡＤのＭＡＣＳＡ
レガシースイッチの透過性があるＭＡＣＤＡ
・Ｅｔｈｅｒ Ｔｙｐｅ
レガシースイッチの透過性があるＥｔｈｅｒ Ｔｙｐｅ
各ＯＦＣがＯＦＣＮＡＤパケットを他のＯＦＣドメインに送信し、ＯＦＣＮＡＤを受信したＯＦＣがＯＦＣＮＡＤを送信したＯＦＣドメインに対してＯＦＣＮＲＳを回答することで、隣接するＯＦＣドメインの特定（ネーバーディスカバリ）を行う。
具体的には、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＮＡＤパケットを他のＯＦＣドメインに送信する。また、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＮＡＤを受信すると、ＯＦＣＮＡＤを送信したＯＦＣドメインに対してＯＦＣＮＲＳを回答する。
ドメイン間トポロジ管理モジュール２１は、送信したＯＦＣＮＡＤパケットに対して、正しいＯＦＣＮＲＳパケットを受信した場合、ＯＦＣＮＡＤパケットを送信したポートをネーバーあり外向きポート（隣接するＯＦＣドメインが存在するポート）として記録する。
次に、隣接するＯＦＣドメインの特定処理（ネーバーディスカバリ処理）について具体的に説明する。以下、ＯＦＣが管理するドメインをＯＦＣ−ＯＦＳドメインと記す。なお、本実施形態の説明では、ＯＦＣが管理するＯＦＳドメインは１つであるが、ＯＦＳドメインが２つ以上に場合についても同様である。
まず、内部ドメイントポロジ管理モジュール２２は、自ＯＦＣ−ＯＦＳドメインのトポロジを検出して、物理ＢＣＭＣ配信ツリーおよび論理ＢＣＭＣ配信ツリーを構築する。なお、自ドメイン内のトポロジを検出する方法および配信ツリーを構築する方法は広く知られており、ここでは説明を省略する。
初期状態において、外向きポートが外部ＯＦＣドメインとの接続している状況は不明であるため、外向きポート状態は接続不明であることを示す情報（例えば、０）に設定されている。そこで、内部ドメイントポロジ管理モジュール２２は、外向きポート状態が０に設定されている外向きポートからのＯＦＣＮＤ以外のパケットの送受信を禁止するように、フローエントリを設定する。
なお、自ＯＦＣドメイン内のトポロジを検知する際にＯＦＣＮＤと異なるタイプのパケットが使用される場合、内部ドメイントポロジ管理モジュール２２は、そのパケットの送受信をＯＦＣＮＤと同様に許可する設定を行えばよい。
内部ドメイントポロジ管理モジュール２２は、外向きポート状態をドメイン間トポロジ管理モジュール２１に通知する。
ドメイン間トポロジ管理モジュール２１は、外向きポート状態が０の外向きポートに関して、以下の条件を満たすＯＦＣＮＤパケットをパケットインさせるフローエントリ（ＯＦＣＮＤパケットインフロー）を登録する。
・ＯＦＣＮＤパケットを受信した場合、ＯＦＣにＰａｃｋｅｔ＿Ｉｎさせる。
内部ドメイントポロジ管理モジュール２２は、ＯＦＣＮＡＤパケットを全外向きポートにＰａｃｋｅｔ＿Ｏｕｔメッセージを用いて送信する。ＯＦＣＮＡＤパケットは、接続性がある外部ＯＦＣドメインに到達するため、ＯＦＣＮＤパケットインフローにマッチしてＯＦＣにＰａｃｋｅｔ＿Ｉｎされる。
ドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＮＡＤにおけるＭＡＣＳＡ、ＯＮ ＮｏｄｅにおけるＯＦＣ Ｄｏｍａｉｎ ＩＤおよびＯＦＳ Ｄｏｍａｉｎ ＩＤを、自ＭＡＣ、自ＯＦＣドメインＩＤおよびＯＦＣＮＡＤを受信したＯＦＳ Ｄｏｍａｉｎ ＩＤと比較する。
すべての項目が一致した場合、ドメイン間トポロジ管理モジュール２１は、ＯＮ ＮｏｄｅのＯＦＳ Ｐｏｒｔ ＩＤで識別されるポート、または、ＯＦＣＮＡＤを受信したＯＦＳのＰｏｒｔからのパケット転送を即時ブロックする。なお、どちらのポートをブロックするかは、ＯＦＣの実装に応じて定められればよい。
ＯＦＣＮＡＤパケットを受信すると、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＮＲＳパケットを、ＯＦＣＮＡＤパケットの受信ポートに送信する。ＯＦＣＮＲＳパケットは、ＯＦＣＮＡＤを送信したＯＦＣドメインに到達するため、ＯＦＣＮＤパケットインフローにマッチし、ＯＦＣにＰａｃｋｅｔ＿Ｉｎされる。
ドメイン間トポロジ管理モジュール２１は、自ＯＦＣドメインＩＤ、ＯＦＣＮＲＳを受信したＯＦＳドメインＩＤ、ＯＦＳ ＩＤおよびＰＯＲＴ ＩＤを、ＯＦＣＮＲＳにおけるＯＮ Ｎｏｄｅの情報と比較する。すべての項目が一致しない場合、受信したパケットを廃棄する。
一方、すべての項目が一致した場合、ドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＮＲＳのＯＮ Ｎｏｄｅ情報およびＮＮ Ｎｏｄｅ情報から、自管理配下のＯＦＣ−ＯＦＳドメインと、隣接するＯＦＣ−ＯＦＳドメインとが接続されていることを示す情報としてドメイン間トポロジ情報記憶部１３にネーバードメインＤＢを保持する。
さらに、ドメイン間トポロジ管理モジュール２１は、外部ＯＦＣ−ＯＦＳドメインと接続しているポートを、隣接するドメインが存在する外向きポートと判定し、外向きポート状態を２に設定する。すなわち、外向きポート状態に２が設定された外向きポートは、ネーバーディスカバリが完了し、隣接するドメインが存在することを示す。
事前に設定された一定の時間を経過し、タイムアウトが発生すると、ドメイン間トポロジ管理モジュール２１は、外向きポート状態に０が設定されている外向きポートについて、その外向きポート状態を１に設定する。すなわち、外向きポート状態に１が設定された外向きポートは、ネーバーディスカバリが完了し、隣接するドメインが存在しないことを示す。
以後、ドメイン間トポロジ管理モジュール２１は、外向きポート状態に１が設定された外向きポートを、隣接ドメインが存在しない外向きポートと認識する。ドメイン間トポロジ管理モジュール２１は、ＯＦＣが外向きポートに対して行う一般的な処理（例えば、パケットインを許可する処理、ＯＦＣ内部のＢＣＭＣツリーの要素として行う処理、など）をその外向きポートに関して行う。
ＯＦＣは、全外向きポートに対してＯＦＣＮＤを送受信することで、ネーバードメインＤＢを維持する。例えば、ＯＦＣＮＡＤに対する新たなＯＦＣＮＲＳを正しく受信した場合、ドメイン間トポロジ管理モジュール２１は、ネーバードメインＤＢを新しい情報で更新する。
一方、ＯＦＣＮＡＤに対するＯＦＣＮＲＳを正しく受信できない場合、ドメイン間トポロジ管理モジュール２１は、一定のリトライ処理を行い、該当の情報をネーバードメインＤＢから削除するなどの動作を行う。
なお、ここまでの処理において、隣接ドメインが存在する外向きポートでＯＦＣＮＤ以外のパケットを送受信する処理は、まだ禁止されている。
（２）ループディスカバリ段階
ドメイン間トポロジ管理モジュール２１は、通信経路内にループが存在するか否か判断する。以下の説明では、通信経路内のループのことを、閉鎖グラフと記すこともある。本実施形態では、ドメイン間トポロジ管理モジュール２１は、ループが存在するか否か判断する際に、ＯＦＣＤＵ（ＯＦＣ Ｄａｔａ Ｕｎｉｔ）パケットを利用する。
ＯＦＣＤＵは、ＳＴＰ（Spanning Tree Protocol）で用いられるＢＰＤＵ（Bridge Protocol Data Unit）パケットと同様のフォーマットである。ただし、ＢＰＤＵパケットがスイッチの情報の伝送に用いられるのに対し、本実施形態で用いられるＯＦＣＤＵパケットは、以下に例示する情報（具体的には、ＯＦＣ−ＯＦＳドメインの情報）の伝送に用いられる。
・Ｒｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤ
・送信ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤ
・Ｒｏｏｔ Ｐａｔｈ Ｃｏｓｔ（各ＯＦＣ−ＯＦＳドメインについて、ルートＯＦＣ−ＯＦＳドメインとのパスコスト）
ドメイン間トポロジ管理モジュール２１は、ＳＴＰと同様のアルゴリズムを用いて、ＯＦＣＤＵに対する処理を行う。以下、ループを回避するための処理を説明する。
ドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する全外向きポートに関して、以下の条件を満たすＯＦＣＤＵパケットをパケットインさせるフローエントリ（ＯＦＣＤＵパケットインフロー）を登録する。
・ＯＦＣＤＵパケットを受信した場合、ＯＦＣにＰａｃｋｅｔ＿Ｉｎさせる。
ドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する全外向きポートからＯＦＣＤＵを送受信する。ＯＦＣ同士でＯＦＣＤＵを送受信することにより、ＯＦＣは、Ｒｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎを決定する。
具体的には、ドメイン間トポロジ管理モジュール２１は、初めに、自身が管理するすべてのＯＦＣ−ＯＦＳ ＤｏｍａｉｎがＲｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎであると認識し、そのＯＦＣ−ＯＦＳ ＤｏｍａｉｎのＩＤをＯＦＣＤＵのＲｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤに設定する。そして、ドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する各外向きポートにＯＦＣＤＵを送信する。
各コントローラは、受信したＯＦＣＤＵのＲｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤを、自身が管理するＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤと比較する。自身が管理するＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤよりも、受信したＯＦＣＤＵのＲｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤが小さい場合、ドメイン間トポロジ管理モジュール２１は、自身がＲｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎではないと判断する。
この処理を繰り返すことで、各閉鎖グラフ上に、唯一のＲｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎが特定される。以後、Ｒｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎと特定されたＯＦＣのみ、ＯＦＣＤＵを送信する。それ以外のＯＦＣは、ＯＦＣＤＵを受信し、Ｐａｔｈ Ｃｏｓｔを加算して転送する。
Ｒｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎにおいて隣接ドメインが存在する外向きポートは、代表ポートになる。また、他のＯＦＣ−ＯＦＳ Ｄｏｍａｉｎにおいて、Ｒｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎに一番近い（Ｒｏｏｔ Ｐａｔｈ Ｃｏｓｔ）ポートは、Ｒｏｏｔ Ｐｏｒｔになる。
また、他の異なるＯＦＣ−ＯＦＳ Ｄｏｍａｉｎに存在する隣り合うポートについて、Ｒｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎに近いＯＦＣ−ＯＦＳ Ｄｏｍａｉｎのポートは、代表ポートになり、遠いポートは非代表ポートになる。
ドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する代表ポートに関して、ＯＦＣがポートに対して行う一般的な処理（例えば、パケットインを許可する処理、ＯＦＣ内部のＢＣＭＣツリーの要素として行う処理、など）を行う。このような処理を行うことで、ＳＴＰで構築されるようなループ構成を回避する（単一経路）の通信ツリーが構築される。以下、このような通信ツリーを、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅと記すこともある。
なお、上述の処理において、Ｒｏｏｔ Ｐａｔｈ Ｃｏｓｔが同一の場合、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＤＵにおける送信ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤ、受信ＯＦＳ ＩＤ、受信ＯＦＳ ＰｏｒｔＩＤを順次比較すればよい。
ドメイン間トポロジ管理モジュール２１は、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ ＴｒｅｅをＳＴＰで用いられる方法と同様の方法を用いて維持する。Ｒｏｏｔ ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎのドメイン間トポロジ管理モジュール２１は、例えば、一定間隔で継続的にＯＦＣＤＵを送信してもよい。また、一定時間内にＯＦＣＤＵを受信できない場合、ドメイン間トポロジ管理モジュール２１は、自らＯＦＣＤＵを送信し、ループディスカバリ処理を再度行ってもよい。
このように、ドメイン間トポロジ管理モジュール２１は、ＯＦＣドメイン間で通信経路がループする閉鎖グラフが存在する場合、その閉鎖グラフを対象としてＳＴＰで用いられるようなループ構成を回避する通信ツリーを計算する。その結果、構築された通信ツリーであるＩｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅ経由で、ＯＦＣ−ＯＦＳドメイン間の通信が可能になる。
（３）トポロジディスカバリ段階
ドメイン間トポロジ管理モジュール２１は、各ＯＦＣドメイン間のネットワークトポロジを特定する。本実施形態では、ドメイン間トポロジ管理モジュール２１は、ドメイン間のネットワークトポロジを判断する際に、ＯＦＣＴＤＤＵ（ＯＦＣ Ｔｏｐｏｌｏｇｙ Ｄｉｓｃｏｖｅｒｙ Ｄａｔａ Ｕｎｉｔ）パケットを利用する。
図６は、ＯＦＣＴＤＤＵパケットの例を示す説明図である。図６に例示するＯＦＣＴＤＤＵパケットでは、Ｎｏｄｅ ＩＤごとに、ＯＦＣ Ｄｏｍａｉｎ ＩＤ、ＯＦＳ Ｄｏｍａｉｎ ＩＤ、ＯＦＳ ＩＤ、ＯＦＳ Ｐｏｒｔ ＩＤ、Ｐｏｒｔ Ｌｉｎｋ Ｃｏｓｔの各フィールドを含む。
ＯＦＣＴＤＤＵパケットのフレームは、以下の条件を満たせば、その他のフォーマット等については、特に限定されない。
・ＭＡＣＳＡ
ＯＦＣ ＯｐｅｎＦｌｏｗ Ｃｈａｎｎｅｌとして利用するＮＩＣのＭＡＣ
なお、クラスタ構成の場合、共有の仮想ＭＡＣ
・ＭＡＣＤＡ
ＢＣ／ＭＣ
レガシースイッチの透過性があるＭＡＣＤＡ
・Ｅｔｈｅｒ Ｔｙｐｅ
レガシースイッチの透過性があるＥｔｈｅｒ Ｔｙｐｅ
ＯＦＣＴＤＤＵには、Ｎｏｄｅ情報が各Ｎｏｄｅラベルに格納される。Ｎｏｄｅ ＩＤ＝０のＮｏｄｅラベルには、ＯＦＣＴＤＤＵを送信するＯＦＣ−ＯＦＳドメインの情報が格納される。ＯＦＣがＯＦＣＴＤＤＵを受信すると、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵの最後尾のＮｏｄｅ ＩＤをインクリメントして、新たなＮｏｄｅラベルを作成し、受信ＯＦＣ−ＯＦＳドメインの情報を、そのＮｏｄｅラベルに格納する。
具体的には、各ＯＦＣのドメイン間トポロジ管理モジュール２１は、隣接ドメインが存在する全外向きポートに対して、送信元のＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ情報を格納したＯＦＣＴＤＤＵを送信する。ＯＦＣがＯＦＣＴＤＤＵを受信すると、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵを受信したＯＦＣ−ＯＦＳ Ｄｏｍａｉｎを示す情報がそのＯＦＣＴＤＤＵに含まれているか判断する。
その情報がＯＦＣＴＤＤＵに含まれている場合、ドメイン間トポロジ管理モジュール２１は、トポロジ情報を学習する。一方、その情報がＯＦＣＴＤＤＵに含まれていない場合、ドメイン間トポロジ管理モジュール２１は、トポロジ情報を学習し、さらに、ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ情報をＯＦＣＴＤＤＵに追加して、受信ポート以外で隣接ドメインが存在する外向きポートに転送する。
一定時間経過後、ＯＦＣのトポロジ管理モジュール２０は、収集したトポロジ情報に基づいてネットワーク全体のトポロジ（以下、Ｉｎｔｅｒ−Ｄｏｍａｉｎ Ｔｏｐｏｌｏｇｙと記すこともある。）を特定し、経路計算モジュール１０に通知する。
Ｉｎｔｅｒ−Ｄｏｍａｉｎ Ｔｏｐｏｌｏｇｙを特定する際、ドメイン間トポロジ管理モジュール２１は、隣り合うポートのリンクコストのうち、最も大きな値を、トポロジにおけるリンクコスト（エッジコスト）として利用してもよい。
（４）Ｕｎｉｃａｓｔ経路計算段階
経路計算モジュール１０は、特定されたネットワークトポロジを利用して、上述する通信経路に基づく経路を算出して、各ＯＦＳに接続される装置からの通信を制御する。具体的には、経路計算モジュール１０は、ＡＲＰ（Address Resolution Protocol ） ＲｅｑｕｅｓｔのブロードキャストＭＡＣＤＡを書き換え、ＭＡＣＳＡの発信元ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤ情報を設定する。そして、経路計算モジュール１０は、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅ経由で、書き換えたパケットを他のＯＦＣに通知する。
ＭＡＣＳＡの発信元ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤ情報は、ＯＦＳＤＡパケットおよびＯＦＳＤＤパケットで伝送される。図７は、ＯＦＳＤＡパケットとＯＦＳＤＤパケットの例を示す説明図である。図７に例示するＯＦＳＤＡパケットには、ＯＦＳＤＡを識別するための固定値として“０３２５５ｃ００”が設定されている。また、図７に例示するＯＦＳＤＤパケットには、ＯＦＳＤＤを識別するための固定値として“０３２５５ｃ０１”が設定されている。
なお、図７に示すＯＦＳＤＡパケットおよびＯＦＳＤＤパケットは一例である。ただし、以下の条件を満たす。
・ＭＡＣＤＡ
Ｍｕｌｔｉｃａｓｔ
ＯＦＣＤＡとＯＦＣＤＤを識別するための識別子を格納するフィールドを有する。
ＭＡＣＳＡの送信元ＯＦＣ−ＯＦＳ Ｄｏｍａｉｎ ＩＤ情報を格納するフィールドを有する。
・Ｅｔｈｅｒ Ｔｙｐｅ
ＡＲＰ
まず、経路計算モジュール１０は、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅ上で、隣接ドメインが存在する外向きポートに対して、以下のＯＦＣＤＡ−ＯＦＣＤＤパケットインフローを登録する。
・ＯＦＣＤＡまたはＯＦＣＤＤを受信した場合、ＯＦＣにＰａｃｋｅｔ＿Ｉｎさせる。
次に、経路計算モジュール１０は、端末（例えば、ＰＣ）から受信したＢＣ ＡＲＰ Ｒｅｑｕｅｓｔを、ＯＦＣドメイン内部のＢＣＭＣツリーを経由させ、各ＯＦＳドメイン内の各ＯＦＳにおいて隣接ドメインが存在しない外向きポートにフラディングする。
経路計算モジュール１０は、ＢＣ ＡＲＰ ＲｅｑｕｅｓｔのＭＡＣＳＡを学習し、ＭＡＣローカルテーブル記憶部１２に登録する。なお、ＯＦＳドメイン内部の経路は、既存の方法により特定される。
次に、経路計算モジュール１０は、端末（例えば、ＰＣ）から受信したＢＣ ＡＲＰ ＲｅｑｕｅｓｔをＯＦＳＤＡに書き換え、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅ上で、隣接ドメインが存在する外向きポートにフラディングする。
ＯＦＣがＯＦＣＤＡを受信すると、経路計算モジュール１０は、ＯＦＳＤＡに含まれるＭＡＣＳＡ、および、ＭＡＣＤＡに設定されたＯＦＣドメインＩＤとＯＦＳドメインＩＤとを、ＭＡＣ・宛先ドメインテーブル記憶部１１に登録する。
そして、経路計算モジュール１０は、そのＯＦＣＤＡパケットを、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅ上で、隣接ドメインが存在する全外向きポート（ただし、受信ポートを除く。）にフラディングする。
次に、経路計算モジュール１０は、ＯＦＣＤＡのＭＡＣＤＡをブロードキャストＭＡＣＤＡに書き戻したＡＲＰ Ｒｅｑｕｅｓｔを、受信したＯＦＣドメイン内部のＢＣＭＣツリーを経由させ、ドメイン内において隣接ドメインが存在しない外向きポートにフラディングする。
以上の処理を行うことで、各ＯＦＣは、端末のＭＡＣが存在するＯＦＣ−ＯＦＳ ＤｏｍａｉｎのＩＤを把握できる。
次に、その端末のＭＡＣがＭＡＣＤＡに設定されたパケットを、ＯＦＣが受信した場合の処理を説明する。
ＭＡＣローカルテーブル記憶部１２にその端末のＭＡＣが存在する場合、経路計算モジュール１０は、一般的な方法で、その端末のＭＡＣが存在するポートにパケットを転送する制御を行う。経路計算モジュール１０は、例えば、フローエントリを追加してパケットを転送するように制御してもよい。
一方、ＭＡＣローカルテーブル記憶部１２にその端末のＭＡＣが存在しない場合、経路計算モジュール１０は、ＭＡＣ・宛先ドメインテーブル記憶部１１を検索する。
ＭＡＣ・宛先ドメインテーブル記憶部１１にも、その端末のＭＡＣが存在しない場合、経路計算モジュール１０は、受信したパケットをＵｎｋｎｏｗｎ ｕｎｉｃａｓｔパケットとして認識する。そして、経路計算モジュール１０は、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅ上において隣接ドメインが存在する全外向きポート、および、自ＯＦＣ−ＯＦＳドメイン内において隣接ドメインが存在しない外向きポートに対して、受信したパケットをフラディングする。
一方、ＭＡＣ・宛先ドメインテーブル記憶部１１にその端末のＭＡＣが存在する場合、経路計算モジュール１０は、Ｕｎｉｃａｓｔパケットを受信した自ＯＦＣ−ＯＦＳドメインを始点とし、ＭＡＣ・宛先ドメインテーブルの宛先ＯＦＣ−ＯＦＳドメインを終点として、最短経路を探索する。
経路計算モジュール１０は、例えば、ダイクストラ法など、一般的に用いられる任意の探索アルゴリズムを用いて最短経路を探索すればよい。
また、最短経路が複数存在する場合、経路計算モジュール１０は、予め定めた分散アルゴリズム（例えば、ラウンドロビン法や、ＭＡＣハッシュ、ＩＰハッシュなど）を用いて、経路を選択してもよい。
経路計算モジュール１０は、ＯＦＣは、計算された最短経路上のＯＦＣ−ＯＦＳドメインに接続されたポートに該当のパケットを転送する制御を行う。経路計算モジュール１０は、例えば、フローエントリをＯＦＳに設定し、送信するＵｎｉｃａｓｔパケットのハードウェア転送を実施させる。
また、ＯＦＣ管理配下のＭＡＣが消滅した場合、経路計算モジュール１０は、ＭＡＣローカルテーブル記憶部１２から、消滅したＭＡＣのラーニング情報を削除する。そして、経路計算モジュール１０は、そのＭＡＣをＭＡＣＳＡに設定したＯＦＣＤＤを、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅ経由で、各ＯＦＣ−ＯＦＳドメインにフラディングする。ＯＦＣがＯＦＣＤＤを受信すると、経路計算モジュール１０は、ＯＦＣＤＤに設定されたＭＡＣＳＡの情報を、ＭＡＣ・宛先ドメインテーブル記憶部１１から削除する。
経路計算モジュール１０は、トポロジディスカバリが完了した後、Ｕｎｉｃａｓｔ経路を計算することで、Ｋｎｏｗｎ Ｕｎｉｃａｓｔの転送および負荷分散を行う。よって、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
以下、第１の実施形態の通信制御システムの動作例を、図１を参照して用いてさらに説明する。図１に示す例では、各ＯＦＣは、既存の方式で自ドメイン内部のＢＣＭＣ Ｔｒｅｅを構築する。具体的には、ＯＦＣ１ドメイン１１０（以下、ＯＦＣ１−ＯＦＳ１ドメインと記す。）においてはＯＦＳ３とＯＦＳ４の間のリンクがブロックされ、ＯＦＣ２ドメイン１２０（以下、ＯＦＣ２−ＯＦＳ１ドメインと記す。）においてはＯＦＳ２とＯＦＳ４の間のリンクがブロックされ、ＯＦＣ３ドメイン１３０（以下、ＯＦＣ３−ＯＦＳ１ドメインと記す。）においてはＯＦＳ３とＯＦＳ４の間のリンクがブロックされたものとする。
また、ＯＦＣ１−ＯＦＳ１ドメインにおけるＯＦＳ１−Ｐｏｒｔ１、ＯＦＳ２−Ｐｏｒｔ１、ＯＦＳ３−Ｐｏｒｔ１およびＯＦＳ４−Ｐｏｒｔ１は、外向きポートとしてＯＦＣ１に認識されている。
同様に、ＯＦＣ２−ＯＦＳ１ドメインにおけるＯＦＳ１−Ｐｏｒｔ１およびＯＦＳ３−Ｐｏｒｔ１は、外向きポートとしてＯＦＣ２に認識されている。また、ＯＦＣ３−ＯＦＳ１ドメインにおけるＯＦＳ１−Ｐｏｒｔ１およびＯＦＳ２−Ｐｏｒｔ１は、外向きポートとしてＯＦＣ３に認識されている。
（１）ネーバーディスカバリ段階
各ＯＦＣの内部ドメイントポロジ管理モジュール２２は、自身が管理する配下に存在する外向きポートに対して、ＯＦＣＮＡＤをフラディングする。ＯＦＣ１が送信するＯＦＣＮＡＤは、以下に例示する情報を含む。
・ＯＦＳ１−Ｐｏｒｔ１に対して
Ｔｙｐｅ：ＮＡＤ，
Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・ＯＦＳ２−Ｐｏｒ１に対して
Ｔｙｐｅ：ＮＡＤ，
Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・ＯＦＳ３−Ｐｏｒ１に対して
Ｔｙｐｅ：ＮＡＤ，
Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ３，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・ＯＦＳ４−Ｐｏｒ１に対して
Ｔｙｐｅ：ＮＡＤ，
Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ４，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ２｝
ＯＦＣ１から送信されるＯＦＣＮＤ（ＮＡＤ）は、ＰＣ２１１、ＰＣ２１２、ＯＦＣ２−ＯＦＳ１ドメインおよびＯＦＣ３−ＯＦＳ１ドメインに到達する。ＰＣ２１１とＰＣ２１２は端末なので、ＯＮＣＮＤ（ＮＡＤ）パケットに対して回答を行わない。
ＯＦＣ２−ＯＦＳ１ドメインおよびＯＦＣ３−ＯＦＳ１ドメインに到達したＯＦＣＮＤ（ＮＡＤ）は、ＯＦＣＮＤパケットインフローに一致し、それぞれ、ＯＦＣ２とＯＦＣ３にＰａｃｋｅｔ＿Ｉｎされる。
ＯＦＣ２およびＯＦＳ３のドメイン間トポロジ管理モジュール２１は、ＯＦＣＮＤ（ＮＲＳ）パケットを回答する。この場合にＯＦＣ２およびＯＦＣ３が送信するＯＦＣＮＤ（ＮＲＳ）パケットは、以下の情報を含む。
・ＯＦＣ２はＯＦＳ１−Ｐｏｒｔ１に対して
Ｔｙｐｅ：ＮＲＳ，
Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
Ｎｅｉｇｈｂｏｒ Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・ＯＦＣ３はＯＦＳ１−Ｐｏｒｔ１に対して
Ｔｙｐｅ：ＮＲＳ，
Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ４，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ２｝，
Ｎｅｉｇｈｂｏｒ Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
ＯＦＣ２およびＯＦＣ３から送信されるＯＦＣＮＤ（ＮＲＳ）は、ＯＦＣ１−ＯＦＳ１ドメインに到達し、ＯＦＣＮＤパケットフローに一致し、ＯＦＣ１にＰａｃｋｅｔ＿Ｉｎされる。ＯＦＣ１のドメイン間トポロジ管理モジュール２１は、ＯＦＳ２−Ｐｏｒｔ１およびＯＦＳ４−Ｐｏｒｔ１をネーバーあり外向きポートとして認識し、ドメイン間トポロジ情報記憶部１３に以下の情報を記録する。
・Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
Ｎｅｉｇｈｂｏｒ Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ４，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ２｝，
Ｎｅｉｇｈｂｏｒ Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
一方、ＯＦＳ１−Ｐｏｒｔ１およびＯＦＳ３−Ｐｏｒｔ１では、ＯＦＣＮＤ（ＮＲＳ）が受信されない。そのため、ＯＦＣ１のドメイン間トポロジ管理モジュール２１は、この２つのポートをネーバーなし外向きポートとして認識し、既存の方式に従って、ＯＦＳ１−Ｐｏｒｔ１およびＯＦＳ３−Ｐｏｒｔ１のＰａｃｋｅｔ＿Ｉｎやパケット転送を許可する。
この場合、ＯＦＣ１ドメイン内の通信（例えば、ＰＣ２１１とＰＣ２１２との間の通信）は可能になる。他のＯＦＣ２とＯＦＣ３も同様にネーバーディスカバリ処理を行う。ＯＦＣ２が検出した情報は、以下に例示する内容である。
・Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
Ｎｅｉｇｈｂｏｒ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
・Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ３，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
Ｎｅｉｇｈｂｏｒ Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
同様に、ＯＦＣ３が検出した情報は、以下に例示する内容である。
・Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ１，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
Ｎｅｉｇｈｂｏｒ Ｎｏｄｅ：｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン，ＯＦＳ４，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ２｝
・Ｏｒｉｇｉｎａｌ Ｎｏｄｅ：｛ＯＦＣ３ドメイン，ＯＦＳ１ドメイン，ＯＦＳ２，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝，
Ｎｅｉｇｈｂｏｒ Ｎｏｄｅ：｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン，ＯＦＳ３，Ｐｏｒｔ１，ＬｉｎｋＣｏｓｔ１｝
（２）ループディスカバリ段階
各ＯＦＣは、ＯＦＣＤＵを送受信することにより、上記の実施形態で説明したＳＴＰに類似する動作を行い、ＯＦＣドメイン間のループを防止する。ループを防止する際のアルゴリズムは、ＳＴＰに基づく処理と同様のため、ここでは詳細な説明は省略する。
ここでは、ＯＦＣドメインＩＤが最小のドメインであるＯＦＣ１−ＯＦＳ１ドメインが、Ｒｏｏｔ Ｄｏｍａｉｎとして選出される。一方、ＯＦＣ３−ＯＦＳ１ドメインのＯＦＳ２−Ｐｏｒｔ１が、非代表ポートとして選出される。
各ＯＦＣのドメイン間トポロジ管理モジュール２１は、ＯＦＣ３−ＯＦＳ１ドメインのＯＦＳ２−Ｐｏｒｔ１以外のネーバーあり外向きポートに対して、Ｐａｃｋｅｔ＿Ｉｎやパケット転送などを許可する。その結果、以下に例示するＩｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅが構成される。以降、ＯＦＣ−ＯＦＳドメイン間の通信は、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅを介して行われる。
・（ＯＦＣ１−ＯＦＳ１ドメイン、ＯＦＳ２、Ｐｏｒｔ１）と、
（ＯＦＣ２−ＯＦＳ１ドメイン、ＯＦＳ１、Ｐｏｒｔ１）とが接続される。
・（ＯＦＣ１−ＯＦＳ１ドメイン、ＯＦＳ４、Ｐｏｒｔ１）と、
（ＯＦＣ３−ＯＦＳ１ドメイン、ＯＦＳ１、Ｐｏｒｔ１）とが接続される。
（３）トポロジディスカバリ段階
各ＯＦＣは、ネーバーあり全外向きポートに対して、ＯＦＣＴＤＤＵを送信する。ここでは、ＯＦＣ１から送信されたＯＦＣＴＤＤＵに対する処理例を説明する。
ＯＦＣ１のドメイン間トポロジ管理モジュール２１は、ＯＦＳ２−Ｐｏｒｔ１とＯＦＳ４−Ｐｏｒｔ１に対して、それぞれ以下の情報を含むＯＦＣＴＤＤＵを送信する。このとき、Ｎｏｄｅ ＩＤ＝０のＮｏｄｅラベルに格納されるＬｉｎｋｃｏｓｔは、ＯＦＣＴＤＤＵが送信されたポート（ＯＦＳ２−Ｐｏｒｔ１およびＯＦＳ４−Ｐｏｒｔ１）に設定されるリンクのリンクコスト値である。
・ＯＦＳ２−Ｐｏｒｔ１に対して
Ｎｏｄｅ ＩＤ＝０
｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
・ＯＦＳ４−Ｐｏｒｔ１に対して
Ｎｏｄｅ ＩＤ＝０
｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ２｝
ＯＦＣ２−ＯＦＳ１ドメインに到達したＯＦＣＴＤＤＵは、ＯＦＣＴＤＤＵパケットインフローに一致し、ＯＦＣ２にＰａｃｋｅｔ＿Ｉｎされる。ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵに含まれるトポロジ情報を学習する。
ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵのＮｏｄｅラベルに、ＯＦＣＴＤＤＵを受信したＯＦＣ−ＯＦＳドメイン（ＯＦＣ２−ＯＦＳ１ドメイン）の情報が含まれていないと判定する。そこで、ドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵにおける最後のＮｏｄｅ ＩＤをインクリメントし、新たなＮｏｄｅ ＩＤを有するＮｏｄｅラベルに、ＯＦＣＴＤＤＵを受信したＯＦＣ２−ＯＦＳ１ドメインの情報を格納する。
ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、新たに作成したＯＦＣＴＤＤＵを、受信ポート以外のネーバーあり外向きポート（ＯＦＣ２−ＯＦＳ１ドメインに存在するＯＦＳ３−Ｐｏｒｔ１）にフラディングする。
ＯＦＣ１が発信したＯＦＣＴＤＤＵは、ＯＦＣ２を経由して転送され、以下に例示する情報を含む。
・ＯＦＳ３−Ｐｏｒｔ１に対して
Ｎｏｄｅ ＩＤ＝０
｛ＯＦＣ１ドメイン，ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
Ｎｏｄｅ ＩＤ＝１
｛ＯＦＣ２ドメイン，ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
同様に、ＯＦＣ３のドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵパケットからトポロジ情報を学習する。ＯＦＣ３のドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵに基づいて新たなＯＦＣＴＤＤＵを作成し、ＯＦＳ２−Ｐｏｒｔ１にフラディングする。
ＯＦＣ１が発信したＯＦＣＴＤＤＵは、ＯＦＣ３を経由して転送され、以下に例示する情報を含む。
・ＯＦＳ２−Ｐｏｒｔ１に対して
Ｎｏｄｅ ＩＤ＝０
｛ＯＦＣ１ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ２｝
・Ｎｏｄｅ ＩＤ＝１
｛ＯＦＣ３ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
一方、ＯＦＣ１が発信したＯＦＣＴＤＤＵがＯＦＣ２から転送されてＯＦＣ３に到達する。ＯＦＣ３のドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵパケットからトポロジ情報を学習する。
ＯＦＣ３のドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵのＮｏｄｅラベルに、ＯＦＣＴＤＤＵを受信した受信ＯＦＣ−ＯＦＳドメインの情報が含まれていないと判定する。そこで、ドメイン間トポロジ管理モジュール２１は、新たなＯＦＣＴＤＤＵを作成し、ＯＦＳ１−Ｐｏｒｔ１にフラディングする。
新たに作成されたＯＦＣＴＤＤＵには、以下に例示する情報が含まれる。
・ＯＦＳ１−Ｐｏｒｔ１に対して
Ｎｏｄｅ ＩＤ＝０
｛ＯＦＣ１ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
Ｎｏｄｅ ＩＤ＝１
｛ＯＦＣ２ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
Ｎｏｄｅ ＩＤ＝２
｛ＯＦＣ３ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
さらに、ＯＦＣ１が発信したＯＦＣＴＤＤＵがＯＦＣ２から転送されてＯＦＣ２に到達する。ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、受信したＯＦＣＴＤＤＵパケットからトポロジ情報を学習する。
ＯＦＣ２のドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵのＮｏｄｅラベルに、ＯＦＣＴＤＤＵを受信した受信ＯＦＣ−ＯＦＳドメインの情報が含まれていないと判定する。そこで、ドメイン間トポロジ管理モジュール２１は、新たなＯＦＣＴＤＤＵを作成し、ＯＦＳ１−Ｐｏｒｔ１にフラディングする。
新たに作成されたＯＦＣＴＤＤＵには、以下に例示する情報が含まれる。
・ＯＦＳ１−Ｐｏｒｔ１に対して
Ｎｏｄｅ ＩＤ＝０
｛ＯＦＣ１ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ２｝
Ｎｏｄｅ ＩＤ＝１
｛ＯＦＣ２ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
Ｎｏｄｅ ＩＤ＝２
｛ＯＦＣ３ドメイン、ＯＦＳ１ドメイン、Ｌｉｎｋｃｏｓｔ１｝
その後、ＯＦＣ１は、ＯＦＣ１からＯＦＣ２を経由しさらにＯＦＣ３を経由したＯＦＣＴＤＤＵと、ＯＦＣ１からＯＦＣ３を経由しさらにＯＦＣ２を経由したＯＦＣＴＤＤＵとを受信する。ＯＦＣ１のドメイン間トポロジ管理モジュール２１は、自身のＯＦＣ−ＯＦＳドメイン（ＯＦＣ１−ＯＦＳ１ドメイン）がＯＦＣＴＤＤＵのＮｏｄｅラベルに含まれていると判定する。そこで、ドメイン間トポロジ管理モジュール２１は、ＯＦＣＴＤＤＵに含まれるトポロジ情報を学習し、ＯＦＣＴＤＤＵパケットを廃棄する。
ＯＦＣ２およびＯＦＣ３も同様に、自らＯＦＣＴＤＤＵを発行し、トポロジディスカバリ処理を行う。その結果、ＯＦＣ１、ＯＦＣ２およびＯＦＣ３は、以下のトポロジ情報を保持する。
・ＯＦＣ１−ＯＦＳ１ドメインとＯＦＣ２−ＯＦＳ１ドメインが、Ｌｉｎｋｃｏｓｔ１で接続されている。
・ＯＦＣ１−ＯＦＳ１ドメインとＯＦＣ３−ＯＦＳ１ドメインが、Ｌｉｎｋｃｏｓｔ２で接続されている。
・ＯＦＣ２−ＯＦＳ１ドメインとＯＦＣ３−ＯＦＳ１ドメインが、Ｌｉｎｋｃｏｓｔ１で接続されている。
（４）Ｕｎｉｃａｓｔ経路計算段階
本具体例では、ＰＣ２１１がＡＲＰ Ｒｅｑｕｅｓｔを送信する。ＡＰＲ Ｒｅｑｕｅｓｔは、ＯＦＣ１−ＯＦＳ１ドメインに到達し、ＯＦＣ１にＰａｃｋｅｔ＿Ｉｎされる。
ＯＦＣ１の経路計算モジュール１０は、ＡＲＰ ＲｅｑｕｅｓｔをＯＦＳ３−Ｐｏｒｔ１にフラディングし、ＭＡＣローカルテーブルにＡＲＰ ＲｅｑｕｅｓｔのＭＡＣＳＡと学習位置（ＯＦＳ１ドメインのＯＦＳ１−Ｐｏｒｔ１）を登録する。
ＯＦＣ１の経路計算モジュール１０は、ＡＲＰ ＲｅｑｕｅｓｔをＯＦＣＤＡに書き換える。具体的には、経路計算モジュール１０は、ＡＲＰ Ｒｅｑｕｅｓｔを受信したＯＦＣ１−ＯＦＳ１ドメインのＩＤをＯＦＣＤＡに含め、Ｉｎｔｅｒ−Ｄｏｍａｉｎ ＢＣＭＣ Ｔｒｅｅにあるネーバーあり外向きポートに対してそのＯＦＣＤＡをフラディングする。
ＯＦＣ２およびＯＦＣ３は、ＯＦＣ１から発行されたＰＣ２１１のＭＡＣがＭＡＣＳＡとして含まれるＯＦＣＤＡをＰａｃｋｅｔ＿Ｉｎで受信する。
ＯＦＣ２の経路計算モジュール１０は、受信したＯＦＣＤＡから、ＰＣ２１１のＭＡＣＳＡと、そのＭＡＣの送信元ドメインであるＯＦＣ１−ＯＦＳ１ドメインＩＤを抽出し、ＭＡＣ・宛先ドメインテーブル記憶部１１に登録する。
同様に、ＯＦＣ３の経路計算モジュール１０は、ＰＣ２１１のＭＡＣＳＡと、そのＭＡＣの送信元ドメインであるＯＦＣ１−ＯＦＳ１ドメインＩＤを抽出し、ＭＡＣ・宛先ドメインテーブル記憶部１１に登録する。また、ＯＦＣ３の経路計算モジュール１０は、ＯＦＣＤＡをＡＲＰ Ｒｅｑｕｅｓｔに書き換え、ＯＦＳ４−Ｐｏｒｔ１とＯＦＳ３−Ｐｏｒｔ１にフラディングする。
ＰＣ２１１、ＰＣ２１２、ＰＣ２３１およびＰＣ２３２のすべてが、ＡＲＰ Ｒｅｑｕｅｓｔを出した場合、ＯＦＣ１、ＯＦＣ２およびＯＦＣ３のＭＡＣローカルテーブル記憶部１２およびＭＡＣ・宛先ドメインテーブル記憶部１１には、以下の情報が登録される。
＜ＯＦＣ１＞
・ＭＡＣローカルテーブル
ＭＡＣＳＡ＝ＰＣ２１１，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＳ１−Ｐｏｒｔ１
ＭＡＣＤＡ＝ＰＣ２１２，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＳ２−Ｐｏｒｔ１
・ＭＡＣ・宛先ドメインテーブル
ＭＡＣＳＡ＝ＰＣ２３１，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＣ３−ＯＦＳ１ドメイン
ＭＡＣＳＡ＝ＰＣ２３２，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＣ３−ＯＦＳ１ドメイン
＜ＯＦＣ２＞
・ＭＡＣローカルテーブル
空（未設定）
・ＭＡＣ・宛先ドメインテーブル
ＭＡＣＳＡ＝ＰＣ２１１，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＣ１−ＯＦＳ１ドメイン
ＭＡＣＳＡ＝ＰＣ２１２，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＣ１−ＯＦＳ１ドメインＭＡＣＳＡ＝ＰＣ２３１，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＣ３−ＯＦＳ１ドメイン
ＭＡＣＳＡ＝ＰＣ２３２，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＣ３−ＯＦＳ１ドメイン
＜ＯＦＣ３＞
・ＭＡＣローカルテーブル
ＭＡＣＳＡ＝ＰＣ２３１，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＳ４−Ｐｏｒｔ１
ＭＡＣＤＡ＝ＰＣ２３２，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＳ３−Ｐｏｒｔ１
・ＭＡＣ・宛先ドメインテーブル
ＭＡＣＳＡ＝ＰＣ２１１，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＣ１−ＯＦＳ１ドメイン
ＭＡＣＳＡ＝ＰＣ２１２，Ｌｅａｒｎｉｎｇ Ｐｏｉｎｔ：ＯＦＣ１−ＯＦＳ１ドメイン
例えば、ＰＣ２１１からＰＣ２３１に対してＵｎｉｃａｓｔ通信を行う場合、ＯＦＣ１の経路計算モジュール１０は、Ｐａｃｋｅｔ＿Ｉｎで受信したＵｎｉｃａｓｔパケットのＭＡＣＤＡ（ＰＣ２３１）で、ＭＡＣローカルテーブル記憶部１２を検索する。
この場合、ＭＡＣローカルテーブル記憶部１２には、対象のＭＡＣＤＡが存在しないため、ＯＦＣ１の経路計算モジュール１０は、ＰＣ２３１でＭＡＣ・宛先ドメインテーブル記憶部１１を検索する。その結果、ＯＦＣ１の経路計算モジュール１０は、ＰＣ２３１がＯＦＣ３−ＯＦＳ１ドメインに存在することを知る。
ＯＦＣ１の経路計算モジュール１０は、Ｕｎｉｃａｓｔパケットインを受信したＯＦＣ−ＯＦＳドメイン（ＯＦＣ１−ＯＦＳ１ドメイン）を始点とし、ＰＣ２３１が存在するＯＦＣ３−ＯＦＳ１ドメインを終点として、トポロジ上における最小コスト経路を探索する。
本例の場合、ＯＦＣ１の経路計算モジュール１０は、以下に例示する最小コスト経路を算出する。
（１）ＯＦＣ１−ＯＦＳ１ドメインからＯＦＣ２−ＯＦＳ１ドメインを経由し、ＯＦＣ３−ＯＦＳ１ドメインに至るまでのＬｉｎｋｃｏｓｔ＝２
（２）ＯＦＣ１−ＯＦＳ１ドメインからＯＦＣ３−ＯＦＳ１ドメインに至るまでのＬｉｎｋｃｏｓｔ＝２
上記に例示するように、最小コスト経路は２つ存在する。そこで、ＯＦＣ１の経路計算モジュール１０は、一般的なＯＦＣの負荷分散アルゴリズムに従って、任意の経路を選択する。なお、ここでは、（１）の経路が選択されたものとする。
ＯＦＣ１の経路計算モジュール１０は、ドメイン間トポロジ情報記憶部１３を参照し、ＯＦＣ２−ＯＦＳ１ドメインに転送するためのＯＦＳ ＩＤおよびＰｏｒｔ ＩＤを取得する。そして、ＯＦＣ１の経路計算モジュール１０は、ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットを、ＯＦＣ２−ＯＦＳ１ドメインに転送するように制御する。
ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットは、ＯＦＣ１−ＯＦＳ１ドメインからＯＦＣ２−ＯＦＳ１ドメインに転送される。
ＯＦＣ２は、ＵｎｉｃａｓｔパケットをＰａｃｋｅｔ＿Ｉｎで受信する。ＯＦＣ２の経路計算モジュール１０は、ＭＡＣローカルテーブル記憶部１２およびＭＡＣ・宛先ドメインテーブル記憶部１１からＭＡＣＤＡ（ＰＣ２３１）を検索する。本例において、ＯＦＣ２の経路計算モジュール１０は、ＰＣ２３１がＯＦＣ３−ＯＦＳ１ドメインに存在することを知る。
ＯＦＣ２の経路計算モジュール１０は、Ｕｎｉｃａｓｔパケットインを受信したＯＦＣ−ＯＦＳドメイン（ＯＦＣ２−ＯＦＳ１ドメイン）を始点とし、ＰＣ２３１が存在するＯＦＣ３−ＯＦＳ１ドメインを終点として、トポロジ上における最小コスト経路を探索する。
本例の場合、ＯＦＣ２の経路計算モジュール１０は、以下に例示する最小コスト経路を算出する。
（１）ＯＦＣ２−ＯＦＳ１ドメインからＯＦＣ３−ＯＦＳ１ドメインに至るまでのＬｉｎｋｃｏｓｔ＝１
ＯＦＣ２の経路計算モジュール１０は、ドメイン間トポロジ情報記憶部１３を参照し、ＯＦＣ３−ＯＦＳ１ドメインに転送するためのＯＦＳ ＩＤおよびＰｏｒｔ ＩＤを取得する。そして、ＯＦＣ２の経路計算モジュール１０は、ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットを、ＯＦＣ３−ＯＦＳ１ドメインに転送するように制御する。
ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットは、Ｐａｃｋｅｔ＿ＩｎでＯＦＣ３に到達する。
ＯＦＣ３の経路計算モジュール１０は、ＭＡＣローカルテーブル記憶部１２からＭＡＣＤＡ（ＰＣ２３１）を検索する。すると、経路計算モジュール１０は、管理する配下のドメイン内のＯＦＳ４−Ｐｏｒｔ１にＰＣ２３１が接続されていることを知る。よって、ＯＦＣ３の経路計算モジュール１０は、ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットを、ＯＦＳ４−Ｐｏｒｔ１転送するように制御する。
以上の処理により、Ｕｎｉｃａｓｔパケットは、ＰＣ２１１から、ＯＦＣ１−ＯＦＳ１ドメイン、ＯＦＣ２−ＯＦＳ１ドメイン、ＯＦＣ３−ＯＦＳ１ドメインの順にドメインを経由して、ＰＣ２３１まで転送される。
なお、上記説明では、ＰＣ２１１からＰＣ２３１宛てのＵｎｉｃａｓｔパケットが単独で送信される場合を例示した。例えば、ＰＣ２１１からＰＣ２３１宛の通信と、ＰＣ２１２からＰＣ２３２宛の通信が同時に行われてもよい。この場合、各ＯＦＣの経路計算モジュール１０は、トラヒック負荷分散を考慮した処理を行ってもよい。
ＰＣ２１１からＰＣ２３１宛の通信と、ＰＣ２１２からＰＣ２３２宛の通信が同時に行われる場合、ＯＦＣ１−ＯＦＳ１ドメインからＯＦＣ３−ＯＦＳ１ドメイン宛の最小コスト経路は２つ存在する。経路計算モジュール１０は、例えば、ラウンドロビンアルゴリズムを用いて負荷分散処理を行ってもよい。この場合、経路計算モジュール１０は、ＰＣ２１１からＰＣ２３１への通信には、ＯＦＣ１−ＯＦＳ１ドメインからＯＦＣ２−ＯＦＳ１ドメインを経由し、ＯＦＣ３−ＯＦＳ１ドメインへ到達する経路を算出してもよい。また、経路計算モジュール１０は、ＰＣ２２１からＰＣ２３２への通信には、ＯＦＣ１−ＯＦＳ１ドメインからＯＦＣ３−ＯＦＳ１ドメインへ到達する経路を算出してもよい。
以上のように、本実施形態によれば、ドメイン間トポロジ管理モジュール２１が、自ＯＦＣドメインに隣接するＯＦＣドメインを特定する。ドメイン間トポロジ管理モジュール２１は、隣接するＯＦＣドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成し、各ＯＦＣドメイン間のネットワークトポロジを特定する。そして、経路計算モジュール１０が、特定されたネットワークトポロジを利用して、上述する通信ツリーに基づく最適経路を算出して、各ＯＦＳに接続される通信装置からの通信を制御する。
よって、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
具体的には、本実施形態の通信制御システムは、既存のＯＦＣの処理方式に影響を与えず、標準的なＯｐｅｎＦｌｏｗプロトコルを用いて実現できる。そして、本実施形態の通信制御システムを用いることで、独立に動作する複数のＯＦＣによって制御されているＯｐｅｎＦｌｏｗネットワーク間のループを防止できるため、ＯｐｅｎＦｌｏｗネットワーク間の冗長構成を組むことができる。
また、本実施形態によれば、独立に動作する複数のＯＦＣによって制御されているＯｐｅｎＦｌｏｗネットワーク間に、複数の通信経路の候補が存在する場合であっても、ＥＣＭＰ（Equal-cost multi-path ）的なロードバランシングを実現できる。そのため、ネットワーク帯域の利用効率を上げることができる。
また、本実施形態によれば、オープンフローのネットワーク内にダークファイバが存在する場合でも、最適なリンクコストを用いて経路計算ができるため、ネットワーク帯域の利用率を上げることができる。したがって、ダークファイバリンクコストの誤判断により発生する帯域圧迫の確率を低減できる。
実施形態２．
次に、本発明の第２の実施形態を説明する。第１の実施形態では、ＯＦＣが、隣接するドメインの情報に基づいてシステム全体のドメイントポロジを計算し、さらに、ドメイン間のＳＰＴを算出していた。一方、本実施形態では、システム内全てのＯＦＣとＩＰ到達性を有するトポロジマネージャを用意し、これらの処理をそのトポロジマネージャが行って、処理結果を各ＯＦＣに通知する。
このように、第１の実施形態では、各ＯＦＣが自律的に通信制御を行うことから、第１の実施形態で説明した手法を、完全自律手法と呼ぶことができる。また、本実施形態で説明する手法は、ＯＦＣとトポロジマネージャが協働して通信制御を行うことから、ハイブリッド手法と呼ぶことができる。
図８は、本発明による通信制御システムの第２の実施形態の構成例を示す説明図である。なお、第１の実施形態と同様の構成については、図１と同一の符号を付し、説明を省略する。
図８に例示する通信制御システムは、第１の実施形態の通信制御システムに加え、トポロジマネージャ１４０を備えている。また、トポロジマネージャ１４０は、制御部１４１を含む。制御部１４１は、プログラム（ドメイン間トポロジ管理プログラム）に従って動作するコンピュータのＣＰＵによって実現される。例えば、プログラムは、トポロジマネージャ１４０の記憶部（図示せず）に記憶され、ＣＰＵは、そのプログラムを読み込み、プログラムに従って、制御部１４１として動作してもよい。
本実施形態のＯＦＣでは、ネーバーディスカバリ段階の処理が完了すると、各ＯＦＣのドメイン間トポロジ管理モジュール２１は、隣接ドメインを示す情報をトポロジマネージャ１４０に送信する。
トポロジマネージャ１４０が各ＯＦＣから隣接ドメインを示す情報を受信すると、制御部１４１は、受信した情報に基づいて、ＯＦＣドメイン間のトポロジを計算し、さらに、ＯＦＣドメイン間でループ構成を回避する通信ツリー（例えば、スパニングツリー）を算出する。そして、制御部１４１は、算出した通信ツリーを各ＯＦＣに配信する。
制御部１４１は、第１の実施形態でドメイン間トポロジ管理モジュール２１が行う方法と同様の方法を用いて、ＯＦＣドメイン間のトポロジを計算してもよく、ＯＦＣドメイン間のループ構成を回避する通信ツリーを算出してもよい。
ドメイン間トポロジ管理モジュール２１は、トポロジマネージャ１４０から受信した通信ツリーを、ドメイン間の通信経路と判断し、例えば、ドメイン間のスパンニングツリーを構築する。以降、経路計算モジュール１０は、Ｕｎｉｃａｓｔ経路計算段階の処理を行う。経路計算モジュール１０がＵｎｉｃａｓｔ経路を計算する方法は、第１の実施形態と同様である。
このように、ハイブリッド方式では、完全自律方式におけるループディスカバリ段階の処理、および、トポロジディスカバリ段階の処理が、ＯＦＣではなく、トポロジマネージャ１４０で行われることになる。
以上のように、本実施形態によれば、ＯＦＣの代わりに、トポロジマネージャ１４０の制御部１４１が、ＯＦＣから受信した隣接ドメイン情報に基づいて、各ＯＦＣドメイン間のトポロジを特定し、隣接するＯＦＣドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する。そして、制御部１４１が、作成した通信ツリーを各ＯＦＣに配信する。
このような構成であっても、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
このように、本発明を実現する方式として、完全自律方式とハイブリッド方式が挙げられ、異なる環境に柔軟に対応することが可能である。完全自律方式の場合、例えば、ループ防止や負荷分散を、他の装置を介さずに実現することが可能である。一方、ハイブリッド方式の場合、ＯＦＣドメイン間のトポロジを集中管理するトポロジマネージャを利用することで、例えば、ＯＦＣＤＵやＯＦＣＴＤＤＵに占有されるネットワーク帯域や負荷を低減できる。
次に、本発明の概要を説明する。図９は、本発明による通信制御システムの概要を示すブロック図である。本発明による通信制御システムは、各オープンフローコントローラ（例えば、ＯＦＣ１〜ＯＦＣ３）によって少なくとも１つ以上のオープンフロースイッチ（例えば、ＯＦＳ１〜ＯＦＳ４）が管理される範囲を示すコントローラドメイン（例えば、ＯＦＣドメイン）が相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段８１（例えば、ドメイン間トポロジ管理モジュール２１）と、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリー（例えば、スパニングツリー）を作成するループ解決手段８２（例えば、ドメイン間トポロジ管理モジュール２１）と、各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定手段８３（例えば、ドメイン間トポロジ管理モジュール２１）と、ネットワークトポロジを利用して、通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置（例えば、ＰＣ２１１等）からの通信を制御する通信制御手段８４（例えば、経路計算モジュール１０）とを備えている。
そのような構成により、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
また、隣接ドメイン特定手段８１は、自コントローラドメインの外向きポートから隣接ドメインを確認する隣接確認パケット（例えば、ＯＦＣＮＡＤ）を送信し、隣接確認パケットを受信したときにその隣接確認パケットを送信したコントローラドメイン宛に隣接応答パケット（例えば、ＯＦＣＮＲＳ）を返信し、隣接応答パケットを受信して隣接するコントローラドメインを特定してもよい。
また、ループ解決手段８２は、スパニングツリーアルゴリズムに基づいて、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成してもよい。
また、ループ解決手段８２は、隣接するコントローラドメイン間の通信経路中のポート（例えば、非代表ポート）に対して、パケット転送を禁止するフローエントリを設定することにより、ループ構成を回避する通信ツリーを作成してもよい。
また、通信制御手段８４は、複数の経路を算出し、各オープンフロースイッチに接続される通信装置からの通信を複数の経路に負荷分散する制御（例えば、ＥＣＭＰ的なロードバランシング）を行ってもよい。
また、図１０は、本発明による通信制御システムの他の概要を示すブロック図である。本発明による他の通信制御システムは、各オープンフローコントローラ（例えば、ＯＦＣ１〜ＯＦＣ３）によって少なくとも１つ以上のオープンフロースイッチ（例えば、ＯＦＳ１〜ＯＦＳ４）が管理される範囲を示すコントローラドメイン（例えば、ＯＦＣドメイン）が相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、複数のオープンフローコントローラ８０（例えば、ＯＦＣ１〜ＯＦＣ３）と、オープンフローコントローラからの通信が到達するように（例えば、ＩＰ到達性を有するように）接続され、コントローラドメイン間の通信経路を示す通信ツリーを作成するトポロジマネージャ９０（例えば、トポロジマネージャ１４０）とを備えている。
オープンフローコントローラ８０は、自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段８１（例えば、第２の実施形態におけるドメイン間トポロジ管理モジュール２１）と、特定した隣接するコントローラドメインを示す情報を、トポロジマネージャに送信する隣接ドメイン情報送信手段８５（例えば、第２の実施形態におけるドメイン間トポロジ管理モジュール２１）と、トポロジマネージャが算出したネットワークトポロジに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段８６（例えば、経路計算モジュール１０）とを含む。
トポロジマネージャ９０は、オープンフローコントローラ８０から受信した情報に基づいて、各コントローラドメイン間のネットワークトポロジを特定し、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する通信ツリー作成手段９１（例えば、制御部１４１）と、作成した通信ツリーをオープンフローコントローラに配信するネットワークトポロジ配信手段９２（例えば、制御部１４１）とを含む。
そのような構成によっても、オープンフローのネットワーク環境において、接続される複数のＯＦＣドメイン間に物理的なループが存在する場合であっても、通信をループさせずに、最適な経路を用いて通信を行うことができる。
以上、実施形態及び実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、２０１４年２月５日に出願された日本特許出願２０１４−０２０３９０を基礎とする優先権を主張し、その開示の全てをここに取り込む。
１０ 経路計算モジュール
１１ ＭＡＣ・宛先ドメインテーブル記憶部
１２ ＭＡＣローカルテーブル記憶部
１３ ドメイン間トポロジ情報記憶部
２０ トポロジ管理モジュール
２１ ドメイン間トポロジ管理モジュール
２２ 内部ドメイントポロジ管理モジュール
３０ メッセージ解析モジュール
４０ メッセージ送受信モジュール
１００ ＯＦＣ
１１０ ＯＦＣ１ドメイン
１２０ ＯＦＣ２ドメイン
１３０ ＯＦＣ３ドメイン
２１０，２１１，２１２，２３１，２３２ ＰＣ

Claims (10)

  1. 各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、
    自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段と、
    前記隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成するループ解決手段と、
    各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定手段と、
    前記ネットワークトポロジを利用して、前記通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段とを備えた
    ことを特徴とする通信制御システム。
  2. 隣接ドメイン特定手段は、自コントローラドメインの外向きポートから隣接ドメインを確認する隣接確認パケットを送信し、前記隣接確認パケットを受信したときに当該隣接確認パケットを送信したコントローラドメイン宛に隣接応答パケットを返信し、前記隣接応答パケットを受信して隣接するコントローラドメインを特定する
    請求項１記載の通信制御システム。
  3. ループ解決手段は、スパニングツリーアルゴリズムに基づいて、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する
    請求項１または請求項２記載の通信制御システム。
  4. ループ解決手段は、隣接するコントローラドメイン間の通信経路中のポートに対して、パケット転送を禁止するフローエントリを設定することにより、ループ構成を回避する通信ツリーを作成する
    請求項１から請求項３のうちのいずれか１項に記載の通信制御システム。
  5. 通信制御手段は、複数の経路を算出し、各オープンフロースイッチに接続される通信装置からの通信を前記複数の経路に負荷分散する制御を行う
    請求項１から請求項４のうちのいずれか１項に記載の通信制御システム。
  6. 各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御システムであって、
    複数のオープンフローコントローラと、
    前記オープンフローコントローラからの通信が到達するように接続され、前記コントローラドメイン間の通信経路を示す通信ツリーを作成するトポロジマネージャとを備え、
    前記オープンフローコントローラは、
    自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定手段と、
    特定した隣接するコントローラドメインを示す情報を、前記トポロジマネージャに送信する隣接ドメイン情報送信手段と、
    前記トポロジマネージャが算出したネットワークトポロジに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御手段とを含み、
    前記トポロジマネージャは、
    前記オープンフローコントローラから受信した情報に基づいて、各コントローラドメイン間のネットワークトポロジを特定し、隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成する通信ツリー作成手段と、
    作成した通信ツリーを前記オープンフローコントローラに配信するネットワークトポロジ配信手段とを含む
    ことを特徴とする通信制御システム。
  7. 各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御する通信制御方法であって、
    自コントローラドメインに隣接するコントローラドメインを特定し、
    前記隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成し、
    各コントローラドメイン間のネットワークトポロジを特定し、
    前記ネットワークトポロジを利用して、前記通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する
    ことを特徴とする通信制御方法。
  8. 隣接ドメインを特定する際、自コントローラドメインの外向きポートから隣接ドメインを確認する隣接確認パケットを送信し、前記隣接確認パケットを受信したときに当該隣接確認パケットを送信したコントローラドメイン宛に隣接応答パケットを返信し、前記隣接応答パケットを受信して隣接するコントローラドメインを特定する
    請求項７記載の通信制御方法。
  9. 各オープンフローコントローラによって少なくとも１つ以上のオープンフロースイッチが管理される範囲を示すコントローラドメインが相互に接続されるネットワークにおいて、各コントローラドメイン間の通信を制御するコンピュータに適用される通信制御プログラムであって、
    前記コンピュータに、
    自コントローラドメインに隣接するコントローラドメインを特定する隣接ドメイン特定処理、
    前記隣接するコントローラドメイン間の通信経路中に存在するループ構成を回避する通信ツリーを作成するループ解決処理、
    各コントローラドメイン間のネットワークトポロジを特定するトポロジ特定処理、および、
    前記ネットワークトポロジを利用して、前記通信ツリーに基づく最適経路を算出して、各オープンフロースイッチに接続される通信装置からの通信を制御する通信制御処理
    を実行させるための通信制御プログラム。
  10. コンピュータに、
    隣接ドメイン特定処理で、自コントローラドメインの外向きポートから隣接ドメインを確認する隣接確認パケットを送信させ、前記隣接確認パケットを受信したときに当該隣接確認パケットを送信したコントローラドメイン宛に隣接応答パケットを返信させ、前記隣接応答パケットを受信して隣接するコントローラドメインを特定させる
    請求項９記載の通信制御プログラム。
JP2015561200A 2014-02-05 2015-01-21 通信制御システム、通信制御方法および通信制御プログラム Active JP6191703B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014020390 2014-02-05
JP2014020390 2014-02-05
PCT/JP2015/000262 WO2015118822A1 (ja) 2014-02-05 2015-01-21 通信制御システム、通信制御方法および通信制御プログラム

Publications (2)

Publication Number Publication Date
JPWO2015118822A1 JPWO2015118822A1 (ja) 2017-03-23
JP6191703B2 true JP6191703B2 (ja) 2017-09-06

Family

ID=53777637

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015561200A Active JP6191703B2 (ja) 2014-02-05 2015-01-21 通信制御システム、通信制御方法および通信制御プログラム

Country Status (4)

Country Link
US (1) US9998367B2 (ja)
EP (1) EP3104561A4 (ja)
JP (1) JP6191703B2 (ja)
WO (1) WO2015118822A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160122226A (ko) * 2014-02-19 2016-10-21 닛본 덴끼 가부시끼가이샤 통신 시스템, 제어 장치, 통신 제어 방법 및 프로그램
EP3400685B1 (en) * 2016-01-05 2020-07-01 Telefonaktiebolaget LM Ericsson (PUBL) Mechanism to detect control plane loops in a software defined networking (sdn) network
KR102117497B1 (ko) * 2017-06-29 2020-06-02 주식회사 케이티 네트워크 인프라 구축 시스템 및 네트워크 인프라 구축 방법
CN111277423B (zh) * 2018-12-04 2022-05-20 中兴通讯股份有限公司 数据中心流量互通方法、装置、设备及存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6556541B1 (en) * 1999-01-11 2003-04-29 Hewlett-Packard Development Company, L.P. MAC address learning and propagation in load balancing switch protocols
AU2004321282B2 (en) 2004-06-30 2009-08-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for multi-domain virtual private network configuration
EP1847071A4 (en) * 2005-01-26 2010-10-20 Internet Broadcasting Corp B V MULTI-DIFFUSION IN LAYERS AND EXACT ATTRIBUTION OF BANDWIDTH AND PRIORIZATION OF PACKETS
WO2009042919A2 (en) 2007-09-26 2009-04-02 Nicira Networks Network operating system for managing and securing networks
WO2011065268A1 (ja) 2009-11-26 2011-06-03 日本電気株式会社 負荷分散システム、負荷分散方法、及びプログラム
US10244500B2 (en) * 2011-03-30 2019-03-26 Wei Lu Open wireless architecture (OWA) mobile cloud infrastructure and method
US9204207B2 (en) 2011-11-01 2015-12-01 Plexxi Inc. Hierarchy of control in a data center network
US9337931B2 (en) * 2011-11-01 2016-05-10 Plexxi Inc. Control and provisioning in a data center network with at least one central controller
US9306800B2 (en) * 2013-05-10 2016-04-05 Telefonaktiebolaget L M Ericsson (Publ) Inter-domain fast reroute methods and network devices

Also Published As

Publication number Publication date
US20160344625A1 (en) 2016-11-24
EP3104561A4 (en) 2017-10-18
WO2015118822A1 (ja) 2015-08-13
US9998367B2 (en) 2018-06-12
JPWO2015118822A1 (ja) 2017-03-23
EP3104561A1 (en) 2016-12-14

Similar Documents

Publication Publication Date Title
US10230577B2 (en) Packet broadcast mechanism in a split architecture network
EP3474502B1 (en) Reduced configuration for multi-stage network fabrics
US9379975B2 (en) Communication control system, control server, forwarding node, communication control method, and communication control program
EP2544417B1 (en) Communication system, path control apparatus, packet forwarding apparatus and path control method
US20160269289A1 (en) Communication system, communication device, controller, and method and program for controlling forwarding path of packet flow
GB2513188A (en) Identification of the paths taken through a network of interconnected devices
CN116668305A (zh) 多级网络结构的简化配置
JP6191703B2 (ja) 通信制御システム、通信制御方法および通信制御プログラム
CN111147372B (zh) 下行报文发送、转发方法和装置
WO2017084448A1 (zh) 一种网络系统及网络运行方法
KR20090110916A (ko) 링크 상태 광고(ｌｓａ)에 기반한 신장 트리를 계산하는 방법, 브릿지 및 컴퓨터 네트워크
CN105262686B (zh) 一种网络连通性验证方法和装置
US10171306B2 (en) Automatic discovery and provisioning of multi-chassis etherchannel peers
WO2014126094A1 (ja) 通信システム、通信方法、制御装置、制御装置の制御方法及びプログラム
US20150036508A1 (en) Method and Apparatus For Gateway Selection In Multilevel SPB Network
US10574481B2 (en) Heterogeneous capabilities in an overlay fabric
JP2017175522A (ja) ネットワークシステム、制御装置、方法およびプログラム
JP2002185504A (ja) パケット転送中継装置および転送制御方法
JP4805708B2 (ja) データ転送装置

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170711

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170724

R150 Certificate of patent or registration of utility model

Ref document number: 6191703

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150