JP6144834B2 - Ｓｄｎスイッチにより正確なフロー・エントリを獲得するための方法、およびｓｄｎスイッチ、コントローラ、およびシステム - Google Patents

Ｓｄｎスイッチにより正確なフロー・エントリを獲得するための方法、およびｓｄｎスイッチ、コントローラ、およびシステム Download PDF

Info

Publication number
JP6144834B2
JP6144834B2 JP2016526160A JP2016526160A JP6144834B2 JP 6144834 B2 JP6144834 B2 JP 6144834B2 JP 2016526160 A JP2016526160 A JP 2016526160A JP 2016526160 A JP2016526160 A JP 2016526160A JP 6144834 B2 JP6144834 B2 JP 6144834B2
Authority
JP
Japan
Prior art keywords
sdn
sdn switch
message
control message
tcp
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
JP2016526160A
Other languages
English (en)
Other versions
JP2016538768A (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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2016538768A publication Critical patent/JP2016538768A/ja
Application granted granted Critical
Publication of JP6144834B2 publication Critical patent/JP6144834B2/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/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/38—Flow based 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/02—Topology update or discovery
    • H04L45/026—Details of "hello" or keep-alive messages
    • 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/26—Route discovery packet
    • 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/42—Centralised 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/54—Organization of routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/76—Routing in software-defined topologies, e.g. routing between virtual machines

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

この出願は、2013年10月26日に中国特許庁に出願され、発明の名称を「SDNスイッチにより正確なフロー・エントリを獲得するための方法、およびSDNスイッチ、コントローラ、およびシステム」とする中国特許出願第201310514564.2号の優先権を主張し、その全体が参照によりここに組み込まれる。
本発明は、通信技術の分野、詳細には、SDNスイッチにより正確なフロー・エントリを獲得するための方法、SDNスイッチ、SDNコントローラ、およびSDNシステムに関する。
ソフトウェア定義ネットワーク（Software Defined Network、SDN）は新しいネットワーク・アーキテクチャであり、ますます研究され適用されており、現在のSDNは主にOpenFlow（オープンフロー）プロトコルに基づいて実現されている。OpenFlowプロトコルに基づくSDNネットワークは下記でOpenFlowネットワークと呼ばれ、OpenFlowネットワークはオープンフロー・コントローラ（OpenFlow Controller、OFC）およびオープンフロー・スイッチ（OpenFlow Switch、OFS）を含む。OFSはフロー・テーブル（Flow Table）をローカルに維持管理し、ここでフロー・テーブルは複数のフロー・エントリを含む。転送されるべきパケットがフロー・テーブル内に対応するフロー・エントリを有するならば、パケットはフロー・テーブルに従って転送され、フロー・テーブル内に対応するフロー・エントリがないならば、OFSはOFCからの命令を要求し、OFCはOFSの要求を受信した後にOFSにフロー・テーブル内のフロー・エントリを配送し、OFSは配送されたフロー・エントリを取得し、そしてそのフロー・エントリをフロー・エントリに追加し、それによって新しいフロー・テーブルに従ってパケットを転送する。
OpenFlowネットワークにおいて、OFSは一般に初期フロー・テーブルを獲得する必要があり（すなわち、OFSはOFCに要求を送信し、OFCは要求を受信した後にフロー・エントリを配送する）、それによってOFSはパケットを転送することができる。先行技術において、一般に、フロー・テーブルは制御プレーンがデータ・プレーンから分離された形態で獲得される。
図１を参照されたく、これは先行技術におけるOpenFlowネットワークのアーキテクチャの概要図であり、これはOFC、従来のスイッチ、複数のOFS（OFS1からOFS6）を含み、ここで従来のスイッチ、OFS1からOFS6、およびOFCは制御プレーンを形成し、OFS1からOFS6およびOFCはデータ・プレーンを形成する。OFSは、まず、従来のスイッチの動作モードにおいて、リンク層発見プロトコル（Link Layer Discovery Protocol、LLDP）またはスパニング・ツリー・プロトコル（Spanning Tree Protocol、STP）のようなプロトコルに基づいて、制御プレーンを初期化し、すなわち、制御プレーンが初期化された後に、STPのようなプロトコルを使用することによって生成された転送テーブルを使用することによって様々なOpenFlow制御メッセージが転送され、OFCは制御プレーンを使用することによってOFSに初期フロー・エントリを配送することが可能であり、OFSはそのフロー・エントリを受信し、そしてOFSのフロー・テーブルにそのフロー・エントリを追加し、それによって初期フロー・テーブルを獲得する。さらに、フロー・テーブルに従ってパケットが処理され、データ・プレーンを使用することによってパケットが転送される。
先行技術において、制御プレーンとデータ・プレーンは２つの異なる物理ネットワークであり、１つまたはより多くの従来のスイッチがさらに要求され、これはハードウェアコストを増加させ、加えて、２つのネットワーク管理システムが２つの物理ネットワークについて別個に維持管理されることがさらに必要であり、これは維持管理コストも増加させる。
本発明の実施例は、ソフトウェア定義ネットワークSDNスイッチにより正確なフロー・エントリを獲得するための方法、対応するSDNスイッチ、SDNコントローラ、およびSDNシステムを提供し、本発明の実施例は、SDNスイッチによりパケットを転送するための方法、およびこの方法に対応するSDNスイッチをさらに提供し、最後に、本発明の実施例は、OFSにより経路情報を収集するための方法、およびこの方法に対応するOFSをさらに提供する。本発明の実施例によって提供される、SDNスイッチにより正確なフロー・エントリを獲得するための方法は、ハードウェアコストおよび維持管理コストが高いという、先行技術において存在する課題を解決するために使用される。
第１の態様の第１の実現形態において、本発明の実施例は、第２のSDNスイッチに適用される、ソフトウェア定義ネットワークSDNスイッチにより正確なフロー・エントリを獲得するための方法を開示し、ここで第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、この方法は、
第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信するステップであって、第１の制御メッセージは第１のSDNスイッチの経路情報を搬送し、第１の制御情報は第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、ステップと、
第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、更新された第１の制御メッセージを取得するステップと、
更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信した後に、SDNコントローラが、各々のSDNスイッチによって最終的に更新された第１の制御メッセージに追加された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するように、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに転送するステップと、を含む。
第１の態様の第１の実現形態を参照して、第１の態様の第２の可能な実現形態において、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続はTCP接続を含み、信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、TCP接続は、第２のSDNスイッチにより、第１のSDNスイッチとSDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することによって確立される。
第１の態様の第１の実現形態を参照して、第１の態様の第３の可能な実現形態において、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、
第２のSDNスイッチにより、第１のSDNスイッチとSDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することは、
第２のSDNスイッチにより、第１のSDNスイッチから送信された第１のTCP/IPパケットを受信することと、
受信された第１のTCP/IPパケット内の複数の特徴情報を獲得することであって、特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、前記獲得することと、
複数の特徴情報と第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行うことと、正確な照合が失敗し、かつ受信された第１のTCP/IPパケットが第１のタイプのTCPハンドシェイク・メッセージを搬送すると判定されたならば、複数の特徴情報における１つまたはより多くの特徴情報と正確なフロー・テーブルの間でワイルドカード・マッチ照合を行うことであって、ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートである、前記ワイルドカード・マッチ照合を行うことと、ワイルドカード・マッチ照合が成功したならば、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、第１のタイプのTCPハンドシェイク・メッセージを搬送する受信された第１のTCP/IPパケットを処理し、それによって第１のTCP/IPパケットをSDNコントローラに転送することであって、第１のタイプのTCPハンドシェイク・メッセージは第１のTCPハンドシェイクのメッセージまたは第３のTCPハンドシェイクのメッセージである、前記転送することと、を含む。
第１の態様の第３の実現形態を参照して、第１の態様の第４の可能な実現形態において、第２のSDNスイッチにより、第１のSDNスイッチとSDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することは、
第２のSDNスイッチにより、SDNコントローラから送信された第３のTCP/IPパケットを受信することであって、第３のTCP/IPパケットは第２のハンドシェイクのメッセージを搬送する、前記受信することと、
第３のTCP/IPパケット内の複数の特徴情報を獲得することであって、特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、前記獲得することと、
複数の特徴情報と第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、正確な照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従って転送を行い、照合が失敗し、かつ第３のTCP/IPパケットが第２のTCPハンドシェイクのメッセージを搬送すると判定されたならば、第３のTCP/IPパケットをブロードキャストすることと、をさらに含む。
第１の態様の第２の実現形態から第４の実現形態のいずれかの実現形態を参照して、第１の態様の第５の可能な実現形態において、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、
第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信するステップと、第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、更新された第１の制御メッセージを取得するステップと、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに転送するステップとは、
第２のSDNスイッチにより、第１のSDNスイッチから送信され、第１の制御メッセージを搬送する第２のTCP/IPパケットを受信するステップであって、第２のTCP/IPパケットは複数の特徴情報を含み、特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、ステップと、
第２のSDNスイッチにより、第２のTCP/IPパケット内の特徴情報および正確なフロー・テーブルに従って正確な照合を行い、正確な照合が失敗し、かつ受信された第２のTCP/IPパケットが第１の制御メッセージを搬送すると判定された後に、TCP/IPパケット内の１つまたはより多くの特徴情報および正確なフロー・テーブルに従ってワイルドカード・マッチ照合を行い、ここでワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートであり、ワイルドカード・マッチ照合が成功したならば、第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージを取得し、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、更新された第１の制御メッセージをSDNコントローラに転送するステップとを含む。
第１の態様の第５の実現形態を参照して、第１の態様の第６の可能な実現形態において、ワイルドカード・マッチ照合が失敗したならば、第２のSDNスイッチの利用可能な出力ポートが獲得され、第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報が第１の制御メッセージに追加され、第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報が追加された更新された第１の制御メッセージが、利用可能な出力ポートからSDNコントローラに転送される。
第１の態様の第３から第６の実現形態のいずれか１つを参照して、第１の態様の第７の可能な実現形態において、特徴情報は、宛先MAC、宛先IP、および宛先ポート番号を含み、正確なフロー・テーブル内のフロー・エントリ内の、ワイルドカード・マッチ照合のために使用される照合フィールドは、宛先MAC、宛先IP、および宛先ポート番号であり、複数の特徴情報における１つまたはより多くの特徴情報と正確なフロー・テーブルの間でワイルドカード・マッチ照合を行い、ワイルドカード・マッチ照合が成功したならば、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、第１のタイプのTCPハンドシェイク・メッセージを搬送する受信された第１のTCP/IPパケットを処理することは、
複数の特徴情報における宛先MAC、宛先IP、および宛先ポート番号と、フロー・エントリ内の宛先MAC、宛先IP、および宛先ポート番号の間で照合を行い、照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従って、受信された第１のTCP/IPパケットを処理することを含む。
第１の態様の第１から第７の実現形態のいずれか１つを参照して、第１の態様の第８の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、第１の制御メッセージはOpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを含み、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用され、
第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、更新された第１の制御メッセージを取得するステップは、
第２のSDNスイッチの経路情報を、OFPT_HELLOメッセージ内の、経路情報を搬送するために使用される拡張されたbodyフィールドに追加して、更新されたOFPT_HELLOメッセージを取得するステップを含み、
更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信した後に、SDNコントローラが、各々のSDNスイッチによって最終的に更新された第１の制御メッセージに追加された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するように、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに転送するステップは、
更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、SDNコントローラが、各々のSDNスイッチによって最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するように、第２のSDNスイッチの経路情報が追加された更新されたOFPT_HELLOメッセージをSDNコントローラに転送するステップを含む。
第１の態様の第１から第８の実現形態のいずれか１つを参照して、第１の態様の第９の可能な実現形態において、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに転送するステップは、
第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに直接的に転送するステップであって、最終的に更新された第１の制御メッセージは更新された第１の制御メッセージである、ステップ、または、
１つまたはより多くの他のSDNスイッチを使用することによって、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNに間接的に転送するステップであって、最終的に更新された第１の制御メッセージは、他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、他のSDNスイッチの各々の経路情報を第１の制御メッセージに追加した後に、他のSDNスイッチの各々によってSDNコントローラに最終的に送信された第１の制御メッセージである、ステップを含む。
第１の態様の第１から第９の実現形態のいずれか１つを参照して、第１の態様の第１０の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、この方法は、
SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するステップであって、OFPT_FLOW_MODメッセージは宛先SDNスイッチによって要求される複数の正確なフロー・エントリを搬送する、ステップと、
受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、OFPT_FLOW_MODメッセージ内で搬送された複数の正確なフロー・エントリを抽出し、そして複数の正確なフロー・エントリをローカルな正確なフロー・テーブルに追加するステップと、をさらに含む。
第１の態様の第１から第９の実現形態のいずれか１つを参照して、第１の態様の第１１の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、この方法は、
SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するステップであって、OFPT_FLOW_MODメッセージは、ルーティング経路上に位置する複数のSDNスイッチによって要求される複数の正確なフロー・エントリおよびルーティング経路上の各々のSDNスイッチに対応する経路情報を搬送し、ルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを使用する、ステップと、
受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、第２のSDNスイッチに対応する経路情報に従って、第２のSDNスイッチによって使用される必要がある１つまたはより多くの正確なフロー・エントリを抽出し、抽出が完了した後にOFPT_FLOW_MODメッセージをルーティング経路上の次のノードに転送するステップと、をさらに含む。
第１の態様の第１から第１１の実現形態のいずれか１つを参照して、第１の態様の第１２の可能な実現形態において、経路情報は、第１の制御メッセージを送信または受信するSDNスイッチのID、第１の制御メッセージを受信するために使用されるポート番号、および第１の制御メッセージを送信するために使用されるポート番号を含む。
第２の態様の第１の実現形式において、本発明の実施例は、SDNコントローラに適用される、ソフトウェア定義ネットワークSDNスイッチによりフロー・テーブルを獲得する方法を開示し、ここでSDNコントローラは第２のSDNスイッチに接続され、第２のSDNスイッチは第１のSDNスイッチに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、この方法は、
第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを受信するステップであって、最終的に更新された第１の制御メッセージは更新された第１の制御メッセージを含み、第２のSDNスイッチが、第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信した後に、第２のSDNスイッチにより、第２のSDNスイッチの経路情報を第１の制御メッセージに追加することによって、更新された第１の制御メッセージが取得され、第１の制御メッセージは第１のSDNスイッチの経路情報を搬送し、第１の制御情報は第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、ステップと、
各々のSDNスイッチによって追加され、最終的に更新された第１の制御メッセージ内で搬送された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を獲得するステップと、
ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するステップと、を含む。
第２の態様の第１の実現形態を参照して、第２の態様の第２の可能な実現形態において、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続はTCP接続を含み、信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、TCP接続は、第２のSDNスイッチにより、第１のSDNスイッチとSDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することによって確立される。
第２の態様の第１から第２の実現形態のいずれか１つを参照して、第２の態様の第３の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、第１の制御メッセージはOpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを含み、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用される。
第２の態様の第１から第３の実現形態のいずれか１つを参照して、第２の態様の第４の可能な実現形態において、第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを受信するステップは、
第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを直接的に受信するステップであって、最終的に更新された第１の制御メッセージは更新された第１の制御メッセージである、ステップ、または、
第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージについて、１つまたはより多くの他のSDNスイッチを使用することによって、第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを間接的に受信するステップであって、最終的に更新された第１の制御メッセージは、他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、他のSDNスイッチの各々の経路情報を第１の制御メッセージに追加した後に、他のSDNスイッチの各々によってSDNコントローラに最終的に送信された第１の制御メッセージである、ステップ、を含む。
第２の態様の第１から第４の実現形態のいずれか１つを参照して、第２の態様の第５の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するステップは、
第１のSDNスイッチによって要求される複数の正確なフロー・エントリをOpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージに追加するステップと、
OFPT_FLOW_MODメッセージを受信した後に、第１のSDNスイッチが、OFPT_FLOW_MODメッセージ内で搬送された複数の正確なフロー・エントリを抽出し、そして複数の正確なフロー・エントリをローカルな正確なフロー・テーブルに追加するように、ルーティング経路に従ってOFPT_FLOW_MODメッセージを第１のSDNスイッチに送信するステップと、を含む。
第２の態様の第１から第５の実現形態のいずれか１つを参照して、第２の態様の第６の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するステップは、
ルーティング経路上に位置する複数のSDNスイッチによって要求される複数の正確なフロー・エントリおよびルーティング経路上の各々のSDNスイッチに対応する経路情報を、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージに追加するステップであって、ルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを必要とする、ステップと、
OFPT_FLOW_MODメッセージを受信した後に、他のSDNスイッチが、経路情報およびOFPT_FLOW_MODメッセージ内の経路情報に従って他のSDNスイッチによって要求される正確なフロー・エントリを抽出し、残りの正確なフロー・エントリを転送し、第１のSDNスイッチによって要求される正確なフロー・エントリを第１のSDNスイッチに最終的に転送するように、ルーティング経路に従ってOFPT_FLOW_MODメッセージを他のSDNスイッチに配送するステップと、を含む。
第３の態様の第１の実現形態において、本発明の実施例は、ソフトウェア定義ネットワークSDNスイッチを開示し、ここでSDNスイッチは第２のSDNスイッチであり、第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、第２のSDNスイッチは、
第１のSDNスイッチとSDNコントローラの間で信頼できる接続が確立されるように、第１のSDNスイッチとSDNコントローラの間でメッセージ交換を行うように構成された接続確立ユニットと、
第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信するように構成された第１の受信ユニットであって、第１の制御メッセージは第１のSDNスイッチの経路情報を搬送し、第１の制御情報は、信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、第１の受信ユニットと、
第２のSDNスイッチの経路情報を第１の受信ユニットによって受信された第１の制御メッセージに追加して、更新された第１の制御メッセージを取得する経路追加ユニットと、
更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信した後に、SDNコントローラが、各々のSDNスイッチによって最終的に更新された第１の制御メッセージに追加された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するように、経路追加ユニットが第２のSDNスイッチの経路情報を追加した更新された第１の制御メッセージをSDNコントローラに転送するように構成された転送ユニットと、を含む。
第３の態様の第１の実現形態を参照して、第３の態様の第２の可能な実現形態において、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続はTCP接続を含み、信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、
接続確立ユニットは、具体的には、TCP接続が第１のSDNスイッチとSDNコントローラの間で確立されるように、第１のSDNスイッチとSDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送するように構成される。
第３の態様の第２の実現形態を参照して、第３の態様の第３の可能な実現形態において、第２のSDNスイッチは正確なフロー・テーブルを含み、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、
接続確立ユニットは、
第１のSDNスイッチから送信された第１のTCP/IPパケットを受信するように構成された受信サブユニットと、
受信サブユニットによって受信された第１のTCP/IPパケット内の複数の特徴情報を獲得するように構成された特徴情報獲得サブユニットであって、特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、特徴情報獲得サブユニットと、
特徴情報獲得サブユニットによって獲得された第１のTCP/IPパケット内の複数の特徴情報と、第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、正確な照合が失敗し、かつ受信された第１のTCP/IPパケットが第１のタイプのTCPハンドシェイク・メッセージを搬送すると判定されたならば、複数の特徴情報における１つまたはより多くの特徴情報と正確なフロー・テーブルの間でワイルドカード・マッチ照合を行うように構成された第１の照合サブユニットであって、ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートであり、第１の照合サブユニットは、ワイルドカード・マッチ照合が成功したならば、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、第１のタイプのTCPハンドシェイク・メッセージを搬送する受信された第１のTCP/IPパケットを処理し、それによって第１のTCP/IPパケットをSDNコントローラに転送するように構成され、第１のタイプのTCPハンドシェイク・メッセージは第１のTCPハンドシェイクのメッセージまたは第３のTCPハンドシェイクのメッセージである、第１の照合サブユニットと、を含む。
第３の態様の第３の実現形態を参照して、第３の態様の第４の可能な実現形態において、受信サブユニットは、SDNコントローラから送信された第３のTCP/IPパケットを受信するようにさらに構成され、ここで第３のTCP/IPパケットは第２のハンドシェイクのメッセージを搬送し、
特徴情報獲得サブユニットは、受信サブユニットによって受信された第３のTCP/IPパケット内の複数の特徴情報を獲得するようにさらに構成され、ここで特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、
第１の照合サブユニットは、特徴情報獲得サブユニットによって獲得された第３のTCP/IPパケット内の複数の特徴情報と、第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、正確な照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従って転送を行い、照合が失敗し、かつ第３のTCP/IPパケットが第２のTCPハンドシェイクのメッセージを搬送すると判定されたならば、第３のTCP/IPパケットをブロードキャストするようにさらに構成される。
第３の態様の第１から第４の実現形態のいずれか１つを参照して、第３の態様の第５の可能な実現形態において、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、
第１の受信ユニットは、具体的には、
第１のSDNスイッチから送信され、第１の制御メッセージを搬送する第２のTCP/IPパケットを受信するように構成され、ここで第２のTCP/IPパケットは複数の特徴情報を含み、ここで特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、
経路追加ユニットは、
第２の受信サブユニットによって受信された第２のTCP/IPパケット内の特徴情報および正確なフロー・テーブルに従って正確な照合を行い、正確な照合が失敗し、かつ受信された第２のTCP/IPパケットが第１の制御メッセージを搬送すると判定された後に、TCP/IPパケット内の１つまたはより多くの特徴情報および正確なフロー・テーブルに従ってワイルドカード・マッチ照合を行うように構成された第２の照合サブユニットであって、ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートである、第２の照合サブユニットと、
第２の照合サブユニットのワイルドカード・マッチ照合が成功したとき、第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージを取得するように構成された追加サブユニットと、を含み、
転送ユニットは、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、追加サブユニットの処理の後に取得された更新された第１の制御メッセージをSDNコントローラに転送するように構成された第１の転送サブユニットを含む。
第３の態様の第５の可能な実現方法を参照して、第３の態様の第６の可能な実現形態において、追加サブユニットは、第２の照合サブユニットのワイルドカード・マッチ照合が失敗したならば、第２のSDNスイッチの利用可能な出力ポートを獲得し、第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報を第１の制御メッセージに追加するようにさらに構成され、
転送ユニットは、追加サブユニットが、第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報を追加した更新された第１の制御メッセージを、利用可能な出力ポートからSDNコントローラに転送するように構成された第２の転送サブユニットをさらに含む。
第３の態様の第１から第６の実現形態のいずれか１つを参照して、第３の態様の第７の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、第１の制御メッセージはOpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを含み、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用され、
第１の受信ユニットは、具体的には、接続確立ユニットによって確立された信頼できる接続を使用することによって、第１のSDNスイッチによって送信され、経路情報を収集するために使用されるOFPT_HELLOメッセージを受信するように構成され、ここでOFPT_HELLOメッセージ内の、経路情報を搬送するために使用される拡張されたbodyフィールドは、第１のSDNスイッチの経路情報を搬送し、
経路追加ユニットは、具体的には、第１の受信ユニットによって受信されたOFPT_HELLOメッセージ内の、経路情報を搬送するために使用される拡張されたbodyフィールドに、第２のSDNスイッチの経路情報を追加して、更新されたOFPT_HELLOメッセージを取得するように構成され、
転送ユニットは、具体的には、更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、SDNコントローラが、各々のSDNスイッチによって最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するように、経路追加ユニットが第２のSDNスイッチの経路情報を追加した更新されたOFPT_HELLOメッセージをSDNコントローラに転送するように構成される。
第３の態様の第１から第７の実現形態のいずれか１つを参照して、第３の態様の第８の可能な実現形態において、転送ユニットは、具体的には、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに直接的に転送するように構成され、ここで最終的に更新された第１の制御メッセージは更新された第１の制御メッセージであり、または、
１つまたはより多くの他のSDNスイッチを使用することによって、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNに間接的に転送するように構成され、ここで最終的に更新された第１の制御メッセージは、他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、他のSDNスイッチの各々の経路情報を第１の制御メッセージに追加した後に、他のSDNスイッチの各々によってSDNコントローラに最終的に送信された第１の制御メッセージである。
第３の態様の第１から第８の実現形態のいずれか１つを参照して、第３の態様の第９の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、SDNスイッチは、
SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するように構成された第２の受信ユニットであって、OFPT_FLOW_MODメッセージは宛先SDNスイッチによって要求される複数の正確なフロー・エントリを搬送する、第２の受信ユニットと、
第２の受信ユニットによって受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、OFPT_FLOW_MODメッセージ内で搬送された複数の正確なフロー・エントリを抽出し、そして複数の正確なフロー・エントリをローカルな正確なフロー・テーブルに追加するように構成された第１のフロー・エントリ処理ユニットと、をさらに含む。
第３の態様の第１から第８の実現形態のいずれか１つを参照して、第３の態様の第１０の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、SDNスイッチは、
SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するように構成された第３の受信ユニットであって、OFPT_FLOW_MODメッセージは、ルーティング経路上に位置する複数のSDNスイッチによって要求される複数の正確なフロー・エントリおよびルーティング経路上の各々のSDNスイッチに対応する経路情報を搬送し、ルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを使用する、第３の受信ユニットと、
第３の受信ユニットによって受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、第２のSDNスイッチに対応する経路情報に従って、第２のSDNスイッチによって使用される必要がある１つまたはより多くの正確なフロー・エントリを抽出し、抽出が完了した後にOFPT_FLOW_MODメッセージをルーティング経路上の次のノードに転送するように構成された第２のフロー・エントリ処理ユニットと、をさらに含む。
第３の態様の第１から第１０の実現形態のいずれか１つを参照して、第３の態様の第１１の可能な実現形態において、経路情報は、第１の制御メッセージを送信または受信するSDNスイッチのID、第１の制御メッセージを受信するために使用されるポート番号、および第１の制御メッセージを送信するために使用されるポート番号を含む。
第４の態様の第１の実現形態において、本発明の実施例は、ソフトウェア定義ネットワークSDNコントローラを開示し、ここでSDNコントローラは第２のSDNスイッチに接続され、第２のSDNスイッチは第１のSDNスイッチに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、SDNコントローラは、
第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを受信するように構成された第１の受信ユニットであって、最終的に更新された第１の制御メッセージは更新された第１の制御メッセージを含み、第２のSDNスイッチが、第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信した後に、第２のSDNスイッチにより、第２のSDNスイッチの経路情報を第１の制御メッセージに追加することによって、更新された第１の制御メッセージが取得され、第１の制御メッセージは第１のSDNスイッチの経路情報を搬送し、第１の制御情報は第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、第１の受信ユニットと、
各々のSDNスイッチによって追加され、第１の受信ユニットによって受信された最終的に更新された第１の制御メッセージ内で搬送された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を獲得するように構成された経路獲得ユニットと、
経路獲得ユニットによって獲得されたルーティング経路を通して、正確なフロー・エントリを第１のSDNスイッチに配送するように構成されたフロー・テーブル配送ユニットと、を含む。
第４の態様の第１の実現形態を参照して、第４の態様の第２の可能な実現形態において、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続はTCP接続を含み、信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、TCP接続は、第２のSDNスイッチにより、第１のSDNスイッチとSDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することによって確立される。
第４の態様の第１から第２の実現形態のいずれか１つを参照して、第４の態様の第３の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、第１の制御メッセージはOFPT_HELLOメッセージを含み、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用される。
第４の態様の第１から第３の実現形態のいずれか１つを参照して、第４の態様の第４の可能な実現形態において、第１の受信ユニットは、具体的には、
第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを直接的に受信するように構成され、ここで最終的に更新された第１の制御メッセージは更新された第１の制御メッセージであり、または、
１つまたはより多くの他のSDNスイッチを使用することによって、第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを間接的に受信するように構成され、ここで最終的に更新された第１の制御メッセージは、他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、他のSDNスイッチの各々の経路情報を第１の制御メッセージに追加した後に、他のSDNスイッチの各々によってSDNコントローラに最終的に送信された第１の制御メッセージである。
第４の態様の第１から第４の実現形態のいずれか１つを参照して、第４の態様の第５の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、フロー・テーブル配送ユニットは、具体的には、
第１のSDNスイッチによって要求される正確なフロー・エントリを、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージに追加し、
第１のSDNスイッチがOFPT_FLOW_MODメッセージに従って正確なフロー・エントリを獲得するように、ルーティング経路を通してOFPT_FLOW_MODメッセージを第１のSDNスイッチに送信するように構成される。
第４の態様の第１から第４の実現形態のいずれか１つを参照して、第４の態様の第６の可能な実現形態において、フロー・テーブル配送ユニットは、具体的には、
ルーティング経路上に位置する複数のOFSによって要求される複数の正確なフロー・エントリおよびルーティング経路上の各々のSDNスイッチに対応する経路情報を、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージに追加するように構成され、ここでルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを必要とし、
OFPT_FLOW_MODメッセージを受信した後に、他のSDNスイッチが、経路情報およびOFPT_FLOW_MODメッセージ内の経路情報に従って他のSDNスイッチによって要求される正確なフロー・エントリを抽出し、残りの正確なフロー・エントリを転送し、第１のSDNスイッチによって要求される正確なフロー・エントリを第１のSDNスイッチに最終的に転送するように、ルーティング経路を通してOFPT_FLOW_MODメッセージを他のSDNスイッチに配送するように構成される。
第５の態様の第１の実現形態において、本発明の実施例は、第１のSDNスイッチ、第２のSDNスイッチ、およびSDNコントローラを含むソフトウェア定義ネットワーク・システムを開示し、ここで第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、
第１のSDNスイッチは、経路情報を収集するために使用される第１の制御メッセージを第２のSDNスイッチに送信するように構成され、ここで第１の制御メッセージは第１のSDNスイッチの経路情報を搬送し、第１の制御情報は第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送され、
第２のSDNスイッチは、第１の制御メッセージを受信し、第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、更新された第１の制御メッセージを取得し、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに転送するように構成され、
SDNコントローラは、第２のSDNスイッチによって送信され、更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信し、各々のSDNスイッチによって最終的に更新された第１の制御メッセージに追加された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するように構成される。
第５の態様の第１の実現形態を参照して、第５の態様の第２の可能な実現形態において、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続はTCP接続を含み、信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、TCP接続は、第２のSDNスイッチにより、第１のSDNスイッチとSDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することによって確立される。
第５の態様の第２の実現形態を参照して、第５の態様の第３の可能な実現形態において、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、
第２のSDNスイッチは、具体的には、第１のSDNスイッチから送信された第１のTCP/IPパケットを受信し、受信された第１のTCP/IPパケット内の複数の特徴情報を獲得し、ここで特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、複数の特徴情報と第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、正確な照合が失敗し、かつ受信された第１のTCP/IPパケットが第１のタイプのTCPハンドシェイク・メッセージを搬送すると判定されたならば、複数の特徴情報における１つまたはより多くの特徴情報と正確なフロー・テーブルの間でワイルドカード・マッチ照合を行い、ここでワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートであり、ワイルドカード・マッチ照合が成功したならば、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、第１のタイプのTCPハンドシェイク・メッセージを搬送する受信された第１のTCP/IPパケットを処理し、それによって第１のTCP/IPパケットをSDNコントローラに転送し、ここで第１のタイプのTCPハンドシェイク・メッセージは第１のTCPハンドシェイクのメッセージまたは第３のTCPハンドシェイクのメッセージであり、それによって第１のSDNスイッチ、他のOFS、およびSDNコントローラの間で、信頼できる接続を確立するために使用されるメッセージの交換を実現して、信頼できる接続を確立するように構成される。
第５の態様の第２から第３の実現形態のいずれか１つを参照して、第５の態様の第４の可能な実現形態において、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、
第２のSDNスイッチは、具体的には、第１のSDNスイッチから送信され、第１の制御メッセージを搬送する第２のTCP/IPパケットを受信し、ここで第２のTCP/IPパケットは複数の特徴情報を含み、ここで特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、第２のTCP/IPパケット内の特徴情報および正確なフロー・テーブルに従って正確な照合を行い、正確な照合が失敗し、かつ受信された第２のTCP/IPパケットが第１の制御メッセージを搬送すると判定された後に、TCP/IPパケット内の１つまたはより多くの特徴情報および正確なフロー・テーブルに従ってワイルドカード・マッチ照合を行い、ここでワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートであり、ワイルドカード・マッチ照合が成功したならば、第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージを取得し、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、更新された第１の制御メッセージをSDNコントローラに転送するように構成される。
第５の態様の第１から第４の実現形態のいずれか１つを参照して、第５の態様の第５の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、第１の制御メッセージはOpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを含み、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用される。
第５の態様の第１から第５の実現形態のいずれか１つを参照して、第５の態様の第６の可能な実現形態において、第２のSDNスイッチは、具体的には、
第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに直接的に転送するように構成され、ここで最終的に更新された第１の制御メッセージは更新された第１の制御メッセージであり、または、
１つまたはより多くの他のSDNスイッチを使用することによって、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNに間接的に転送するように構成され、ここで最終的に更新された第１の制御メッセージは、他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、他のSDNスイッチの各々の経路情報を第１の制御メッセージに追加した後に、他のSDNスイッチの各々によってSDNコントローラに最終的に送信された第１の制御メッセージである。
第５の態様の第１から第６の実現形態のいずれか１つを参照して、第５の態様の第７の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、第２のSDNスイッチは、
SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するようにさらに構成され、ここでOFPT_FLOW_MODメッセージは宛先SDNスイッチによって要求される複数の正確なフロー・エントリを搬送し、
受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、OFPT_FLOW_MODメッセージ内で搬送された複数の正確なフロー・エントリを抽出し、そして複数の正確なフロー・エントリをローカルな正確なフロー・テーブルに追加するようにさらに構成される。
第５の態様の第１から第６の実現形態のいずれか１つを参照して、第５の態様の第８の可能な実現形態において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、第２のSDNスイッチは、
SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するようにさらに構成され、ここでOFPT_FLOW_MODメッセージは、ルーティング経路上に位置する複数のSDNスイッチによって要求される複数の正確なフロー・エントリおよびルーティング経路上の各々のSDNスイッチに対応する経路情報を搬送し、ここでルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを使用し、
受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、第２のSDNスイッチに対応する経路情報に従って、第２のSDNスイッチによって使用される必要がある１つまたはより多くの正確なフロー・エントリを抽出し、抽出が完了した後にOFPT_FLOW_MODメッセージをルーティング経路上の次のノードに転送するようにさらに構成される。
第５の態様の第１から第８の実現形態のいずれか１つを参照して、第５の態様の第９の可能な実現形態において、経路情報は、第１の制御メッセージを送信または受信するSDNスイッチのID、第１の制御メッセージを受信するために使用されるポート番号、および第１の制御メッセージを送信するために使用されるポート番号を含む。
第６の態様の第１の実現形態において、本発明の実施例は、ソフトウェア定義ネットワークSDNスイッチによりパケットを転送するための方法を開示し、ここでSDNスイッチは第２のSDNスイッチであり、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは少なくとも１つの正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、この方法は、
第１のSDNスイッチから送信されたパケットを受信するステップであって、パケットは複数の特徴情報を含み、特徴情報は正確なフロー・エントリ内の照合フィールドに対応する、ステップと、
パケット内の特徴情報を獲得するステップと、
特徴情報と正確なフロー・テーブル内の正確なフロー・エントリの間で正確な照合を行い、正確な照合が失敗したならば、複数の特徴情報における１つまたはより多くの特徴と正確なフロー・テーブル内の正確なフロー・エントリの間でワイルドカード・マッチ照合を行い、ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートであり、ワイルドカード・マッチが成功したならば、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従ってパケットを転送するステップと、を含む。
第６の態様の第１の実現形態を参照して、第６の態様の第２の可能な実現形態において、正確な照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従って転送が行われ、
ワイルドカード・マッチ照合が失敗したならば、受信されたパケットはブロードキャストを通して転送される。
第６の態様の第１から第２の実現形態のいずれか１つを参照して、第６の態様の第３の可能な実現形態において、
第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信する。
第６の態様の第１から第３の実現形態のいずれか１つを参照して、第６の態様の第４の可能な実現形態において、
パケットは、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケットであり、パケットは、第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを搬送するために使用される。
第７の態様の第１の実現形態において、本発明の実施例は、ソフトウェア定義ネットワークSDNスイッチを開示し、ここでSDNスイッチは第２のSDNスイッチであり、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、第２のSDNスイッチは、
第１のSDNスイッチから送信されたパケットを受信するように構成された受信ユニットであって、パケットは１つまたはより多くの特徴情報を含む、受信ユニットと、
受信ユニットによって受信されたパケット内の特徴情報を獲得するように構成された獲得ユニットと、
獲得ユニットによって獲得された１つまたはより多くの特徴情報と正確なフロー・テーブル内の正確なフロー・エントリの間で正確な照合を行うように構成された正確な照合ユニットであって、１つまたはより多くの特徴情報は正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、正確な照合ユニットと、
正確な照合ユニットによって行われる正確な照合が失敗したならば、複数の特徴情報における１つまたはより多くの特徴と正確なフロー・テーブル内の正確なフロー・エントリの間でワイルドカード・マッチ照合を行うように構成されたワイルドカード・マッチ照合ユニットであって、ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートである、ワイルドカード・マッチ照合ユニットと、
ワイルドカード・マッチ照合ユニットによって行われるワイルドカード・マッチ照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従ってパケットを転送するように構成された転送ユニットと、を含む。
第７の態様の第１の実現形態を参照して、第７の態様の第２の可能な実現形態において、照合および転送ユニットは、
正確な照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従って転送を行い、
ワイルドカード・マッチ照合が失敗したならば、ブロードキャストを通して転送を行うようにさらに構成される。
第７の態様の第１から第２の実現形態のいずれか１つを参照して、第７の態様の第３の可能な実現形態において、第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信する。
第７の態様の第１から第３の実現形態のいずれか１つを参照して、第７の態様の第４の可能な実現形態において、パケットは、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケットであり、パケットは、第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを搬送するために使用される。
第８の態様の第１の実現形態において、本発明の実施例は、第２のOFSに適用される、オープンフロー・スイッチOpenFlow Switch OFSにより経路情報を収集するための方法を開示し、ここで第２のOFSは第１のOFSおよびオープンフロー・コントローラOpenFlow Controller OFCに接続されて、OpenFlowネットワークを形成し、OFCは帯域内通信の形態で各々のOFSと通信し、この方法は、
第１のOFSによって送信され、経路情報を収集するために使用され、OpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを受信するステップであって、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用され、OFPT_HELLOメッセージは第１のOFSの経路情報を搬送し、OFPT_HELLOメッセージは第１のOFSとOFCの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、ステップと、
第２のOFSの経路情報をOFPT_HELLOメッセージに追加して、更新されたOFPT_HELLOメッセージを取得するステップと、
更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、OFCが、各々のOFSによって最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、OFCと第１のOFSの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のOFSに配送するように、更新されたOFPT_HELLOメッセージをOFCに転送するステップと、を含む。
第８の態様の第１の実現形態を参照して、第８の態様の第２の実現形態において、経路情報は、OFPT_HELLOメッセージを送信または受信するOFSのID、OFPT_HELLOメッセージを受信するために使用されるポート番号、およびOFPT_HELLOメッセージを送信するために使用されるポート番号を含む。
第８の態様の第１から第２の実現形態のいずれか１つを参照して、第８の態様の第３の実現形態において、更新されたOFPT_HELLOメッセージをOFCに転送するステップは、
更新されたOFPT_HELLOメッセージをOFCに直接的に転送するステップであって、最終的に更新されたOFPT_HELLOメッセージは更新されたOFPT_HELLOメッセージである、ステップ、または、
１つまたはより多くの他のOFSを使用することによって、更新されたOFPT_HELLOメッセージをOFCに間接的に転送するステップであって、他のOFSは経路情報を受信された更新されたOFPT_HELLOメッセージに追加して、最終的に更新されたOFPT_HELLOメッセージを取得する、ステップ、を含む。
第９の態様の第１の実現形態において、本発明の実施例は、オープンフロー・スイッチOpenFlow Switch OFSを開示し、ここでOFSは第２のOFSであり、第２のOFSは、第１のOFS、オープンフロー・コントローラOpenFlow Controller OFC、および少なくとも１つの他のOFSに接続されて、OpenFlowネットワークを形成し、OFCは帯域内通信の形態で各々のOFSと通信し、第２のOFSは、
第１のOFSによって送信され、経路情報を収集するために使用され、OpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを受信するように構成された受信ユニットであって、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用され、OFPT_HELLOメッセージは第１のOFSの経路情報を搬送し、OFPT_HELLOメッセージは第１のOFSとOFCの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、受信ユニットと、
第２のOFSの経路情報を受信ユニットによって受信されたOFPT_HELLOメッセージに追加して、更新されたOFPT_HELLOメッセージを取得するように構成された経路情報追加ユニットと、
更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、OFCが、各々のOFSによって最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、OFCと第１のOFSの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のOFSに配送するように、経路情報追加ユニットが第２のOFSの経路情報を追加した更新されたOFPT_HELLOメッセージをOFCに転送するように構成された転送ユニットと、を含む。
第９の態様の第１の実現形態を参照して、第９の態様の第２の実現形態において、経路情報は、OFPT_HELLOメッセージを送信または受信するOFSのID、OFPT_HELLOメッセージを受信するために使用されるポート番号、およびOFPT_HELLOメッセージを送信するために使用されるポート番号を含む。
第９の態様の第１から第２の実現形態のいずれか１つを参照して、第９の態様の第３の実現形態において、転送ユニットは、具体的には、
更新されたOFPT_HELLOメッセージをOFCに直接的に転送するように構成され、ここで最終的に更新されたOFPT_HELLOメッセージは更新されたOFPT_HELLOメッセージであり、または、
１つまたはより多くの他のOFSを使用することによって、更新されたOFPT_HELLOメッセージをOFCに間接的に転送するように構成され、ここで他のOFSは経路情報を受信された更新されたOFPT_HELLOメッセージに追加して、最終的に更新されたOFPT_HELLOメッセージを取得する。
本発明の実施例における、SDNスイッチにより正確なフロー・エントリを獲得するための方法において、SDNコントローラは帯域内の形態で各々のSDNスイッチと通信し、信頼できる接続がまず確立され、そして、確立された信頼できる接続に基づいて各々のSDNスイッチの経路情報を搬送する制御メッセージが伝送され、それによってSDNコントローラは受信された制御メッセージ内で搬送される各々のSDNスイッチの経路情報に従ってSDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、経路に従って正確なフロー・エントリを第１のSDNスイッチに配送することができる。上記の形態において、２つの物理ネットワークを維持管理する必要がなく、それによりハードウェアコストおよび維持管理コストを減少させる。
本発明の実施例における技術的解決策をより明確に記載するために、下記は、実施例または先行技術を記載するために要求される添付図面を簡単に紹介する。明らかに、下記の記載における添付図面は本発明のほんのいくつかの実施例を表わし、この技術分野の当業者は創作的な努力なしでこれらの添付図面から他の図面を依然として導き出し得る。
先行技術におけるOpenFlowネットワークのアーキテクチャの概要図である。 本発明の実施例１による、OFSにより正確なフロー・エントリを獲得するための方法のフローチャートである。 本発明の実施例２による、第２のOFSによる第１のタイプのTCPハンドシェイク・メッセージの処理の概要のフローチャートである。 本発明の実施例２による、フロー・テーブルの概要図である。 本発明の実施例３による、OFSによる第１のTCPハンドシェイクのメッセージの処理の概要の概観図である。 本発明の実施例３による、OFSによる第１のTCPハンドシェイクのメッセージの処理のフローチャートである。 本発明の実施例３による、第１のTCPハンドシェイクのメッセージを搬送するパケットのパケット・ヘッダ内のいくつかのフィールドの概要図である。 本発明の実施例３による、第２のOFSによる第１のTCPハンドシェイクのメッセージのパケットの転送の概要図である。 本発明の実施例３による、第２のTCPハンドシェイクのメッセージを搬送するパケットのパケット・ヘッダ内のいくつかのフィールドの概要図である。 本発明の実施例３による、OFSによる第２のTCPハンドシェイクのメッセージの処理の概要の概観図である。 本発明の実施例３による、OFSによる第２のTCPハンドシェイクのメッセージの処理のフローチャートである。 本発明の実施例３による、第３のTCPハンドシェイクのメッセージを搬送するパケットのパケット・ヘッダ内のいくつかのフィールドの概要図である。 本発明の実施例３による、OFSによる第３のTCPハンドシェイクのメッセージの処理の概要の概観図である。 本発明の実施例３による、OFSによる第３のTCPハンドシェイクのメッセージの処理のフローチャートである。 本発明の実施例４による、OPFT_HELLOメッセージのbodyフィールドへの経路情報の拡張の概要図である。 本発明の実施例４による、OFSによるOPFT_HELLOメッセージの処理のフローチャートである。 本発明の実施例４による、各々のOFSへのOPFT_HELLOメッセージの伝送の概要図である。 本発明の実施例４による、各々のOFSへのOPFT_HELLOメッセージの伝送の他の概要図である。 本発明の実施例５による、OFSのフロー・エントリの概要図である。 本発明の実施例５による、OFCがHelloメッセージを受信した後のOFCによるフロー・エントリの配送のフローチャートである。 本発明の実施例５による、OFSがOFCによって配送されたフロー・エントリを受信した後の処理のフローチャートである。 本発明の実施例６による、OFSのハードウェア構成の図である。 本発明の実施例６による、ソフトウェア・デバイスを使用することによるOFSの実現の概要図である。 本発明の実施例７による、SDNスイッチの概要の構成図である。 本発明の実施例７による、SDNスイッチ内の接続確立ユニットの概要の構成図である。 本発明の実施例７による、SDNスイッチ内の経路追加ユニットの概要の構成図である。 本発明の実施例７による、SDNスイッチ内の転送ユニットの概要の構成図である。 本発明の実施例８による、SDNコントローラの概要の構成図である。 本発明の実施例９による、SDNシステムの概要の構成図である。 本発明の実施例１０による、SDNスイッチによりパケットを転送するための方法の概要のフローチャートである。 本発明の実施例１１による、SDNスイッチの概要の構成図である。 本発明の実施例１２による、OFSにより経路情報を収集するための方法の概要のフローチャートである。 本発明の実施例１３による、OFSの概要の構成図である。
本発明の目的、技術的解決策、および利点をより明確にかつより良く理解できるようにするために、下記は、具体的な実施例および関連する図面を使用することによって詳細に本発明をさらに記載する。
本発明の実施例１は、SDNスイッチにより正確なフロー・エントリを獲得するための方法を提供する。この実施例において、SDNネットワークのアーキテクチャは、現在最も広く適用されているOpenFlow技術に基づいて実現されることが可能であり、または他の技術を使用することによって実現されることが可能であり、これはここで限定されない。この実施例において、OpenFlowネットワークのアーキテクチャと同じように、SDNネットワークのアーキテクチャは１つまたはより多くのSDNスイッチおよび１つまたはより多くのSDNコントローラも含む。これらのSDNスイッチおよびSDNコントローラはOpenFlowプロトコルまたは他のプロトコルを使用することによって通信し得る。OpenFlowプロトコルが使用されるならば、SDNスイッチはOpenFlowスイッチと呼ばれ、略してOFSと呼ばれることが可能であり、SDNコントローラはOpenFlowコントローラと呼ばれることが可能であり、これは他のプロトコルが使用されるとき類似する。
この実施例および下記の実施例において、この解決策は、主に、OFSおよびOFCによって形成されるOpenFlowネットワークに基づいて詳細に記載され、この技術分野の当業者は、SDNコントローラがOFCに等価であり、SDNスイッチがOFSに等価であると考え得る。もちろん、本発明の実施例においてOpenFlowネットワークに基づく関連する解決策は他の類似のプロトコルを使用することによって実現されるSDNネットワークにも適用可能である。
この実施例において、SDNネットワークは従来のスイッチを必要とせず、制御プレーンとデータ・プレーンは両方とも同じ物理ネットワークに基づき、例えば、SDNネットワークがOpenFlowネットワークに基づいて実現されるとき、OFS内の物理ポートは制御パケットを送信および受信するように構成され、パケットを送信および受信するようにも構成される。この実施例および下記の実施例において、「制御プレーン」の概念は先行技術における「制御プレーン」の概念に類似し、すなわち、（OFC および各々のOFSのような）いくつかの関連するノードおよびこれらのノードの間のリンクは、制御メッセージを伝送するために使用されるネットワーク・プレーンを形成し、OFSは、これらのノードの間の制御メッセージの交換によって、OFCによって配送されるフロー・エントリを獲得するが、先行技術と比較して、これらのノードの間の制御メッセージの交換を完了するために従来のスイッチを必要としない。「データ・プレーン」の概念は、背景技術において言及したものにも類似し、すなわち、いくつかの関連するノード（OFCおよび各々のOFS）およびこれらのノードの間のリンクはデータ情報を伝送するために使用されるネットワーク・プレーンを形成し、各々のOFSがOFCによって配送されるフロー・エントリを受信した後に、OFSは、フロー・エントリに従って、受信されたパケットを転送する。同じ物理ネットワークに基づくそのような通信の形態は「帯域内通信」と呼ばれる。
この実施例においてフロー・テーブルを獲得および配送するための方法は、第２のSDNスイッチに適用され、すなわち、この方法は第２のSDNスイッチによって行われる。「第２のSDNスイッチ」は、SDNコントローラに第１のSDNスイッチ（すなわち、フロー・テーブル獲得要求を開始するSDNスイッチ）の制御メッセージを転送するSDNスイッチを指し、ここで、パケットを転送することは、直接的な転送および間接的な転送を含み、従って、ネットワーク内に、第１のSDNスイッチの制御メッセージを転送するように構成された複数のSDNスイッチがあるとき、これらのSDNスイッチの各々は「第２のSDNスイッチ」と考えられ得る。この実施例において、それらの第２のSDNスイッチに基づいて記載が行われ、他の第２のSDNスイッチの処理手順もこの実施例における例における第２のSDNスイッチに類似し、SDNスイッチはこの実施例においてもはや１つずつ記載されないことが理解され得る。この実施例において、SDNコントローラは「帯域内通信」の形態で各々のSDNスイッチと通信する。
具体的には、図２を参照すると、実施例１においてSDNスイッチによりフロー・エントリを獲得するための方法は以下を含む。
S101：第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信し、ここで第１の制御メッセージは第１のSDNスイッチの経路情報を搬送し、第１の制御情報は、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される。
SDNネットワークがOpenFlowネットワークである例を使用して、１つまたはより多くの中間OFSとOFCが信頼できる接続の確立のために使用されるメッセージを交換した後に、信頼できる接続は第１のOFSにおいて確立される。この実施例において、各々のOFSは中継ノードとしての役目をすることが可能であり、それによって１つのノード（例えば、第１のOFS）から他のノード（例えば、OFC）にメッセージを伝送する。
この実施例において、「信頼できる接続」は通信の信頼性を保証するために確立される接続を指し、一般に、「信頼できる接続」はアクノリッジおよび再送のメカニズムを有し、例えば、TCP接続（TCPプロトコルを使用することによって確立される接続）は典型的な信頼できる接続と考えられ、UDPは「信頼できない接続」と考えられ得る。この実施例において、TCP接続またはSCTP接続（SCTPプロトコルを使用する接続）は信頼できる接続として使用されることが可能であり、またはUDPまたはSSHのようなプロトコルはこれらのプロトコルに基づく実現のために追加され、例えば、TCPはSSHと組み合わせて使用され、またはTCPはUDPと組み合わせて使用される。
この実施例において、「経路情報」はネットワーク内のOFSノードの経路を識別するためにOFSノードによって使用される情報であり、一般に、OFSのポート番号は「経路情報」として使用され、ネットワーク内の経路は、パケットがノードのポート（OFSまたはOFCであり得る）から他のノードのポートに送信される伝送リンクを指し、この実施例および下記の実施例において、経路は双方向であり、すなわち、伝送の間にパケットが送信および返信されるチャネルは同じ経路であり、例えば、OFS1がOFS1のポート11からOFS3のポート33にパケットを送信するならば、OFS3はパケットをOFS1に送信する必要があるとき、OFS3もパケットをOFS1のポート11に送信するためにポート33を使用する。経路情報は、また、OFSのポート番号を識別するためにOFSのIDを搬送する。
この実施例において、OFSのポート（port）はプロトコル・ポート（「ソフトウェア・ポート」とも呼ばれ、例えば、HTTPアプリケーションのために定義されたポート80）ではなく物理的なポートを指すことに留意すべきである。OpenFlow技術の分野およびインターネット技術の分野において、ポート（port）は物理的なポートまたはソフトウェア・ポートのいずれかを指すことが可能であり、この技術分野の当業者は文脈に従ってポートの実際の意味を知ることが可能であり、例えば、図４を参照すると、OFSにおけるフロー・エントリ内のinstructionフィールド内に現れるポート番号は物理的なポート番号であり、IP Portフィールド内のポート番号はプロトコル・ポート番号を示す。この実施例および下記の実施例において、この技術分野の当業者によるポートにおける使用および記載の便宜を考慮するために、各々のポートについて、ポートが「物理的なポート」を示すか、または「プロトコル・ポート」を指すかは１つずつ指摘されず、この技術分野の当業者は、文脈を参照して、「ポート」がどのタイプのポートであるかを容易に知り得る。
この実施例において、OpenFlowプロトコルにおいて定義されたいくつかの制御メッセージ（ここで、「第１の制御情報」と名付けられる）は経路情報を収集するために拡張されることが可能であり、例えば、第１の制御情報はOFPT_HELLOメッセージであり得る。具体的には、OFPT_HELLOメッセージのbodyフィールドは拡張されて、経路情報を搬送するために使用され得る。それが他のプロトコルに基づいて実現されるならば、既存のプロトコルを拡張する類似の方法が使用されることも可能であり、または拡張を実現するためにいくつかの新しいフィールドがプロトコルにおいて定義される。
S102：第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、更新された第１の制御メッセージを取得する。
ステップS101における経路情報の内容に類似して、SDNネットワークがOpenFlowネットワークである例を使用して、経路情報はここで第２のOFSのIDおよびポート番号を含む。このステップにおいて、第１のOFSの経路情報が第１の制御メッセージ内に既に存在することに基づいて、経路情報が第１の制御メッセージに追加されて、更新された第１の制御メッセージを取得する。このステップが行われた後に、中間ノードの経路情報は第１の制御メッセージに追加され、この場合、第１のOFSがどのポートから第１の制御メッセージを送信しているか、およびOFSがどのポートから第１の制御メッセージを受信しているかが知られ、第１のOFSと第２のOFSの間の経路は知られることが可能である。
この実施例において、「第１の制御メッセージ」は第１のOFSによってOFCに送信されるOpenFlowプロトコルにおける制御メッセージ、例えば、下記で言及されるOPFT_HELLOメッセージであることに留意すべきである。もちろん、SDNネットワークが他のプロトコルを使用することによって実現されるとき、第１の制御メッセージは他のプロトコルに基づく制御メッセージであることも可能である。第１の制御メッセージの定義は第１の制御メッセージのヘッダ情報によって主に決定される。メッセージの他の部分の内容が変わるとき（例えば、メッセージが第２のOFSを通過するときメッセージ内のいくつかのフィールドに第２のOFSの経路メッセージが追加され得る）、メッセージは、この実施例において依然として「第１の制御メッセージ」と呼ばれ、または、より正確に、「更新された第１の制御メッセージ」である。「第１の制御メッセージ」について異なって述べるのでなければ、この技術分野の当業者は文脈を参照して第１の制御メッセージ（最初に第１のOFSによって送信された第１の制御メッセージ、または第１の制御メッセージが各々のOFSを通過した後に新しい経路情報が追加された第１の制御メッセージ）の意味を理解し得る。
S103：更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信した後に、SDNコントローラが、各々のSDNスイッチによって最終的に更新された第１の制御メッセージに追加された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するように、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに転送する。
このステップにおいて、転送は直接的な転送と間接的な転送に分類され、それに対応して、最終的に更新された第１の制御メッセージも異なる。
SDNネットワークがOFSネットワークである例を依然として使用して、それが直接的な転送であるならば（すなわち、第２のOFSはOFCに直接的に転送し、どの中間OFSも通過しない）、最終的に更新された第１の制御メッセージは更新された第１の制御メッセージであり、それが間接的な転送であるならば（すなわち、第２のOFSは１つまたはより多くの他のOFSを使用することによってOFCに第１の制御メッセージを転送する）、前のOFSによって送信された第１の制御メッセージを受信した後に、他のOFSの各々は他のOFSの各々の経路情報を追加し、それによって第１の制御メッセージは絶えず更新され、全てのOFSの経路情報を含む第１の制御メッセージは最終的にOFCに到達する。
他のOFSが経路情報を追加する形態は、第２のOFSが経路情報を追加する形態と同じであり、すなわち、他のOFSも他のOFSのIDおよびポート番号を第１の制御メッセージに追加して、最終的に更新された第１の制御メッセージを取得し得る。各々のOFCは各々のOFSの経路情報を追加するので、OFCは、第１の制御メッセージ内の経路情報に従って、第１のOFSがどの中間OFSに接続されているか、および第１のOFSがメッセージを送信するためにどのポートを使用しているかを知ることができ、それによってルーティング経路（すなわち、第１のOFSによって送信される第１の制御メッセージがどの中間OFSを通過し、最終的にOFCに到達するかの経路）が獲得されることが可能であり、フロー・エントリはルーティング経路を通して第１のOFSに配送される（実際の応用において、フロー・テーブルはルーティング経路に基づいて他の関連するOFSに配送されることも可能であり、詳細については、下記の実施例５への参照が行われ得る）。
フロー・エントリを受信した後に、第１のOFSはフロー・エントリをローカルなフロー・テーブルに追加し、続いて、フロー・テーブル内の各々のフロー・エントリに従って、受信されたパケットを転送し得る。実際の応用において、各々のOFS（または各々のSDNスイッチ）は同じであり、他のOFSはこの実施例において第１のOFSのようなフロー・エントリを獲得することも可能であり、第１のOFSは、この実施例における「第２のOFS」または「他のOFS」のような様々なタイプのメッセージを転送するために中間OFSとしての役目をすることも可能である。
加えて、このステップにおいて転送される第１の制御メッセージは、また、（TCP/IPプロトコルのような）対応するプロトコルに基づくパケット内で搬送され、いくつかのパケット・カプセル化手順が関与することも可能であり、これは全て先行技術に属し、これらの具体的な実現はここに詳細に記載されない。
この実施例において、フロー・エントリは１つまたはより多くの従来のスイッチを必要とせずに配送されることが可能であり、それによりコストを節約する。加えて、この実施例において、データ・プレーンおよび制御プレーンは両方とも同じ物理ネットワークに属すことが可能であるので、先行技術と比較して、１つの物理ネットワークが減少され、これは、ハードウェアコストをさらに減少させ、加えて、この実施例において、２つのネットワーク管理システムは２つの物理ネットワークのために別個に維持管理される必要がなく、これは、また、維持管理コストを減少させる。
上記の実施例に基づいて、SDNネットワークがOpenFlowネットワークである例を使用して、信頼できる接続を確立するための方法がこの実施例においてさらに記載される。実施例１において、信頼できる接続を確立するための方法は、TCPまたはSCTPのようなプロトコルに基づいて確立することであり得ることが既に記載さており、この実施例において、現在広く使用されているTCPに基づいてさらなる記載が行われ、この実施例を使用することによって、この技術分野の当業者は実現のために（SCTPのような）他の類似のプロトコルを使用することも可能であることが理解され得る。
この実施例において、TCPハンドシェイク・メッセージの基本的な交換手順は先行技術におけるものと同じであり、３方向ハンドシェイク（three-way handshake）が完了される必要があり、すなわち、送信元ノードはSYNメッセージを宛先ノードに送信し（第１のハンドシェイク）、SYNメッセージを受信した後に、宛先ノードはSYN-ACKメッセージ（これは「SYN+ACK」によって示されることも可能である、すなわち、第２のハンドシェイク）を送信元ノードに返信し、そして、送信元ノードはACKメッセージを宛先ノードに送信し（第３のハンドシェイク）、それによって３方向TCPハンドシェイクを完了する。それに対応して、SYNメッセージ、SYN-ACKメッセージ、およびACKメッセージはそれぞれ「第１のハンドシェイクのメッセージ」、「第２のハンドシェイクのメッセージ」、および「第３のハンドシェイクのメッセージ」と呼ばれることが可能であり、各々のメッセージは（TCP/IPパケットのような）パケットの形式で搬送され、これらの技術はこの技術分野の当業者によってよく知られた技術であり、これらは再度ここに詳細に記載されない。
この実施例におけるOpenFlowネットワークにおいて、第１のOFSとOFCの間に１つまたはより多くのOFSがあることが可能であり、従って、ほとんどの場合、第１のOFSはOFCと直接的に相互作用することができず、第２のOFSおよび１つまたは少なくとも１つの他のOFSは交換されるメッセージを伝送するために中継ノードとしての役目をする必要がある。
これらの中継ノードが交換されるメッセージを伝送することを可能とするために、方法は、第１のOFSがTCPハンドシェイク・メッセージを第１のOFSに接続された全てのOFSにブロードキャストし、メッセージを受信した各々のOFSもメッセージを他のOFSにブロードキャストし、最終的にTCPハンドシェイク・メッセージをOFCに伝送することであり、加えて、TCPハンドシェイク・メッセージを受信した後に、OFCはまずTCPハンドシェイク・メッセージを全ての接続されたOFSにブロードキャストし、OFCの応答メッセージを受信した後に、各々のOFSもメッセージをブロードキャストし、最終的に、TCPハンドシェイク・メッセージを第１のOFSに伝送し、それによって３方向TCPハンドシェイクのメッセージの交換が完了されることが可能である。
比較的多くのネットワーク資源がブロードキャストによって占有され、それはブロードキャスト・ストームを引き起こす可能性があり、従って、ネットワーク資源をより良く使用し、ブロードキャスト・ストームの発生を減少させるために、この実施例は、第１のOFSとOFCの間でOFSのためにTCPハンドシェイク・メッセージを転送するための新しい方法を提供する。第２のOFSが第１のOFSによって送信される第１のタイプのTCPハンドシェイク・メッセージ（第１のTCPハンドシェイクのメッセージおよび第３のTCPハンドシェイクのメッセージ）を受信し、他のOFSを使用することによって第１のタイプのTCPハンドシェイク・メッセージをOFCに転送する例を使用して、図３を参照して、この方法は以下を含む。
S21：第２のOFSは第１のOFSから送信されたTCP/IPパケットを受信する。
それは直接的な受信（他の中間OFSがない）または間接的な受信（第１のOFSからの第１のTCP/IPパケットは複数のOFSを通して受信される）であることが可能であり、この実施例はTCP/IPに基づくので、様々なタイプのメッセージは全てTCP/IPパケットを使用することによって搬送される。
S22：TCP/IPパケット内の複数の特徴情報を獲得し、ここで特徴情報は第２のOFSにおけるフロー・テーブル内のフロー・エントリ内の照合フィールドに対応する。
OpenFlowネットワーク内のOFSの全ては転送のために使用されるフロー・テーブルを有し、フロー・テーブルは１つまたはより多くのフロー・エントリ（flow entry、または略してentry）を含むことが可能であり、各々のフロー・エントリは１つまたはより多くの照合フィールド（match field、下記で略して「フィールド」とも呼ばれる）を含み、具体的には、宛先MAC、送信元MAC、送信元IP、宛先IP、およびTCPポート番号のような照合フィールドを含むことが可能であり、加えて、フロー・エントリはフロー・エントリに対応する命令（instruction）、例えば、どのポートを通して転送するか、をさらに有することが可能である。受信されたパケット（様々なタイプのメッセージを搬送するために使用される）がフロー・テーブル照合ポリシーに適合するとき、パケットはフロー・エントリ内の命令に従って転送される。
図４を参照されたく、これはフロー・テーブルの概要図である。フロー・テーブルは正確なフロー・エントリおよびワイルドカード・マッチ・フロー・エントリを含む。各々のフロー・エントリは（宛先MACおよび宛先IPのような）照合フィールドおよびこれらの照合フィールドに対応する命令（instructions）を含む。「照合フィールド」および「命令」に加えて、フロー・エントリは（フロー・エントリがヒットした回数についての統計を収集するために使用されるカウンタcountersのような）他の項目を含むことも可能であり、照合フィールドについて、図に表わされたいくつかの照合フィールドに加えて、他の照合フィールドが含まれることも可能であり、この実施例において、記載の容易さのために、他の全ての情報は完全には列挙されないことに留意すべきである。
正確なフロー・エントリとワイルドカード・マッチ・フロー・エントリの間の相違は、正確なフロー・エントリでは、各々の照合フィールドは正確な値を有し、照合フィールドに等しい値のみが照合フィールドと合致すると考えられ、一方、ワイルドカード・マッチ・フロー・エントリでは、いくつかの照合フィールドの値は限定されず（図４において記号「*」によって示される）、いずれの値も照合フィールドと合致すると考えられることが可能である、ということにある。
図４において、１つのフロー・テーブルは複数のフロー・エントリを有し、他の実施例において、フロー・テーブルは２つのフロー・テーブル、「正確なフロー・テーブル」および「ワイルドカード・マッチ・フロー・テーブル」に区分されることも可能であり、正確なフロー・テーブルは正確なフロー・エントリを含むのみであり、ワイルドカード・マッチ・フロー・テーブルはワイルドカード・マッチ・フロー・エントリを含むのみであり、または、他の実施例において、他の論理的な区分形式があることも可能であり、これはここで限定されない。
加えて、物理的な記憶プレーンにおける「フロー・テーブル」の具体的な実現形態はこの実施例において限定されず、例えば、１つまたはより多くのフロー・テーブル内の内容は、連続した物理空間内に順に記憶され、またはいくつかの物理空間内に記憶され得る。物理空間は（FPGAのような）ハードウェア・デバイス内の組み込みの記憶空間であることが可能であり、または一般的なメモリ空間であることが可能であり、具体的には、SDRAM、DDR SDRAM、flash等は物理空間の記憶媒体として使用されることが可能である。フロー・テーブル照合が行われるとき、照合はハードウェア・デバイスに基づいて行われることが可能であり、または照合はソフトウェアを使用することによって（CPUによりソフトウェア・プログラムを実行することによって）行われることが可能である。
この解決策の様々な実施例において、記載の容易さのために、異なって述べるのでなければ、フロー・テーブルは正確なフロー・テーブル、すなわち、正確なフロー・エントリを含むのみのフロー・テーブルを指すことに留意すべきである。ワイルドカード・マッチ・フロー・テーブルを使用するための方法について、既存の処理の解決策への参照が行われることが可能であり、これはここで扱われない。図４に表わされたワイルドカード・マッチ・フロー・エントリはフロー・テーブルをより明確に記載するために使用されるのみであり、それによって下記で言及される「正確なフロー・テーブルにおいてワイルドカード・マッチ照合を行うこと」の概念をより良く区別する。
このステップにおいて、受信されたTCP/IPパケットはフロー・エントリ内のいくつかの照合フィールドに対応する（宛先MACおよび宛先IPのような）複数の特徴情報を有し、これらの特徴情報はパケット内に（例えば、パケット・ヘッダ内に）カプセル化され、OFSは、パケットを受信し、パケットを解析することによってこれらの特徴情報を獲得することができる。
S23：複数の特徴情報と第２のOFSにおける正確なフロー・テーブルの間で正確な照合を行い、正確な照合が失敗し、かつ受信された第１のTCP/IPパケットが第１のタイプのTCPハンドシェイク・メッセージを搬送すると判定されたならば、複数の特徴情報における１つまたはより多くの特徴情報と正確なフロー・テーブルの間でワイルドカード・マッチ照合を行い、ワイルドカード・マッチ照合が成功したならば、照合において成功したワイルドカード・マッチ照合エントリ内の命令に従って、第１のタイプのTCPハンドシェイク・メッセージを搬送する受信された第１のTCP/IPパケットを処理して、第１のTCP/IPパケットをOFCに直接的または間接的に転送する。
この実施例において、フロー・テーブル照合（ここで、再度強調するために、異なって述べるのでなければ、フロー・テーブルは正確なフロー・テーブルを指す）は２つの場合を含むことが可能であり、第１の場合は、先行技術において使用される正確な照合（exact-match）であり、すなわち、照合は、照合が行われる必要がある内容と照合フロー・エントリ内の各々の照合フィールドの間で行われ、各々の照合フィールドが内容と合致するときのみ照合が成功したと考えられ、他の場合は、ワイルドカード・マッチ照合（wildcard-match）であり、照合が行われる必要がある内容が照合フロー・テーブル内の１つまたはより多くの照合フィールドと合致したならば、ワイルドカード・マッチ照合が成功したと考えられることが可能であり、正確な照合のように各々の照合フィールドが内容と合致する必要がない。ここで、「ワイルドカード・マッチ照合」は、図４におけるワイルドカード・マッチ・フロー・エントリに基づいてワイルドカード・マッチ照合を行うことではなく、正確なフロー・エントリに基づいてワイルドカード・マッチ照合を行うことを指すことは強調される必要がない。
速度および柔軟性に考慮すると、この実施例において、正確な照合はハードウェアを使用することによって実現されることが可能であり、ワイルドカード・マッチ照合はソフトウェアを使用することによって実現されることが可能である。ソフトウェアとハードウェアを組み合わせるシステムにおいて、CPUはインタフェースを使用することによってハードウェア・デバイスと相互作用して、フロー・テーブルを共有することが可能であり、それによってソフトウェアとハードウェアのフロー・テーブル照合を実現する。フロー・テーブルを共有する複数の形態があることが可能であり、例えば、ソフトウェアが照合を必要とするとき、ソフトウェアはインタフェースを使用することによってハードウェア・メモリからコピーを獲得し、またはハードウェアがフロー・テーブルを更新するとき、ハードウェアはインタフェースを使用することによってコピーをソフトウェアに送信し、フロー・テーブルを共有する具体的な形態またはその形態に類似する等価な形態（例えば、ポリシーを使用することによっていくつかの特定のフロー・エントリをコピーするのみである）は、ソフトウェアとハードウェアのフロー・テーブル照合が共有を通して完了されることが可能である限り、この実施例において限定されない。
このステップにおいて、正確な照合がフロー・テーブルにおいてまず行われ、正確に合致するフロー・エントリがない（すなわち、フロー・テーブル内の各々の照合フィールドと合致することができるフロー・エントリがない）ならば、「ワイルドカード・マッチ照合」がフロー・テーブルにおいて行われ、すなわち、複数の特徴情報における１つまたはより多くの特徴情報がフロー・テーブル内のフロー・エントリ内の１つまたはより多くの（全てが要求されるわけではない）照合フィールドと合致するかどうかが判定され、合致するならば、TCPハンドシェイク・メッセージは照合において成功したフロー・エントリ内の命令に従って処理され、それによってハンドシェイク要求メッセージをOFSに直接的または間接的に転送する。例えば、第２のOFSが第１のOFSによって送信された第１のハンドシェイクのメッセージ（SYNメッセージ）を受信した後に、フロー・エントリがワイルドカード・マッチ照合において成功したならば、処理は照合において成功したフロー・エントリ内の命令に従って行われ、例えば、特定のポートから転送され、他のOFSに転送され、および他のOFSを使用することによってOFCに転送される。第２のOFSによって転送されるパケットを受信した後に、他のOFSは第２のOFSのように処理を行い、またはブロードキャストを通してまたは他の形式を使用することによって処理を依然として行い得る。
記載の容易さのために、ここで、正確なフロー・エントリ内の「ワイルドカード・マッチ照合」のために使用される照合フィールドは「ワイルドカード・マッチ照合フィールド」であり、「ワイルドカード・マッチ照合フィールド」を有する正確なフロー・エントリは「ワイルドカード・マッチ照合エントリ」と呼ばれ、これらのワイルドカード・マッチ照合フィールド全てが照合において成功したとき、パケットはワイルドカード・マッチ照合フィールドに対応する命令を使用することによって第２端に転送されることが可能である。このステップにおいて、フロー・テーブルにおいて「ワイルドカード・マッチ照合」を行う目的は、ハンドシェイク要求メッセージを第２端に直接的または間接的に転送することである。１つまたはより多くの照合フィールドが「ワイルドカード・マッチ照合フィールド」として具体的に選択されるとき、これらのいくつかの照合フィールドに対応する命令を使用することによって決定される転送ルートが最終的に第２端に到達することができるルートである限り、メッセージは１つまたはより多くの照合フィールドに対応する命令（命令の内容は一般にどのポートから転送するかである）を使用することによって最終的に第２端に転送されることが可能であり、それによりワイルドカード・マッチ照合の間に使用される照合フィールドとして使用される。一般的なワイルドカード・マッチ照合フィールドは、宛先MAC、宛先IP、および宛先ポート（プロトコル・ポート）であることが可能であり、一般に、第２端の具体的な応用はこれらのいくつかの照合フィールドを使用することによって決定されることが可能であり、従って、照合はメッセージを第２端に転送するためにいくつかのフィールドにおいて行われることが可能である。もちろん、実際の応用において、それの（宛先IPおよび宛先ポートのような）２つの情報または１つの情報でさえ第２端のアプリケーションを決定することもできるならば、照合はそれの２つまたは１つの情報において行われることが可能であり、最終的に、パケットは照合フィールドに対応する命令を使用することによって第２端に送信される。正確さを改善するために、照合が行われる必要がある他のフィールドを追加することはこの実施例において限定されない。
第２のOFS（または他の中間OFSの各々）が前にかつ取得されたOFCと通信するとき、ワイルドカード・マッチ照合のために使用される上記のフロー・エントリはOFCによって配送されることが可能であり、ワイルドカード・マッチ照合が行われるとき依然として有効である。これらのフロー・エントリは他のいくつかの情報を転送するために本来使用されるが、これらのフロー・エントリは２つのノードの間の転送経路を含み得るので、この実施例はこれらのフロー・エントリ内に存在する経路を使用することによってワイルドカード・マッチ照合を通してより正確な転送を実現する。もちろん、そのようなフロー・エントリは前に記憶されず、または記憶されていたならば、しかし、フロー・エントリは無効であり、ワイルドカード・マッチ照合の間に存在せず、「ワイルドカード・マッチ照合」は成功することができず、この場合、パケットはブロードキャストを通して転送され得る。
この実施例において、特徴情報は、宛先MAC、宛先IP、および宛先ポート番号を含むことが可能であり、フロー・テーブル内のフロー・エントリ内の照合フィールドは、宛先MAC、宛先IP、および宛先ポート番号を含み、それによって、ステップS23において、「複数の特徴情報における１つまたはより多くの特徴情報がフロー・テーブル内のフロー・エントリ内の１つまたはより多くの照合フィールドと合致するかどうかを判定すること」は、具体的には、複数の特徴情報における宛先MAC、宛先IP、および宛先ポート番号がフロー・テーブル内のフロー・エントリ内の宛先MAC、宛先IP、および宛先ポート番号と合致するかどうかを判定すること、を含み得る。照合のために使用される上記のいくつかの特徴情報は比較的一般的な特徴情報であり、１つまたはより多くの特徴情報を減少させまたは追加することはこの実施例において限定されない。
転送は、この実施例においてワイルドカード・マッチ照合を正確なフロー・テーブルにおいて行うことによって実現され、それによって第１のタイプのハンドシェイク・メッセージはブロードキャストの必要がなく転送されることも可能であり、それによりブロードキャスト回数を減少させ、これは資源をより良く減少させ、ブロードキャスト・ストームを抑えることができる。
上記の実施例に基づいて、実施例２における３方向TCPハンドシェイク・メッセージの交換がこの実施例において詳細に記載される。
図５を参照されたく、これはこの実施例におけるOpenFlowネットワークの概要図であり、これは複数のOFS、OFS1からOFS6、および１つのOFCを含む。ここで、OFS1は第１のOFSであり、OFS3は第２のOFSであり、OFS1に直接的に接続されると仮定すると（もちろん、実際、複数の中間OFSがさらに含まれ得る）、残りのOFS2およびOFS4からOFS6は上記の実施例における「他のOFS」と考えられ得る。
１．第１のハンドシェイク
上記の実施例に基づいて、図５は第１のTCPハンドシェイクの交換の簡単な手順を表わし、すなわち、第１のOFSは第１のTCPハンドシェイクのメッセージをまずブロードキャストし、これはTCP_Reqによって示される。メッセージは具体的にはTCP/IPパケットであり、パケット・ヘッダ内のSYNは1に設定され、ACKは0に設定される。受信の後に、第２のOFS（OFS3）はワイルドカード・マッチを通してフロー・テーブルを探索し、合致するフロー・エントリがあるならば、命令を使用することによって転送ポリシーを行い、例えば、図５におけるOFS5に転送する。同様に、OFS5もワイルドカード・マッチを通してフロー・テーブルを探索し、合致するフロー・エントリがあるならば、命令を使用することによって転送ポリシーを行い得る。図５においてOFS3もOFS5もブロードキャストする必要がなく、次のホップへの転送は特定のポートを通して行われるので、ネットワーク資源は減少される。
具体的には、図５に基づいて、図６を参照すると、この実施例における３方向TCPハンドシェイクにおける第１のハンドシェイクは下記の方法を使用することによって完了され得る。
S31：第１のOFSは電源オンされ、そしてパラメータを環境設定する。
ここで、図５において第１のOFSはOFS1であると仮定し、ネットワーク・ケーブルがOFS1に挿入され、OFS1が電源オンされた後に、OFS1は、OFS1のIPアドレスを環境設定すること（例えば、コマンド・ラインを使用することによって環境設定すること）を含めて、いくつかのパラメータを環境設定し、関連付けされたOFCのIPアドレス、ポート番号、および接続形態（TCP、SSL、等）を環境設定し、具体的な環境設定の方法は先行技術であり、ここに詳細に記載されない。
S32：第１のOFSはTCP接続を確立するために使用される第１のTCPハンドシェイクのメッセージ（TCP_Req）を生成し、第１のOFSのポート（物理的なポート）を使用することによって第１のTCPハンドシェイクのメッセージを外部にブロードキャストする。TCP_Reqは具体的にはTCP/IPパケットであり、図７を参照されたく、これはパケット内に含まれるいくつかのフィールドを表わし、これらのフィールドは下記のように設定される。
src_mac：第１のOFSのMACアドレス、そしてsrcはsourceの略語であり、「送信元」を示し、この明細書中の他の場所におけるsrcの意味は異なって述べるのでなければ同じであり、
src_ip：第１のOFSのIPアドレス、
dst_ip：S31において指定されたOFCのIPアドレス、そしてdstはdestinationの略語であり、「宛先」を示し、この明細書中の他の場所におけるdstの意味は異なって述べるのでなければ同じであり、
src_port：固定されたポート番号（プロトコル・ポート番号、これはTCPプロトコルがここで使用されるのでTCPポート番号であり、下記のプロトコル・ポート番号も異なって述べるのでなければTCPポート番号を指す）、例えば、「36653」に設定されることが可能であり、
dst_port：S31において指定されたOFCのポート番号（プロトコル・ポート番号）、例えば、「6633」、
dst_mac：擬似MACアドレス、FF-FF-FF-FF-FF-FF、アドレスは、他のOFSが、受信の後に、特別な目的のために使用される値を知り、パケットを廃棄しないことを可能にするために使用される他の合意された値であることも可能であり、全てFのために既存のネットワーク内でデフォルトによってブロードキャストされるので、値は既存のネットワークと互換性があるように設定され、
SYNビットは1に設定され、ASKビットは0に設定され、そして、
初期TTL値は例えば30に設定され、TTL値はネットワーク内のパケットの生存期間を定義するために使用される。
S33：第２のOFSは、第１のOFSによって送信される第１のTCPハンドシェイクのメッセージのパケットを転送するために、ワイルドカード・マッチを通してフロー・テーブルを探索する。第１のTCPハンドシェイクのメッセージを受信した後に、他のOFSの各々も第２のOFSのように類似の処理を行い、最終的に、第１のTCPハンドシェイクのメッセージをOFCに転送する。
図８を参照すると、S33は具体的には以下を含む。
S331：パケットのheader（ヘッダ）を解析する。
続くステップにおける判定のために使用される、TTL、送信元／宛先MAC、送信元／宛先IP、および送信元／宛先ポートのような、複数の情報が、ヘッダが解析された後に取得されることが可能であり、続いて、各々のOFSが第２／第３のハンドシェイクのメッセージを処理するとき、各々のOFSも解析を通してこれらの情報を取得し、解析を通して取得された情報に従って判定を行う。
S332：TTLが0より大きいかどうかを判定し、大きいならば、S333を行い、そうでないならば、パケットを廃棄する。
S333：フロー・テーブルにおいて正確な照合を行い、合致したエントリがあるならば、合致したエントリ内の「命令」フィールド内の値に従って転送を行うS334を行い、合致したエントリがないならば、S335を行う。
処理の効率を改善し、柔軟性に考慮するために、上記のステップS331からステップS334は、処理速度を増加させるために（ASICまたはFPGAのような）ハードウェアを使用することによって実現されることが可能であり、続くステップは、ソフトウェア（CPUがソフトウェア・コードを実行する）を使用することによって実現されることが可能であり、これはより柔軟である。
S335：宛先IPアドレスがそれ自身と関連付けされたOFCのIPアドレスであるかどうかを判定し、そうであるならば、ステップS336を行い、そうでないならば、パケットを廃棄する。
S336：宛先ポート番号がそれ自身と関連付けされたOFCのポート番号であるかどうかを判定し、そうであるならば、ステップS337を行い、そうでないならば、パケットを廃棄する。
S337：「ACK!=1 & SYN=1」（ACKビットが１に等しくなく、SYNビットが１に等しい）であるかどうかを判定し、そうであるならば、ステップS338を行い、そうでないならば、パケットを廃棄する。このステップは、それが第１のハンドシェイクのメッセージであるかどうかを判定するために使用される。この実施例および下記の実施例において、OFSは実際の応用において多くのメッセージを受信し、異なるメッセージについて異なる処理の形態を有するので、OFSはメッセージがどのタイプのメッセージであるかを判定する必要があり、それが実際にコードによって実現されるとき、そのステップの前または後にそれが他のメッセージであるかどうかを判定するために使用される他のいくつかのコードがあることが可能であり、この実施例および下記の実施例において、記載の容易さのために、コードは表わされないが、この実施例に関連するコードのみが表わされることに留意すべきである。
ステップS335からステップS337の機能はOFSによって処理される必要がないパケットを廃棄することである。
S338：フロー・テーブルにおいてワイルドカード・マッチ照合を行い、合致したエントリがあるならば、合致したエントリ内の「命令」フィールド内の値に従って転送を行うS339を行い、合致したエントリがないならば、ブロードキャストするS3310を行う。
S339：ワイルドカード・マッチ照合において成功することができた合致したエントリがあるとき、合致したエントリ内の「命令」フィールド内の値に従って転送を行う。合致したエントリがないならば、ブロードキャストが行われ得る。
上記のS33は、第２のOFSによりパケットを処理および転送する手順であり、ブロードキャストはワイルドカード・マッチを通してフロー・テーブルを探索することによって減少され、それによりネットワーク資源を減少させ、ブロードキャスト・ストームを抑える。
他のOFSが第２のOFS（例えば、OFS3）によって使用される同じ形態で転送を行うことも可能であり、それによって最終的にパケット内の第１のハンドシェイクの要求メッセージ（TCP_Req）をOFCに伝送する。
例えば、OFS3およびOFS5がそのような転送および処理手順を使用することも可能である。図５において、OFS3とOFS5の両方はフロー・テーブルにおいてワイルドカード・マッチ照合を行うことができ、それによって２つのOFSはブロードキャストの必要がなくパケットをOFCに転送することができると仮定する。もちろん、実際、フロー・テーブルにおける照合（フロー・テーブルにおける正確な照合およびワイルドカード・マッチ照合を含む）が失敗したならば、パケットはブロードキャストを通して転送されることも依然として可能であり、例えば、OFS3はOFS5およびOFS2にブロードキャストし、OFS5はOFS4、OFS6、およびOFCにブロードキャストする。
続いて、パケットを受信した後、OFCはヘッダを解析し、パケットの宛先MACアドレスが全てFであるので、OFCはパケットを一般的なブロードキャスト・パケットとして処理し、レイヤ2アドレスを除去し、パケットのレイヤ3の内容において下記の処理を行う（合意されたMACアドレスが使用されるならば、OFCは、また、宛先MACアドレスが合意されたMACアドレスであることを知った後に下記の処理を行う）。
OFCはパケット内の宛先IPがOFCのIPに等しいかどうか、およびパケット内の宛先ポート番号がOFCによりOFCのTCP接続およびポート番号を聴取するためのポート番号に等しいかどうかを判定し、それらの一方がそうでない限りパケットを廃棄し、両方がそうであるならば、「ACK!=1 & SYN=1」が満たされるかどうかを判定し続け、満たされるならば、第１のハンドシェイクは成功し、満たされないならば、OFCは、また、パケットを廃棄する。上記のいくつかの判定の順序は限定されないことに留意すべきである。
２．第２のハンドシェイク
第１のハンドシェイクが成功した後に、OFCは、受信されたTCP_Reqメッセージに従って第２のハンドシェイクのメッセージ（TCP_Res）を構築し、ここでメッセージは具体的にはTCP/IPパケットである。図９を参照されたく、これは第２のハンドシェイクのメッセージを搬送するパケットのパケット・ヘッダ内のフィールドと第１のハンドシェイクの間の対応の図を表わし、TCP_Resのパケット・ヘッダは次のように設定される。
TCPdst_mac：TCP_Reqのパケット・ヘッダ内のsrc_macに等しい、第１のOFSのMACアドレス、
src_mac：OFCのMACアドレス、
src_ip：TCP_Reqのパケットheader内のdst_ipに等しい、OFCのIPアドレス、
dst_ip：第１のOFSのIPアドレス、
src_port：TCP_Reqのパケットheader内のdst_portに等しい、OFCの、Openflowアプリケーションを聴取するために使用されるTCPポート番号、
dst_port：TCP_Reqのパケットheader内のsrc_portに等しい、OFSの、Openflowアプリケーションを聴取するために使用されるTCPポート番号、
ACKビットおよびSYNビットの両方は「1」に設定され、そして、
初期TTL値が設定される。
第２のハンドシェイクのメッセージを構築した後に、OFCは、第２のハンドシェイクのメッセージをOFSに送信し、第２のハンドシェイクのメッセージをOFCに接続された１つまたはより多くのOFSに送信し得る。好ましくは、OFCは第２のハンドシェイクのメッセージを第１のハンドシェイクのメッセージを受信したOFSに送信し、または極端な場合、OFCは第２のハンドシェイクのメッセージをブロードキャストし得る。
第２のハンドシェイクのメッセージを受信した後に、各々のOFSはフロー・テーブルにおいて正確な照合をまず行い、照合が成功したならば、特定のポートを使用することによって第２のハンドシェイクのメッセージを転送し、照合が失敗したならば、第２のハンドシェイクのメッセージをブロードキャストする。第２のハンドシェイクのメッセージを転送するとき、OFSはワイルドカード・マッチ照合の形態でフロー・テーブルにおいて照合を行わない。これは、実際のシナリオにおいて、第１のOFSは一般に新しいOFSであり、第１のOFSに転送されるフロー・エントリは他のOFS内に存在せず、従って第２のハンドシェイクのメッセージはフロー・テーブルにおいてワイルドカード・マッチ照合を行う形態で正確に転送されることが可能でないからである。もちろん、第１のOFSに転送されるフロー・エントリが同じフロー・エントリ内に実際に存在するシナリオにおいて、正確な転送は、ブロードキャストを通して転送を行う代わりにフロー・テーブルにおいてワイルドカード・マッチ照合を行う形態でポートから実現され得る。
加えて、第２のハンドシェイクのメッセージを処理するとき、OFSがOFCからの第２のハンドシェイクのメッセージがOFSに送信されると判定したならば、OFSは、ローカルに記憶される、OFCのIPとMACの間のマッピング関係を更新し、元の擬似MAC（全てF）をOFCの実際のMACアドレスで置換し、それによってOFCに送信されるべきパケットが続いて構築されるときに使用される。
図１０を参照されたく、これは各々のOFSによる第２のハンドシェイクのメッセージの処理の概要図であり、具体的には、図１１を参照されたく、各々のOFSは以下を含む下記の方法を使用することによって第２のハンドシェイクのメッセージを転送し得る。
S51：ヘッダを解析する。
ヘッダが解析された後に、TTL、送信元／宛先MAC、および送信元／宛先IPのような複数の情報が取得され得る。
S52：TTLが0より大きいかどうかを判定し、大きいならば、S53を行い、そうでないならば、パケットを廃棄する。
S53：フロー・テーブルにおいて正確な照合を行い、照合が成功したならば、「命令」フィールド内の値に従ってパケットを転送し（例えば、パケットを特定のポートに転送する）、照合が失敗したならば、S54を行う。
処理の効率を改善し、柔軟性に考慮するために、上記のいくつかのステップは、ハードウェアを使用することによって実現されることが可能であり、下記のステップは、ソフトウェアを使用することによって実現されることが可能である。
S54：宛先MACがOFSのMACアドレスであるかどうかを判定し、そうであるならば、ステップS55を行い、そうでないならば、ステップS59を行う。宛先MACアドレスがOFSのMACアドレスであると判定されたならば、それはパケットがOFSに送信されることを示し、この場合、ステップS55からステップS58が行われ、そうでないならば、それはパケットが他のOFSに送信されることを示し、OFSは転送を行うための中間OFSであり、この場合、ステップS59からステップS6が行われる。それがOFSに送信されるパケットであるかどうかは宛先IPを使用することによって判定されることが可能であるが、実際、MACはレイヤ２プロトコルであり、IPより前のパケット・ヘッダから解析することを通して取得されるので、従って、MACを使用することによって判定することは処理速度を向上させることができる。
S55：送信元IPアドレスがそれ自身と関連付けされたOFCのIPアドレスであるかどうかを判定し、そうであるならば、ステップS56を行い、そうでないならば、パケットを廃棄する。
S56：送信元ポート番号がそれ自身と関連付けされたOFCのポート番号であるかどうかを判定し、そうであるならば、ステップS57を行い、そうでないならば、パケットを廃棄する。
S57：「ACK=1 & SYN=1」（ACKビットおよびSYNの両方が1である）が満たされるかどうかを判定し、満たされるならば、ステップS58を行い、そうでないならば、パケットを廃棄する。
S58：OFSはOFCのIPとMACアドレスの間のマッピング関係を更新し、すなわち、OFCのIPアドレスに対応する実際のMACアドレスを記録し（第１のOFSによって送信される擬似MACは第１のハンドシェイクの間に受信され、ここで更新される必要がある）、それによってOFCに送信されるべきパケットが続いて構築されるとき、パケット・ヘッダ内の、設定される必要があるOFCのMACアドレスは更新された値に従って設定されることが可能である。この時点で、第２のTCPハンドシェイクは完了する。
S59：送信元IPアドレスがそれ自身と関連付けされたOFCのIPアドレスであるかどうかを判定し、そうであるならば、ステップS510を行い、そうでないならば、パケットを廃棄する。
S510：送信元ポート番号がそれ自身と関連付けされたOFCのポート番号であるかどうかを判定し、そうであるならば、ステップS511を行い、そうでないならば、パケットを廃棄する。
S511：「ACK=1 & SYN=1」が満たされるかどうかを判定し、満たされるならば、ステップS512を行い、そうでないならば、パケットを廃棄する。
S512：パケットをブロードキャストする。
上記のステップを使用することによって第２のハンドシェイクのメッセージを搬送するパケットは最終的に第１のOFS（OFS1）に伝送されることが可能であり、それによって第２のハンドシェイクを完了する。
３．第３のハンドシェイク
OFCによって送信されたTCP_Resを受信した後に、第１のOFS（OFS1）は第３のハンドシェイクのメッセージ（TCP_Req'）を構築し、ここでメッセージは具体的にはTCP/IPパケットである。図１２を参照されたく、これは第３のハンドシェイクのメッセージのパケット・ヘッダ内のフィールドと上記の２度のハンドシェイクの間の対応のテーブルであり、パケット・ヘッダ内のフィールドは下記のように設定される。
dst_mac：OFCのMACアドレス、
src_mac：第１のOFSのMACアドレス、
src_ip：第１のOFSのIPアドレス、
dst_ip：OFCのIPアドレス、
src_port：第１のOFSの、TCP接続を聴取するために使用されるポート番号、
dst_port：OFCの、TCP接続を聴取するために使用されるポート番号、
ACKは「1」に設定され、SYNは「0」に設定され、そして、
初期TTL値が設定される。
第１のOFSは構築されたパケットをブロードキャストする。図１３を参照されたく、これは第３のハンドシェイクのメッセージの第１のOFSからOFCへの送信の概要図である。OFS1はフロー・テーブルを依然として有さないので、OFS1は依然としてパケットをブロードキャストする必要があり、パケットを受信した後に、各々の中間OFSはフロー・テーブルにおいてワイルドカード・マッチ照合を行う形態で特定のポートからパケットを転送するか、またはブロードキャストを通してパケットを転送し得る。具体的には、図１４を参照すると、各々のOFSは下記の方法に従って処理を行い得る。
S71：ヘッダを解析する。
TTL、ポート番号、およびIPアドレスのような情報が取得される。
S72：TTLが0より大きいかどうかを判定し、大きいならば、S73を行い、そうでないならば、パケットを廃棄する。
S73：フロー・テーブルにおいて正確な照合を行い、合致したエントリがあるならば、合致したエントリ内の「命令」フィールド内の値に従って転送を行い、合致したエントリがないならば、S74を行う。
上記の３つのステップはハードウェアを使用することによって処理されて、処理速度を向上させることが可能であり、続くステップはソフトウェアを使用することによって処理されて、処理の柔軟性を改善することが可能である。
S74：宛先IPアドレスがそれ自身と関連付けされたOFCのIPアドレスであるかどうかを判定し、そうであるならば、S75を行い、そうでないならば、パケットを廃棄する。
S75：宛先ポート番号がそれ自身と関連付けされたOFCのポート番号であるかどうかを判定し、そうであるならば、S76を行い、そうでないならば、パケットを廃棄する。
S76：「ACK=1 & SYN!=1」（ACKビットは1であり、SYNビットは1でない）かどうかを判定し、そうであるならば、ステップS77を行い、そうでないならば、パケットを廃棄する。
S77：フロー・テーブルにおいてワイルドカード・マッチ照合を行い、照合が成功したならば、照合において成功した合致したエントリ内の「命令」フィールド内の値に従ってパケットを転送し、照合が失敗したならば、パケットをブロードキャストする。
S77におけるフロー・テーブルにおいてワイルドカード・マッチ照合を行う形態は、資源を減少させ、ブロードキャスト・ストームを防止することができる。
各々のOFSにより、フロー・テーブルにおいてワイルドカード・マッチ照合を行う形態でパケットを転送するための方法は、TCP接続を確立する特定の応用シナリオにおいて必ずしも限定されず、この実施例における「フロー・テーブルにおいてワイルドカード・マッチ照合」を行う形態は、複数のOFSがOFCとの交換およびOFCへの転送を行うことが要求されるシナリオが関与する限り使用されることが可能であることに留意すべきである。
上記の実施例に基づいて、各々のOFSが経路情報を制御メッセージにどのように追加するかの方法は具体的にはこの実施例において記載される。
この実施例において、制御メッセージはいくつかのプロトコルにおいてユーザ定義の制御メッセージを使用することが可能であり、または既存の資源をより良く使用し、より容易に実現するために、いくつかの既存のプロトコルにおける制御メッセージは拡張されることが可能であり、それによって制御メッセージは経路情報を搬送することができる。この実施例において、OpenFlowプロトコルにおけるOPFT_HELLOメッセージのbodyフィールドは拡張され、それによってbodyフィールドは経路情報を搬送することができる。
OpenFlowプロトコルはTCP/IPレイヤより上のプロトコルであり、TCP/IPの使用において搬送される。OpenFlowプロトコルにおけるOPFT_HELLOメッセージはバージョン情報をネゴシエーションするために使用され、そのbodyフィールドは現在予約され、使用されず、従って、メッセージはbodyフィールドに基づいて拡張され得る。
経路情報はネットワーク内の経路を形成するために各々のノードによって要求される情報を識別するために使用され、ネットワーク内の経路（または、「ルーティング経路」とも呼ばれる）は、送信元ノードからのパケットが他の１つまたはより多くのノードを通過し、宛先ノードに到達する経路を指す（もちろん、パケットは中間ノードを通過せずに宛先ノードに直接的に到達することも可能である）。ネットワークにおいて、パケットが、そのノードのどのポートから入力され、どのポートから出力されるかが知られているならば（ここで、ポートは全て「物理的な」ポートである）、経路内の全体の経路の完全な形成のためにノードによって提供される経路のセグメントは知られることが可能であり、各々のノードがそのような経路情報を有するならば、送信元ノードから宛先ノードへの全体の経路は決定されることが可能である。
経路情報は、具体的には、OFSのID、制御メッセージを受信するためにOFSによって使用されるポート番号（物理的なポート番号）、および制御メッセージを送信するためにOFSによって使用されるポート番号（物理的なポート番号）を含み得る。OFSのIDはOFSを識別するために使用され、OFCがOFSを識別することを可能にすることができ、例えば、ユーザ定義のユニークな値がIDとして使用されることが可能であり、または既存のプロトコルにおいて定義されたいくつかのフィールドがOFSのIDとして使用されることが可能であり、例えば、OpenFlowプロトコルにおいて一般に使用されるdatapath IDがOFSのIDとして使用される。時々、各々の物理的なOFSについて、１つの物理的なOFSをいくつかの論理的なOFSに区分するために、いくつかの仮想化された操作が行われることが可能であり、この場合、OFSのIDはいくつかの論理的なOFSのIDと考えることが可能であり、各々のメッセージにおけるいくつかの論理的なOFSによる処理の手順は、単一の物理的なOFSの処理手順と首尾一貫したままであることに留意すべきである。
この実施例において、経路情報を示すために三つ組[datapath_id, input_no, output_no]が使用され、OFSによって受信されるOPFT_HELLOメッセージが既に上記の三つ組を有するならば、OFSは前の三つ組に基づいてこのノードの三つ組を追加して、三つ組のシーケンスを形成し、これは下記の形態で表現され得る。
<[datapath_id, input_no, output_no], [datapath_id, input_no, output_no]......>
ここで、
datapath_idはOFSを識別するために使用され、フィールドはOpenFlowプロトコルにおいて定義され、その下位48ビットはスイッチのMACアドレスであり、その上位16ビットは実装者によって定義され（例えば、OFSの仮想化を実現するとともに仮想ネットワークのIDが使用される）、
input_no：OFSの、パケットがそこに入るポートの番号、そして
output_no：OFSの、パケットがそこから転送されるポートの番号。
図１５を参照されたく、これはこの実施例における経路情報のOPFT_HELLOメッセージのbodyフィールドへの拡張の概要図である。図において、body_lengthフィールドより下の部分は経路情報であり、複数の組の経路情報があることが可能であり、各々の組の経路情報は３つの部分、datapath_id、input_no、およびoutput_noを含む。
３方向TCPハンドシェイクの交換が完了した後に、第１のOFSはOFPT_HELLOメッセージを生成し、TCP/IPパケットを構築し、パケットをブロードキャストする。
TCP/IPパケットのヘッダは下記のように設定される。
dst_mac：OFCのMACアドレス、
src_mac：第１のOFSのMACアドレス、
src_ip：第１のOFSのIPアドレス、
dst_ip：OFCのIPアドレス、
src_port：第１のOFSの、TCP接続を聴取するために使用されるポート番号、
dst_port：OFCの、TCP接続を聴取するために使用されるポート番号、
初期TTL値が設定され、そして、
パケット内のpayloadはOFPT_HELLOメッセージを搬送し、経路の三つ組<[dpid_OFS1, --, output_no_OFS1]>がOFPT_HELLOメッセージのbodyフィールドに追加され、ここでdpid_OFS1は経路IDを示し、「--」は、OFSポートの、そこにパケットが入るポートの番号が空であることを示し（OFSは初期OFSであるので、OFSは他のOFSからパケットを受信しない）、output_no_OFS1は、第１のOFS（OFS1）の、そこからパケットが転送されるポートの番号を示す。
第１のOFS（OFS1）によって送信されるOFPT_HELLOメッセージのパケットを受信した後に、第２のOFS（OFS3）は経路情報をOFPT_HELLOメッセージのbodyフィールドに追加する。この実施例において、各々のOFSがOFPT_HELLOメッセージのパケットを処理するとき、OFSは、実施例２および実施例３において言及したフロー・テーブルにおいてワイルドカード・マッチ照合を行う形態に基づいてパケットを転送することも可能であり、照合が成功したならば、OFSは合致したエントリ内の「命令」フィールド内の値に従って特定のポートからパケットを転送することが可能であり、照合が失敗したならば、OFSはパケットをブロードキャストするか、または前もって定義された複数のポートからパケットを転送することが可能である。それに対応して、そこからパケットが転送されるポートについて、ポートの情報を含む経路情報がOFPT_HELLOメッセージのbodyフィールドに追加される。具体的には、OFPT_HELLOメッセージのパケットを受信した後に、第２のOFSおよび他のOFSの各々は、下記の方法を使用することによってパケットを転送することが可能であり、これは、図１６を参照すると、以下を含む。
S91：パケットを解析してTTL、ポート番号、IPアドレス、およびMACアドレスのような情報を取得する。
S92：TTLが0より大きいかどうかを判定し、大きいならば、S93を行い、そうでないならば、パケットを廃棄する。
S93：フロー・テーブルにおいて正確な照合を行い、合致したエントリがあるならば、合致したエントリ内の「命令」フィールド内の値に従ってパケットを指定されたポートに送信し、合致したエントリがないならば、S94を行う。
上記のステップはハードウェアを使用することによって実現されて、処理速度を増加させることが可能であり、下記のステップはソフトウェアを使用することによって実現されて、柔軟性を改善することが可能である。
S94：宛先IPアドレスがそれ自身と関連付けされたOFCのIPアドレスであるかどうかを判定し、そうであるならば、S95を行い、そうでないならば、パケットを廃棄する。
S95：宛先ポート番号がそれ自身と関連付けされたOFCのポート番号であるかどうかを判定し、そうであるならば、S96を行い、そうでないならば、パケットを廃棄する。
S96：パケットがOFPTタイプのメッセージを搬送するかどうかを判定し、搬送するならば、S97を行い、そうでないならば、パケットを廃棄する。具体的には、判定することはパケット内のpayload内の情報を解析することによって行われ得る。
S97：メッセージのタイプがOFPTタイプのOFPT_HELLOメッセージであるかどうかを判定し、そうであるならば、S98を行い、そうでないならば、パケットを廃棄する。
S98：フロー・テーブルにおいてワイルドカード・マッチ照合を行い、合致したエントリがあるならば、S99を行い、そうでないならば、S910を行う。
S99：現在のOFSの経路情報をOFPT_HELLOメッセージのbodyに追加し、S911を行う。
S910：OFSの現在利用可能な出力ポートを獲得し、S912を行う。
一般に、全ての利用可能な出力ポートが選択されることが可能であり、続いて、これらのポートからブロードキャストが行われる。実際の応用において、ブロードキャストを行うためにいくつかのポートが獲得されることも可能であり（例えば、前もって指定されたいくつかのポートが獲得される）、全ての利用可能なポートを獲得する必要はない。
S911：合致したエントリ内の「命令」フィールド内の値に従ってOFPT_HELLOメッセージのパケットを転送し、手順は終了する。
S912：各々の利用可能な出力ポートに対応する現在のOFSの経路情報をOFPT_HELLOメッセージのbodyに追加し、例えば、別個にport11およびport22である２つの出力ポートがあると仮定し、datapath_idはdatapath_id1であり、input_noはinput_no1であると仮定し、そして、下記の情報がOFPT_HELLOメッセージのbodyフィールドに追加される。
[datapath_id1, input_no1, port11]、および[datapath_id,1 input_no1, port22]
S913が引き続き行われる。
S913：転送のためにステップS910から利用可能な出力ポートを獲得し、手順は終了する。
図１７および図１８を参照されたく、これらは各々のOFSへのOFPT_HELLOメッセージの伝送の概要図である。図において、HelloはOFPT_HELLOメッセージ（下記で略して「Helloメッセージ」と呼ばれる）を示し、Helloの後の括弧内の数字は、それに異なる経路情報が追加されたOFPT_HELLOメッセージを示す。OFPT_HELLOメッセージを伝送するプロセスのbodyフィールド内の経路情報における変化が図１７および図１８を使用することによって記載される。
図１７を参照されたく、OFS1はまずHelloメッセージをブロードキャストおよび送信し、Helloメッセージを受信した後に、OFS3およびOFS5は、フロー・テーブルにおいてワイルドカード・マッチ照合を行い、そして特定のポートを使用することによって（例えば、OFS3はポート32を使用する）Helloメッセージを転送し、この場合、各々のHelloメッセージのbodyフィールド内の情報は下記の通りである。
Hello (1): < [dpid_OFS1, --, 11] >
Hello (2): < [dpid_OFS1, --, 12] >
Hello (3): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 32]>
Hello (4): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 33]>
Hello (5): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 33], [dpid_OFS5, 51, 52]>
図１８を参照すると、OFS1はまずHelloメッセージをブロードキャストおよび送信し、OFS3は、フロー・テーブルにおいてワイルドカード・マッチ照合を行い、合致したエントリがないことを見出し、従って、また、ブロードキャストを行い、Helloメッセージを受信した後に、OFS5はフロー・テーブルにおいてワイルドカード・マッチ照合を行い、そして特定のポート（52）を使用することによってHelloメッセージを転送し、この場合、各々のHelloメッセージのbodyフィールド内の情報は下記の通りである。
Hello (1): < [dpid_OFS1, --, 11] >
Hello (2): < [dpid_OFS1, --, 12] >
Hello (3): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 32]>
Hello (4): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 33]>
Hello (5): < [dpid_OFS1, --, 11], [dpid_OFS3, 31, 33], [dpid_OFS5, 51, 52]>
OFCは、受信されたHello (5)メッセージ内で搬送される経路情報に従って、メッセージがOFS1のポート11からOFS3のポート31にまず送信され、そして、OFS3のポート32からOFS5のポート51に送信され、最終的に、OFS5のポート52からOFCに送信されることを知る。それに対応して、逆経路（OFCからOFS1への経路）が決定されることも可能である（例えば、OFS5のポート51からOFS3のポート32に送信されること）。
他の実施例において、OFPT_HELLOメッセージのbodyフィールドの拡張は上記の実施例に依存しないことが可能であり、例えば、「まず信頼できる接続を確立する」、「まず正確な照合を行い、そしてワイルドカード・マッチ照合を行う」、等の上記のステップは使用されないことが可能であるが、OFPT_HELLOメッセージのbodyフィールドが、拡張された後に経路情報を搬送するために使用されることに焦点が置かれているのみであることに留意すべきであり、詳細について、実施例１２における記載への参照が行われ得る。
上記の実施例に基づいて、この実施例は、OFCが経路情報を獲得した後にフロー・エントリ（フロー・エントリ）を配送するための方法を提供する。
フロー・エントリの機能は、OFSがブロードキャストを行う必要がないことを可能にすることであり、フロー・エントリを使用することによって正確な転送が実現されることが可能であり、例えば、現在、図１６における概要図において、フロー・エントリはOFS1、OFS3、およびOFS5に配送され、それによってOFS1からOFCへのメッセージが、ブロードキャスト（例えば、OFS1はOFS2にメッセージを送信し、OFS3はOFS2にメッセージを送信する）の必要がなく一方向の経路OFS1->OFS3->OFS5->OFC（またはメッセージは逆に伝送されることが可能である）を通してOFCに伝送されることが可能である。
経路情報を獲得した後に、OFCは各々のOFSによって要求されるフロー・エントリを定式化する。例えば、図１６においてOFS1はパケットをOFCに送信する必要があるという需要のために、OFS1内のフロー・エントリ内にいくつかの主な関連するフィールドがあり、例えば、宛先IP、宛先MAC、および宛先ポート（ソフトウェア・ポート）は、IP、MAC、およびOFCのポートであり、送信元IP、送信元MAC、および送信元ポート（ソフトウェア・ポート）は、IP、MAC、およびOFS1のポートであり、命令はポート（物理的なポート）番号11である。他のOFS内のフロー・エントリについて、それは類似であり、命令内の様々な宛先／送信元情報およびポート番号を対応して調整する必要があるのみである。
図１９を参照されたく、これはいくつかのOFSについてのフロー・エントリの概要図である。図１９において、OFCは経路情報OFS1->OFS3->OFS5->OFCを収集すると仮定し、そして、OFCはフロー・エントリを関連するOFSに送信することが可能であり、例えば、順方向フロー・エントリはOFS1、OFS3、およびOFS5に配送されることが可能であり、それによってパケットはOFS1からOFCに転送されることが可能であり、OFS3について、OFS5は逆方向フロー・エントリを配送し、それによってパケットはOFCからOFS1およびOFS3に転送されることが可能である。
図１９において、各々のOFSのMACアドレスは「MAC_OFS名」によって示され、例えば、MAC_OFS1はOFS1のMACアドレスを示す。OFS1のIPアドレスは192.169.1.5であると仮定し、OFS3のIPアドレスは192.168.1.12であると仮定し、OFS5のIPアドレスは192.168.1.9であると仮定し、OFCのIPアドレスは192.168.1.21であると仮定し、各々のOFSのTCPポート番号は6633であると仮定し、OFCのTCPポート番号は36653であると仮定する。フィールドは別個に、switch port（Switchの入力ポート）、宛先MAC、送信元MAC、送信元IP、宛先IP、送信元ポート、宛先ポート、および照合が成功したときに実行される命令であり、最も左のflow_entryはフロー・エントリを示す。
図１９において、flow_entry(51)からflow_entry(55)はOFS5に特有であり、ここでflow_entry(51)は特有であり、flow_entry(31)からflow_entry(33)はOFS3に特有であり、flow_entry(11)はOFS1に特有である。具体的には、例としてOFS3内のフロー・エントリを使用して、flow_entry(31)はOFCによって送信されるパケットをOFS3に転送するために使用され、flow_entry(32)はOFCによって送信されるパケットをOFS1に転送するために使用され、flow_entry(33)はOFS1によって送信されるパケットをOFCに転送するために使用される。
図１９における例はフロー・エントリ内のいくつかの関連するフィールドを列挙するのみであり、フロー・エントリ内の他のフィールドの値は、この技術分野の当業者によって実際の応用シナリオを参照してたいへん容易に取得されることが可能であり、詳細は再度ここに記載されないことに留意すべきである。
OFCがフロー・テーブルを配送するとき、OFCはOFSおよびOFCのホップ・カウントの昇順にフロー・エントリを各々のOFSに配送することが可能であり、このやり方において、フロー・エントリを受信した後に、最小のホップ・カウントを有する（最も近い）OFSはブロードキャストの必要がなく続くパケットにおいて正確な転送を行うことができる。もちろん、ブロードキャストのオーバーヘッドが考慮されないならば、フロー・エントリはブロードキャストを通して配送され得る。
図２０を参照すると、Helloメッセージを受信した後にOFCがフロー・エントリを配送する例が使用され、主な手順は以下を含む。
S111：ヘッダを解析する。
S112：パケット内の宛先IPアドレスがOFCのIPアドレスに等しいかどうかを判定し、等しいならば、S113を行い、そうでないならば、パケットを廃棄する。
S113：パケット内の宛先ポート番号が、OFCの、TCP接続を聴取するためのポート番号に等しいかどうかを判定し、等しいならば、S114を行い、そうでないならば、パケットを廃棄する。
S114：パケットがOFPTタイプのメッセージを搬送するかどうかを判定し、搬送するならば、S115を行い、そうでないならば、パケットを廃棄する。
S115：OFPTメッセージのタイプがOFPT_HELLOメッセージであるかどうかを判定し、そうであるならば、S116を行い、そうでないならば、パケットを廃棄する。
S116：送信元OFSとOFCの間の経路の情報を抽出し、続いてフロー・エントリを定式化するステップS117およびステップS119を行う（S117は順方向および逆方向の経路についてのフロー・エントリに特有であり、S119は逆方向の経路に特有である）。
S117：経路における関連するOFSについてOFCへのフロー・エントリを定式化し、S118を行う。
OFCへのフロー・エントリは第１のOFSおよび転送のための中間OFSについて定式化される。
S118：経路における関連するOFSにフロー・エントリを配送する。
OFCは経路におけるOFSおよびOFCのホップ・カウントの昇順にフロー・エントリを各々のOFSに配送またはブロードキャストすることが可能であり、手順は終了する。
OFCが経路情報内のdatapath_idを使用することによって対応するIPアドレスおよびMACアドレスを見出すことができないならば、OFCは配送されるフロー・エントリ内のMACアドレスを擬似MACアドレス（例えば、FF-FF-FF-FF-FF-FF）に設定し、それがIPv4アドレスであるならば、OFCはdatapath_idに対応するアドレスをIPv4マルチキャスト・アドレスまたはブロードキャスト・アドレスに設定し、それがIPv6アドレスであるならば、OFCはdatapath_idに対応するアドレスをIPv6マルチキャスト・アドレスに設定する。
S119：経路における中間OFSについて第１のOFSへのフロー・エントリを定式化し、S1110を行う。
中間OFSは、OFCによって送信されるパケットを第１のOFSに転送するように構成されたOFSを指す。
S1110：経路における中間OFSにフロー・エントリを配送し、S118と類似して、フロー・エントリはホップ・カウントに基づいて配送またはブロードキャストされることが可能であり、手順は終了する。
同様に、分岐を行うプロセスにおいて、OFCが経路情報内のdatapath_idを使用することによって対応するIPアドレスおよびMACアドレスを見出すことができないならば、OFCは配送されるフロー・エントリ内のMACアドレスを擬似MACアドレス（例えば、FF-FF-FF-FF-FF-FF）に設定し、それがIPv4アドレスであるならば、OFCはdatapath_idに対応するアドレスをIPv4マルチキャスト・アドレスまたはブロードキャスト・アドレスに設定し、それがIPv6アドレスであるならば、OFCはdatapath_idに対応するアドレスをIPv6マルチキャスト・アドレスに設定する。
フロー・エントリを構築および配送するための方法が下記で詳細に記載される。
方法１
既存のOpenFlowプロトコルに従い、フロー・エントリはOFPT_FLOW_MODメッセージを使用することによって搬送され、各々のOFPT_FLOW_MODメッセージは１つのみのflow_entryを含む。
例としてOpenFlow Spec 1.2仕様を使用すると、OFPF_FLOW_MODメッセージの構成は下記の通りである。
struct ofp_flow_mod {
struct ofp_header header;
uint64_t cookie;
uint64_t cookie_mask;
uint8_t table_id;
uint8_t command;
uint16_t idle_timeout;
uint16_t hard_timeout;
uint16_t priority;
uint32_t buffer_id;
uint32_t out_port;
uint32_t out_group;
uint16_t flags;
uint8_t pad[2];
struct ofp_match match;//「照合フィールド」内の構造体変数を定義する。
struct ofp_instruction instructions[0];//「命令」内の構造体変数を定義する。
};
struct ofp_header {
uint8_t version;
uint8_t type;
uint16_t length;
uint32_t xid;
}
OFCはOFPT_FLOW_MODメッセージを搬送するために使用されるTCP/IPパケットを構築し、パケット・ヘッダは下記のように設定される。
dst_mac：OFSのMACアドレス、
src_mac：OFCのMACアドレス、
src_ip：OFCのIPアドレス、
dst_ip：OFSのIPアドレス、
src_port：OFCの、聴取するために使用されるポート、
dst_port：OFSの、TCP接続を聴取するために使用されるポート番号、そして、
初期TTL値が設定される。
OFSは、経路においてフロー・エントリを獲得する必要があるOFSを指し、例えば、第１のOFSまたは転送のための中間OFSであり得る。
パケットを完全に構築した後に、OFCはパケットを各々のOFSに送信し、図２１を参照すると、パケットを受信した後に、各々のOFSは下記の処理を行う。
S131：ヘッダを解析する。
S132：TTLが0より大きいかどうかを判定し、大きいならば、S133を行い、そうでないならば、パケットを廃棄する。
S133：フロー・テーブルにおいて正確な照合を行い、合致したエントリがあるならば、合致したエントリ内の「命令」フィールド内の値に従って転送を行い、合致したエントリがないならば、S134を行う。
上記のステップはハードウェアを使用することによって実現されることが可能であり、下記のステップはソフトウェアを使用することによって実現されることが可能である。
S134：宛先MACアドレスがOFSのMACアドレスまたは擬似MACアドレス（例えば、全てF）であるかどうかを判定し、そうであるならば、S135を行い、そうでないならば、S1310を行う。
S135：送信元IPがそれ自身と関連付けされたOFCのIPアドレス（またはマルチキャスト・アドレスまたはブロードキャスト・アドレス）であるかどうかを判定し、そうであるならば、S136を行い、そうでないならば、パケットを廃棄する。
S136：送信元ポート番号がそれ自身と関連付けされたOFCのポート番号であるかどうかを判定し、そうであるならば、S137を行い、そうでないならば、パケットを廃棄する。
S137：それがOFPTタイプのメッセージであるかどうかを判定し、そうであるならば、S138を行い、そうでないならば、パケットを廃棄する。
S138：OFPTメッセージのタイプがOFPT_FLOW_MODであるかどうかを判定し、そうであるならば、S139を行い、そうでないならば、パケットを廃棄する。
S139：OFPT_FLOW_MODメッセージ内のフロー・エントリを抽出し、フロー・エントリをフロー・テーブルに挿入する。具体的には、OFSはOFPT_FLOW_MODがOFSのdatapath_idを含むかどうかを判定し、含むならば、OFSは、datapathと関連付けされ、正確に合致する１つまたはより多くのフロー・エントリをフロー・テーブルに追加し、OFPT_FLOW_MOD内に含まれるMACフィールドの値がFF-FF-FF-FF-FF-FFに等しく、MACアドレスに対応するIPアドレスがマルチキャスト・アドレスまたはブロードキャスト・アドレスであるならば、OFSはスイッチのMACアドレスおよびIPアドレスをフロー・エントリに対して更新し、手順は終了する。
S1310：送信元IPがそれ自身と関連付けされたOFCのIPアドレスであるかどうかを判定し、そうであるならば、S1311を行い、そうでないならば、パケットを廃棄する。
S1311：送信元ポート番号がそれ自身と関連付けされたOFCのポート番号であるかどうかを判定し、そうであるならば、S1312を行い、そうでないならば、パケットを廃棄する。
S1312：それがOFPTタイプのメッセージであるかどうかを判定し、そうであるならば、S1313を行い、そうでないならば、パケットを廃棄する。
S1313：OFPTメッセージのタイプがOFPT_FLOW_MODであるかどうかを判定し、そうであるならば、S1314を行い、そうでないならば、パケットを廃棄する。
S1314：パケットをブロードキャストし、手順は終了する。
方法２
他の構築方法はOpenFlowプロトコルにおけるOFPT_FLOW_MODメッセージを拡張することであり、それによって１つのOFPT_FLOW_MODメッセージはOFSに関連する複数のflow_entryを含むことが可能である。下記の構造体を参照すると、構造体ofp_multi_flow_mod_listはOFPT_FLOW_MODメッセージ内の拡張された部分である。
struct ofp_multi_flow_mod_list {
ofp_multi_flow_mod head;
ofp_multi_flow_mod tail;
uint8_t flow_entry_number;
}; //拡張された構造体
struct ofp_multi_flow_mod {
struct ofp_flow_mod;
struct ofp_multi_flow_mod *prior, *next;
}; //拡張された構造体
struct ofp_header {
uint8_t version;
uint8_t type;
uint16_t length;
uint32_t xid;
};
struct ofp_flow_mod_body {
uint64_t cookie;
uint64_t cookie_mask;
uint8_t table_id;
uint8_t command;
uint16_t idle_timeout;
uint16_t hard_timeout;
uint16_t priority;
uint32_t buffer_id;
uint32_t out_port;
uint32_t out_group;
uint16_t flags;
uint8_t pad[2];
struct ofp_match match;
struct ofp_instruction instructions[0];
};
転送手順は方法１における転送手順に類似するが、ステップS139において、複数のフロー・エントリが一度に抽出され得る。
方法３
OpenFlowプロトコルにおけるOFPT_FLOW_MODメッセージが拡張され、それによって１つのOFPT_FLOW_MODメッセージは、経路における（例としてOFS1、OFS3、OFS5、およびOFCによって形成される経路を使用して）全ての関連するOFS（例えば、OFS1、OFS3、およびOFS5）の複数のflow entries（例えば、図３０において列挙された全てのflow_entry）を含むことが可能である。経路における全てのデバイスに送信することが行われるので、この実施例においてdatapath_id識別子が構造体ofp_flow_mod_bodyに追加され、それによって経路におけるデバイスを識別し、それによって経路における情報が続いて転送されることが可能である。
struct ofp_multi_flow_mod_list {
ofp_multi_flow_mod head;
ofp_multi_flow_mod tail;
uint8_t flow_entry_number;
}; //拡張された構造体
struct ofp_multi_flow_mod {
struct ofp_flow_mod;
struct ofp_multi_flow_mod *prior, *next;
}; //拡張された構造体
struct ofp_header {
uint8_t version;
uint8_t type;
uint16_t length;
uint32_t xid;
};
struct ofp_flow_mod_body{
uint64_t datapath_id; //拡張された項目
uint64_t cookie;
uint64_t cookie_mask;
uint8_t table_id;
uint8_t command;
uint16_t idle_timeout;
uint16_t hard_timeout;
uint16_t priority;
uint32_t buffer_id;
uint32_t out_port;
uint32_t out_group;
uint16_t flags;
uint8_t pad[2];
struct ofp_match match;
struct ofp_instruction instructions[0];
};
パケット内のペイロードは、拡張されたOFPT_FLOW_MODを搬送し、経路における（例としてOFS1、OFS3、OFS5、およびOFCによって形成される経路を使用して）各々のスイッチ（OFS1、OFS3、およびOFS5）に関連するフロー・エントリを含む。
TCP/IPパケットを受信した後に、OFSが、メッセージのタイプがOFPT_FLOW_MODであると判定したならば、OFSは、TCP/IPパケットからOFSに関連するいくつかのflow_entriesを抽出し（すなわち、ofp_flow_mod_body。datapath_idはOFSのdatapath_idに等しい）、いくつかのflow_entriesをtable_idによって示される正確なテーブルに挿入し、そして、OFPT_FLOW_MOD内の関与するOFSの全てがメッセージを受信するまで、パケットをブロードキャストし続ける。
上記の実施例に基づいて、この実施例はSDNスイッチのハードウェア構成を提供し、これは、図２２を参照すると、例としてOFSのハードウェア構成を使用して、
トランシーバ、ハードウェア・デバイス、およびソフトウェア・デバイス
を含み得る。
トランシーバは、パケットを送信および受信するように構成されたハードウェア回路であり、またはハードウェア・デバイスとともに物理的なチップ内に製造され得る。
ハードウェア・デバイスは「ハードウェア処理モジュール」と呼ばれることも可能であり、またはより簡単に、略して「ハードウェア」と呼ばれることも可能であり、受信されたパケットを処理するように構成される。ハードウェア・デバイスは、いくつかの特定の機能を有するハードウェア回路を実現するために、FPGA、ASIC、等に基づく専用のハードウェア回路（これはメモリのような他の付属デバイスと組み合わせて使用されることも可能である）を主に含み、それらの処理速度は、一般に、一般的なCPUのそれよりずっと高いが、機能はカスタマイズされた後に変更することが大変難しく、従って、実現は柔軟でなく、一般に、いくつかの固定された機能を処理するように構成される。実際の応用において、ハードウェア・デバイスは、MCU（シングル・チップ・マイクロコンピュータのようなマイクロプロセッサ）、またはCPUのようなプロセッサを含むことも可能であるが、これらのプロセッサの主な機能はビッグ・データにおける処理を完了しないが、いくつかの制御を行うために主に使用されることに留意すべきである。この応用シナリオにおいて、これらのデバイスによって組み合わされたシステムはハードウェア・デバイスである。
ソフトウェア・デバイス（または、略して「ソフトウェア」とも呼ばれる）は、一般的なCPUおよびいくつかの付属デバイス（メモリまたはハードディスクのような記憶デバイス）を主に含み、CPUはソフトウェア・プログラミングを通して対応する処理機能を有することが可能であり、ソフトウェア・デバイスがソフトウェアを使用することによって実現されるとき、ソフトウェア・デバイスはサービスの需要に従って柔軟に構成されることが可能であるが、速度は一般にハードウェア・デバイスのそれよりずっと低い。ソフトウェアが処理を完了した後に、完全に処理されたデータはトランシーバを使用することによってハードウェア・デバイスにより送信されることが可能であり、または完全に処理されたデータはトランシーバに接続されたインタフェースを使用することによってトランシーバに送信されることが可能である。
この実施例において、ハードウェア・デバイスは上記の実施例において言及された正確な照合を行うように構成されることが可能であり、ソフトウェア・デバイスは上記の実施例において言及されたワイルドカード・マッチ照合を行うように構成される。すなわち、送信および受信回路を通してパケットを受信した後に、OFSは、また、処理のためにパケットをハードウェア・デバイスに送信し、照合が成功したならば、OFSはパケットを転送し、照合が失敗したならば、OFSは処理のためにパケットをソフトウェア・デバイスに送信する（例えば、OpenFlowプロトコルにおいて定義されたpacket_inメッセージが生成されることが可能であり、パケットはソフトウェア・デバイスに送信される）。
ハードウェアおよびソフトウェアの両方は正確なフロー・テーブルを記憶し、２つはマッピング関係を保持することが可能であり、これは実施例２において詳細に記載され、ここに再度詳細に記載されない。
この実施例においてソフトウェアとハードウェアを組み合わせる方法を使用することによって、処理速度は保証され、柔軟性は維持される。
もちろん、この実施例はソフトウェア・デバイスを使用することによって実現されることに限定されず、例えば、図２３を参照されたく、これはハードウェアを使用することによって実現される解決策であり、すなわち、プロセッサは（ハードディスクまたはメモリのような）メモリ内に記憶されたコードを走らせて対応する操作を行う。
上記の実施例に基づいて、図２４を参照すると、この実施例はSDNスイッチを提供し、ここでSDNスイッチは第２のSDNスイッチであり、第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、第２のSDNスイッチは、
第１のSDNスイッチとSDNコントローラの間で信頼できる接続が確立されるように、第１のSDNスイッチとSDNコントローラの間でメッセージ交換を行うように構成された接続確立ユニット71と、
第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信するように構成された第１の受信ユニット72であって、第１の制御メッセージは第１のSDNスイッチの経路情報を搬送し、第１の制御情報は、信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、第１の受信ユニット72と、
第２のSDNスイッチの経路情報を第１の受信ユニットによって受信された第１の制御メッセージに追加して、更新された第１の制御メッセージを取得するように構成された経路追加ユニット73と、
更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信した後に、SDNコントローラが、各々のSDNスイッチによって最終的に更新された第１の制御メッセージに追加された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するように、経路追加ユニットが第２のSDNスイッチの経路情報を追加した更新された第１の制御メッセージをSDNコントローラに転送するように構成された転送ユニット74と、を含む。
この実施例において、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続はTCP接続を含み、信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、
接続確立ユニットは、具体的には、TCP接続が第１のSDNスイッチとSDNコントローラの間で確立されるように、第１のSDNスイッチとSDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送するように構成される。
この実施例において、第２のSDNスイッチは正確なフロー・テーブルを含み、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、
図２５を参照すると、接続確立ユニット71は、具体的には、
第１のSDNスイッチから送信された第１のTCP/IPパケットを受信するように構成された受信サブユニット711と、
受信サブユニットによって受信された第１のTCP/IPパケット内の複数の特徴情報を獲得するように構成された特徴情報獲得サブユニットであって、特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、特徴情報獲得サブユニットと、
特徴情報獲得サブユニットによって獲得された第１のTCP/IPパケット内の複数の特徴情報と、第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、正確な照合が失敗し、かつ受信された第１のTCP/IPパケットが第１のタイプのTCPハンドシェイク・メッセージを搬送すると判定されたならば、複数の特徴情報における１つまたはより多くの特徴情報と正確なフロー・テーブルの間でワイルドカード・マッチ照合を行うように構成された第１の照合サブユニット712であって、ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートであり、第１の照合サブユニット712は、ワイルドカード・マッチ照合が成功したならば、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、第１のタイプのTCPハンドシェイク・メッセージを搬送する受信された第１のTCP/IPパケットを処理し、それによって第１のTCP/IPパケットをSDNコントローラに転送するように構成され、第１のタイプのTCPハンドシェイク・メッセージは第１のTCPハンドシェイクのメッセージまたは第３のTCPハンドシェイクのメッセージである、第１の照合サブユニット712と、を含む。
この実施例において、受信サブユニットは、SDNコントローラから送信された第３のTCP/IPパケットを受信するようにさらに構成され、ここで第３のTCP/IPパケットは第２のハンドシェイクのメッセージを搬送し、
特徴情報獲得サブユニットは、受信サブユニットによって受信された第３のTCP/IPパケット内の複数の特徴情報を獲得するようにさらに構成され、ここで特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、
第１の照合サブユニットは、特徴情報獲得サブユニットによって獲得された第３のTCP/IPパケット内の複数の特徴情報と、第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、正確な照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従って転送を行い、照合が失敗し、かつ第３のTCP/IPパケットが第２のTCPハンドシェイクのメッセージを搬送すると判定されたならば、第３のTCP/IPパケットをブロードキャストするようにさらに構成される。
この実施例において、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、
第１の受信ユニットは、具体的には、
第１のSDNスイッチから送信され、第１の制御メッセージを搬送する第２のTCP/IPパケットを受信するように構成され、ここで第２のTCP/IPパケットは複数の特徴情報を含み、ここで特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、
図２６を参照すると、経路追加ユニットは、
第２の受信サブユニットによって受信された第２のTCP/IPパケット内の特徴情報および正確なフロー・テーブルに従って正確な照合を行い、正確な照合が失敗し、かつ受信された第２のTCP/IPパケットが第１の制御メッセージを搬送すると判定された後に、TCP/IPパケット内の１つまたはより多くの特徴情報および正確なフロー・テーブルに従ってワイルドカード・マッチ照合を行うように構成された第２の照合サブユニット731であって、ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートである、第２の照合サブユニット731と、
第２の照合サブユニットのワイルドカード・マッチ照合が成功したとき、第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージを取得するように構成された追加サブユニット732と、を含む。
図２７を参照すると、転送ユニット74は、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、追加サブユニットの処理の後に取得された更新された第１の制御メッセージをSDNコントローラに転送するように構成された第１の転送サブユニット741を含む。
この実施例において、追加サブユニット732は、第２の照合サブユニット731のワイルドカード・マッチ照合が失敗したならば、第２のSDNスイッチの利用可能な出力ポートを獲得し、第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報を第１の制御メッセージに追加するようにさらに構成され、
図２７を参照すると、転送ユニット74は、追加サブユニットが、第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報を追加した更新された第１の制御メッセージを、利用可能な出力ポートからSDNコントローラに転送するように構成された第２の転送サブユニット742をさらに含む。
上記で言及した実施例と類似して、この実施例において、SDNネットワークはOpenFlowプロトコルに基づいて実現されることが可能であり、このシナリオにおいて、第１の制御メッセージはOpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを含み、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用され、
第１の受信ユニットは、具体的には、接続確立ユニットによって確立された信頼できる接続を使用することによって、第１のSDNスイッチによって送信され、経路情報を収集するために使用されるOFPT_HELLOメッセージを受信するように構成され、ここでOFPT_HELLOメッセージ内の、経路情報を搬送するために使用される拡張されたbodyフィールドは、第１のSDNスイッチの経路情報を搬送し、
経路追加ユニットは、具体的には、第１の受信ユニットによって受信されたOFPT_HELLOメッセージ内の、経路情報を搬送するために使用される拡張されたbodyフィールドに、第２のSDNスイッチの経路情報を追加して、更新されたOFPT_HELLOメッセージを取得するように構成され、
転送ユニットは、具体的には、更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、SDNコントローラが、各々のSDNスイッチによって最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチに配送するように、経路追加ユニットが第２のSDNスイッチの経路情報を追加した更新されたOFPT_HELLOメッセージをSDNコントローラに転送するように構成される。
この実施例において、転送ユニットは、具体的には、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNコントローラに直接的に転送するように構成され、ここで最終的に更新された第１の制御メッセージは更新された第１の制御メッセージであり、または、
１つまたはより多くの他のSDNスイッチを使用することによって、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージをSDNに間接的に転送するように構成され、ここで最終的に更新された第１の制御メッセージは、他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、他のSDNスイッチの各々の経路情報を第１の制御メッセージに追加した後に、他のSDNスイッチの各々によってSDNコントローラに最終的に送信された第１の制御メッセージである。
この実施例において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、SDNスイッチは、
SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するように構成された第２の受信ユニットであって、OFPT_FLOW_MODメッセージは宛先SDNスイッチによって要求される複数の正確なフロー・エントリを搬送する、第２の受信ユニットと、
第２の受信ユニットによって受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、OFPT_FLOW_MODメッセージ内で搬送された複数の正確なフロー・エントリを抽出し、そして複数の正確なフロー・エントリをローカルな正確なフロー・テーブルに追加するように構成された第１のフロー・エントリ処理ユニットと、をさらに含む。
その代わりに、SDNネットワークがOpenFlowプロトコルに基づいて実現されるとき、この実施例は、
SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するように構成された第３の受信ユニットであって、OFPT_FLOW_MODメッセージは、ルーティング経路上に位置する複数のSDNスイッチによって要求される複数の正確なフロー・エントリおよびルーティング経路上の各々のSDNスイッチに対応する経路情報を搬送し、ルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを使用する、第３の受信ユニットと、
第３の受信ユニットによって受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、第２のSDNスイッチに対応する経路情報に従って、第２のSDNスイッチによって使用される必要がある１つまたはより多くの正確なフロー・エントリを抽出し、抽出が完了した後にOFPT_FLOW_MODメッセージをルーティング経路上の次のノードに転送するように構成された第２のフロー・エントリ処理ユニットと、をさらに含み得る。
この実施例において、経路情報は、第１の制御メッセージを送信または受信するSDNスイッチのID、第１の制御メッセージを受信するために使用されるポート番号、および第１の制御メッセージを送信するために使用されるポート番号を含む。
この実施例を使用することによって、コストは減少されることが可能であり、SDNスイッチの転送効率は改善されることが可能であり、ブロードキャスト・ストームは減少されることが可能であり、具体的な理由について、上記の実施例における分析を参照されたく、詳細は再度ここに記載されない。
上記の実施例に基づいて、この実施例はSDNコントローラを開示し、ここでSDNコントローラは第２のSDNスイッチに接続され、第２のSDNスイッチは第１のSDNスイッチに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、図２８を参照すると、SDNコントローラは、
第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを受信するように構成された第１の受信ユニット81であって、最終的に更新された第１の制御メッセージは更新された第１の制御メッセージを含み、第２のSDNスイッチが、第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信した後に、第２のSDNスイッチにより、第２のSDNスイッチの経路情報を第１の制御メッセージに追加することによって、更新された第１の制御メッセージが取得され、第１の制御メッセージは第１のSDNスイッチの経路情報を搬送し、第１の制御情報は第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、第１の受信ユニット81と、
各々のSDNスイッチによって追加され、第１の受信ユニットによって受信された最終的に更新された第１の制御メッセージ内で搬送された経路情報に従って、SDNコントローラと第１のSDNスイッチの間のルーティング経路を獲得するように構成された経路獲得ユニット82と、
経路獲得ユニットによって獲得されたルーティング経路を通して、正確なフロー・エントリを第１のSDNスイッチに配送するように構成されたフロー・テーブル配送ユニット83と、を含む。
この実施例において、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続はTCP接続を含み、信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、TCP接続は、第２のSDNスイッチにより、第１のSDNスイッチとSDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することによって確立される。
この実施例において、SDNネットワークはOpenFlowプロトコルに基づいて実現されることが可能であり、このシナリオにおいて、第１の制御メッセージはOFPT_HELLOメッセージを含み、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用される。
この実施例において、第１の受信ユニットは、具体的には、
第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを直接的に受信するように構成され、ここで最終的に更新された第１の制御メッセージは更新された第１の制御メッセージであり、または、
１つまたはより多くの他のSDNスイッチを使用することによって、第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを間接的に受信するように構成され、ここで最終的に更新された第１の制御メッセージは、他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、他のSDNスイッチの各々の経路情報を第１の制御メッセージに追加した後に、他のSDNスイッチの各々によってSDNコントローラに最終的に送信された第１の制御メッセージである。
この実施例において、SDNネットワークはOpenFlowプロトコルに基づいて実現されることが可能であり、これに対応して、フロー・テーブル配送ユニットは、具体的には、
第１のSDNスイッチによって要求される正確なフロー・エントリを、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージに追加し、
第１のSDNスイッチがOFPT_FLOW_MODメッセージに従って正確なフロー・エントリを獲得するように、ルーティング経路を通してOFPT_FLOW_MODメッセージを第１のSDNスイッチに送信するように構成される。
その代わりに、
フロー・テーブル配送ユニットは、具体的には、
ルーティング経路上に位置する複数のOFSによって要求される複数の正確なフロー・エントリおよびルーティング経路上の各々のSDNスイッチに対応する経路情報を、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージに追加するように構成され、ここでルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを必要とし、
OFPT_FLOW_MODメッセージを受信した後に、他のSDNスイッチが経路情報およびOFPT_FLOW_MODメッセージ内の経路情報に従って他のSDNスイッチによって要求される正確なフロー・エントリを抽出し、残りの正確なフロー・エントリを転送し、第１のSDNスイッチによって要求される正確なフロー・エントリを第１のSDNスイッチに最終的に転送するように、ルーティング経路を通してOFPT_FLOW_MODメッセージを他のSDNスイッチに配送するように構成される。
図２９を参照すると、この実施例は、第１のSDNスイッチ91、第２のSDNスイッチ92、およびSDNコントローラ94（１つまたはより多くの他の中間SDNスイッチ93があり得る）を含むソフトウェア定義ネットワークSDNシステムを開示し、ここで、第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、
第１のSDNスイッチ9191は、経路情報を収集するために使用される第１の制御メッセージを第２のSDNスイッチ92に送信するように構成され、ここで第１の制御メッセージは第１のSDNスイッチ91の経路情報を搬送し、第１の制御情報は第１のSDNスイッチ91とSDNコントローラ94の間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送され、
第２のSDNスイッチ92は、第１の制御メッセージを受信し、第２のSDNスイッチ92の経路情報を第１の制御メッセージに追加して、更新された第１の制御メッセージを取得し、第２のSDNスイッチ92の経路情報が追加された更新された第１の制御メッセージをSDNコントローラ94に転送するように構成され、
SDNコントローラ94は、第２のSDNスイッチ92によって送信され、更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信し、各々のSDNスイッチによって最終的に更新された第１の制御メッセージに追加された経路情報に従ってSDNコントローラ94と第１のSDNスイッチ91の間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のSDNスイッチ91に配送するように構成される。
この実施例において、第１のSDNスイッチ91とSDNコントローラ94の間で確立される信頼できる接続はTCP接続を含み、信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、TCP接続は、第２のSDNスイッチ92により、第１のSDNスイッチ91とSDNコントローラ94の間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することによって確立される。
この実施例において、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、
第２のSDNスイッチは、具体的には、第１のSDNスイッチから送信された第１のTCP/IPパケットを受信し、受信された第１のTCP/IPパケット内の複数の特徴情報を取得し、ここで特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、複数の特徴情報と第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、正確な照合が失敗し、かつ受信された第１のTCP/IPパケットが第１のタイプのTCPハンドシェイク・メッセージを搬送すると判定されたならば、複数の特徴情報における１つまたはより多くの特徴情報と正確なフロー・テーブルの間でワイルドカード・マッチ照合を行い、ここでワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートであり、ワイルドカード・マッチ照合が成功したならば、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、第１のタイプのTCPハンドシェイク・メッセージを搬送する受信された第１のTCP/IPパケットを処理し、それによって第１のTCP/IPパケットをSDNコントローラに転送し、ここで第１のタイプのTCPハンドシェイク・メッセージは第１のTCPハンドシェイクのメッセージまたは第３のTCPハンドシェイクのメッセージであり、それによって第１のSDNスイッチ、他のOFS、およびSDNコントローラの間で、信頼できる接続を確立するために使用されるメッセージの交換を実現して、信頼できる接続を確立するように構成される。
第２のSDNスイッチは、具体的には、第１のSDNスイッチから送信され、第１の制御メッセージを搬送する第２のTCP/IPパケットを受信し、ここで第２のTCP/IPパケットは複数の特徴情報を含み、ここで特徴情報は第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、第２のTCP/IPパケット内の特徴情報および正確なフロー・テーブルに従って正確な照合を行い、正確な照合が失敗し、かつ受信された第２のTCP/IPパケットが第１の制御メッセージを搬送すると判定された後に、TCP/IPパケット内の１つまたはより多くの特徴情報および正確なフロー・テーブルに従ってワイルドカード・マッチ照合を行い、ここでワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートであり、ワイルドカード・マッチ照合が成功したならば、第２のSDNスイッチの経路情報を第１の制御メッセージに追加して、第２のSDNスイッチの経路情報が追加された更新された第１の制御メッセージを取得し、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、更新された第１の制御メッセージをSDNコントローラに転送するようにさらに構成される。
この実施例において、SDNネットワークはOpenFlowプロトコルに基づいて実現され、この場合、第１の制御メッセージはOpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを含み、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用される。
この実施例において、第２のSDNスイッチは、直接的または間接的な形態で第１の制御メッセージをSDNコントローラに転送することが可能であり、直接的な転送の間に、最終的に更新された第１の制御メッセージは更新された第１の制御メッセージであり、間接的な転送の間に、最終的に更新された第１の制御メッセージは、他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、他のSDNスイッチの各々の経路情報を第１の制御メッセージに追加した後に、他のSDNスイッチの各々によってSDNコントローラに最終的に送信された第１の制御メッセージである。
この実施例において、SDNネットワークがOpenFlowプロトコルに基づいて実現されるとき、正確なフロー・エントリは、いくつかの方法を使用することによってOpenFlowプロトコルにおけるメッセージに基づいて搬送され得る。
第１の方法に対応する実施例において、第２のSDNスイッチは、SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信し、ここでOFPT_FLOW_MODメッセージは宛先SDNスイッチによって要求される複数の正確なフロー・エントリを搬送し、
受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、第２のSDNスイッチは、OFPT_FLOW_MODメッセージ内で搬送された複数の正確なフロー・エントリを抽出し、そして複数の正確なフロー・エントリをローカルな正確なフロー・テーブルに追加する。
第２の方法に対応する実施例において、第２のSDNスイッチは、SDNコントローラから送信され、OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信し、ここでOFPT_FLOW_MODメッセージは、ルーティング経路上に位置する複数のSDNスイッチによって要求される複数の正確なフロー・エントリおよびルーティング経路上の各々のSDNスイッチに対応する経路情報を搬送し、ここでルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを使用し、
受信されたメッセージが第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、第２のSDNスイッチは、第２のSDNスイッチに対応する経路情報に従って、第２のSDNスイッチによって使用される必要がある１つまたはより多くの正確なフロー・エントリを抽出し、抽出が完了した後にOFPT_FLOW_MODメッセージをルーティング経路上の次のノードに転送する。
この実施例において、経路情報は、第１の制御メッセージを送信または受信するSDNスイッチのID、第１の制御メッセージを受信するために使用されるポート番号、および第１の制御メッセージを送信するために使用されるポート番号を含む。
上記の実施例に基づいて、この実施例はSDNスイッチによりパケットを転送するための方法を開示し、ここでSDNスイッチは第２のSDNスイッチであり、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは少なくとも１つの正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、図３０を参照すると、この方法は、以下を含む。
S301：第１のSDNスイッチから送信されたパケットを受信し、ここでパケットは複数の特徴情報を含み、ここで特徴情報は正確なフロー・エントリ内の照合フィールドに対応する。
S302：パケット内の特徴情報を獲得する。
S303：特徴情報と正確なフロー・テーブル内の正確なフロー・エントリの間で正確な照合を行い、正確な照合が失敗したならば、複数の特徴情報における１つまたはより多くの特徴と正確なフロー・テーブル内の正確なフロー・エントリの間でワイルドカード・マッチ照合を行い、ここでワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートであり、ワイルドカード・マッチ照合が成功したならば、ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従ってパケットを転送する。
この実施例において、正確な照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従って転送が行われ、ワイルドカード・マッチ照合が失敗したならば、受信されたパケットはブロードキャストを通して転送される。
この実施例において、第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信する。
この実施例において、パケットは、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケットであり、パケットは、第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを搬送するために使用される。
この実施例を使用することによって、SDNスイッチの転送効率は改善されることが可能であり、加えて、この実施例における解決策に基づいて転送されるパケットのタイプはこの実施例において限定されない。
上記の実施例に基づいて、この実施例は実施例１０における方法に対応するSDNスイッチを提供し、ここでSDNスイッチは第２のSDNスイッチであり、第２のSDNスイッチは正確なフロー・テーブルを記憶し、ここで正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび複数の照合フィールドに対応する命令を含み、図３１を参照すると、第２のSDNスイッチは、
第１のSDNスイッチから送信されたパケットを受信するように構成された受信ユニット101であって、パケットは１つまたはより多くの特徴情報を含む、受信ユニット101と、
受信ユニットによって受信されたパケット内の特徴情報を獲得するように構成された獲得ユニット102と、
獲得ユニットによって獲得された１つまたはより多くの特徴情報と正確なフロー・テーブル内の正確なフロー・エントリの間で正確な照合を行うように構成された正確な照合ユニット103であって、１つまたはより多くの特徴情報は正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、正確な照合ユニット103と、
正確な照合ユニットによって行われる正確な照合が失敗したならば、複数の特徴情報における１つまたはより多くの特徴と正確なフロー・テーブル内の正確なフロー・エントリの間でワイルドカード・マッチ照合を行うように構成されたワイルドカード・マッチ照合ユニット104であって、ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的にSDNコントローラに到達することができるルートである、ワイルドカード・マッチ照合ユニット104と、
ワイルドカード・マッチ照合ユニットによって行われるワイルドカード・マッチ照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従ってパケットを転送するように構成された転送ユニット105と、を含む。
この実施例において、照合および転送ユニットは、
正確な照合が成功したならば、照合において成功した正確なフロー・エントリ内の命令に従って転送を行い、
ワイルドカード・マッチ照合が失敗したならば、ブロードキャストを通して転送を行うようにさらに構成される。
第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて（直接的または間接的に接続されることが可能であり）、SDNネットワークを形成し、SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信する。
パケットは、第１のSDNスイッチとSDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケットであり、パケットは、第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを搬送するために使用される。
上記の実施例に基づいて、この実施例は、第２のOFSに適用される、オープンフロー・スイッチOpenFlow Switch OFSにより経路情報を収集するための方法を提供し、ここで第２のOFSは第１のOFSおよびオープンフロー・コントローラOpenFlow Controller OFCに接続されて、OpenFlowネットワークを形成し、OFCは帯域内通信の形態で各々のOFSと通信し、図３２を参照すると、この方法は、以下を含む。
S321：第１のOFSによって送信され、経路情報を収集するために使用され、OpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを受信し、ここでOFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用され、OFPT_HELLOメッセージは第１のOFSの経路情報を搬送し、OFPT_HELLOメッセージは第１のOFSとOFCの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される。
S322：第２のOFSの経路情報をOFPT_HELLOメッセージに追加して、更新されたOFPT_HELLOメッセージを取得する。
S323：更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、OFCが、各々のOFSによって最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、OFCと第１のOFSの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のOFSに配送するように、更新されたOFPT_HELLOメッセージをOFCに転送する。
経路情報は、OFPT_HELLOメッセージを送信または受信するOFSのID、OFPT_HELLOメッセージを受信するために使用されるポート番号、およびOFPT_HELLOメッセージを送信するために使用されるポート番号を含む。
この実施例において、更新されたOFPT_HELLOメッセージをOFCに転送することは、
更新されたOFPT_HELLOメッセージをOFCに直接的に転送することであって、最終的に更新されたOFPT_HELLOメッセージは更新されたOFPT_HELLOメッセージである、前記直接的に転送すること、または、
１つまたはより多くの他のOFSを使用することによって、更新されたOFPT_HELLOメッセージをOFCに間接的に転送することであって、他のOFSは経路情報を受信された更新されたOFPT_HELLOメッセージに追加して、最終的に更新されたOFPT_HELLOメッセージを取得する、前記間接的に転送すること、を含む。
この実施例を使用することによって、経路情報は、既存のOpenFlowプロトコルにおけるメッセージに基づいて搬送されることが可能であり、プロトコルは変更される必要がなく、これは開発コストを節約する。
上記の実施例に基づいて、この実施例は、実施例１２における方法に対応するOFSを開示し、ここでOFSは第２のOFSであり、第２のOFSは、第１のOFS、オープンフロー・コントローラOpenFlow Controller OFC、および少なくとも１つの他のOFSに接続されて、OpenFlowネットワークを形成し、OFCは帯域内通信の形態で各々のOFSと通信し、図３３を参照すると、第２のOFSは、
第１のOFSによって送信され、経路情報を収集するために使用され、OpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを受信するように構成された受信ユニット131であって、OFPT_HELLOメッセージのbodyフィールドは拡張された後に経路情報を搬送するために使用され、OFPT_HELLOメッセージは第１のOFSの経路情報を搬送し、OFPT_HELLOメッセージは第１のOFSとOFCの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、受信ユニット131と、
第２のOFSの経路情報を、受信ユニットによって受信されたOFPT_HELLOメッセージに追加して、更新されたOFPT_HELLOメッセージを取得するように構成された経路情報追加ユニット132と、
更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、OFCが、各々のOFSによって最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、OFCと第１のOFSの間のルーティング経路を決定し、ルーティング経路に従って正確なフロー・エントリを第１のOFSに配送するように、経路情報追加ユニットが第２のOFSの経路情報を追加した更新されたOFPT_HELLOメッセージをOFCに転送するように構成された転送ユニット133と、を含む。
経路情報は、OFPT_HELLOメッセージを送信または受信するOFSのID、OFPT_HELLOメッセージを受信するために使用されるポート番号、およびOFPT_HELLOメッセージを送信するために使用されるポート番号を含む。
この実施例において、転送ユニット133は、具体的には、
更新されたOFPT_HELLOメッセージをOFCに直接的に転送するように構成され、ここで最終的に更新されたOFPT_HELLOメッセージは更新されたOFPT_HELLOメッセージであり、または、
１つまたはより多くの他のOFSを使用することによって、更新されたOFPT_HELLOメッセージをOFCに間接的に転送するように構成され、ここで他のOFSは経路情報を受信された更新されたOFPT_HELLOメッセージに追加して、最終的に更新されたOFPT_HELLOメッセージを取得する。
実施例７から実施例１３に関与する解決策の具体的なステップは、上記の実施例（例えば、実施例１から実施例５）の具体的な記載を参照してこの技術分野の当業者によって取得されることが可能であり、実施例７から実施例１３において詳細に記載されない。加えて、実施例７から実施例１３における装置に関与するユニット（またはサブユニット）は論理的な機能区分であり、これらのユニットの具体的な実現形態は限定されないことに留意すべきである。例えば、これらのユニットは、実施例６においてソフトウェアとハードウェアを組み合わせるアーキテクチャに基づいて実現され、またはソフトウェアのみのアーキテクチャを使用することによって実現され得る。ユニットに関与する機能は上記の方法の実施例における方法におけるステップに対応するので、この技術分野の当業者は実施例６における具体的なデバイスに従って各々のユニットを実現することが可能であり、例えば、装置の実施例に関与するいくつかの受信ユニットを実現するためにトランシーバを使用する。
この技術分野の当業者は、実施例における方法のプロセスの全てまたはいくつかは関係するハードウェアに命令するコンピュータ・プログラムによって実現され得ることを理解し得る。プログラムはコンピュータ読み取り可能な記憶媒体内に記憶され得る。プログラムが動作するとき、実施例における方法のプロセスが行われる。上記の記憶媒体は、磁気ディスク、光ディスク、リード・オンリ・メモリ（Read-Only Memory、ROM）、ランダム・アクセス・メモリ（Random Access Memory、RAM）、等であり得る。
上記の例示の実施例において、本発明の目的、技術的解決策、および利点が詳細にさらに記載されている。上記の記載は本発明の単なる例示の実施例であるが、本発明を限定することは意図されないことを理解すべきである。本発明の思想および原理から逸脱せずに行われるいずれの変更、等価な置換、または改善は本発明の保護範囲内にあるものである。
71 接続確立ユニット
711 受信サブユニット
712 第１の照合サブユニット
72 第１の受信ユニット
73 経路追加ユニット
731 第２の照合サブユニット
732 追加サブユニット
74 転送ユニット
741 第１の転送サブユニット
742 第２の転送サブユニット
81 第１の受信ユニット
82 経路獲得ユニット
83 フロー・テーブル配送ユニット
91 第１のSDNスイッチ
92 第２のSDNスイッチ
93 他の中間SDNスイッチ
94 SDNコントローラ

Claims (37)

  1. 第２のSDNスイッチに適用される、ソフトウェア定義ネットワーク（SDN）スイッチにより正確なフロー・エントリを獲得する方法であって、前記第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、前記SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、前記方法は、
    前記第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信するステップであって、前記第１の制御メッセージは前記第１のSDNスイッチの経路情報を搬送し、前記第１の制御メッセージは前記第１のSDNスイッチと前記SDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、ステップと、
    前記第２のSDNスイッチの経路情報を前記第１の制御メッセージに追加して、更新された第１の制御メッセージを取得するステップと、
    前記更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信した後に、前記SDNコントローラが、各々のSDNスイッチによって前記最終的に更新された第１の制御メッセージに追加された経路情報に従って、前記SDNコントローラと前記第１のSDNスイッチの間のルーティング経路を決定し、前記ルーティング経路に従って正確なフロー・エントリを前記第１のSDNスイッチに配送するように、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに転送するステップと、を含む方法。
  2. 前記第１のSDNスイッチと前記SDNコントローラの間で確立される信頼できる接続はTCP接続を含み、前記信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、前記TCP接続は、前記第２のSDNスイッチにより、前記第１のSDNスイッチと前記SDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することによって確立される、請求項１に記載の方法。
  3. 前記第２のSDNスイッチは正確なフロー・テーブルを記憶し、前記正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび前記複数の照合フィールドに対応する命令を含み、
    前記第２のSDNスイッチにより、前記第１のSDNスイッチと前記SDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することは、
    前記第２のSDNスイッチにより、前記第１のSDNスイッチから送信された第１のTCP/IPパケットを受信することと、
    前記受信された第１のTCP/IPパケット内の複数の特徴情報を獲得することであって、前記特徴情報は前記第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、前記獲得することと、
    前記複数の特徴情報と前記第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行うことと、前記正確な照合が失敗し、かつ前記受信された第１のTCP/IPパケットが第１のタイプのTCPハンドシェイク・メッセージを搬送すると判定されたならば、前記複数の特徴情報における１つまたはより多くの特徴情報と前記正確なフロー・テーブルの間でワイルドカード・マッチ照合を行うことであって、前記ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的に前記SDNコントローラに到達することができるルートである、前記ワイルドカード・マッチ照合を行うことと、前記ワイルドカード・マッチ照合が成功したならば、前記ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、前記第１のタイプのTCPハンドシェイク・メッセージを搬送する前記受信された第１のTCP/IPパケットを処理し、それによって前記第１のTCP/IPパケットを前記SDNコントローラに転送することであって、前記第１のタイプのTCPハンドシェイク・メッセージはSYNメッセージである第１のTCPハンドシェイクのメッセージまたはACKメッセージである第３のTCPハンドシェイクのメッセージである、前記転送することと、を含む、請求項１または２に記載の方法。
  4. 前記第２のSDNスイッチにより、前記第１のSDNスイッチと前記SDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することは、
    前記第２のSDNスイッチにより、前記SDNコントローラから送信された第３のTCP/IPパケットを受信することであって、前記第３のTCP/IPパケットはSYN-ACKメッセージである第２のTCPハンドシェイクのメッセージを搬送する、前記受信することと、
    前記第３のTCP/IPパケット内の複数の特徴情報を獲得することであって、前記特徴情報は前記第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、前記獲得することと、
    前記複数の特徴情報と前記第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、前記正確な照合が成功したならば、前記照合において成功した正確なフロー・エントリ内の命令に従って転送を行い、前記照合が失敗し、かつ前記第３のTCP/IPパケットが第２のTCPハンドシェイクの前記メッセージを搬送すると判定されたならば、前記第３のTCP/IPパケットをブロードキャストすることと、をさらに含む、請求項１から３のいずれか一項に記載の方法。
  5. 前記第２のSDNスイッチは前記正確なフロー・テーブルを記憶し、前記正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび前記複数の照合フィールドに対応する命令を含み、
    前記第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信するステップと、前記第２のSDNスイッチの経路情報を前記第１の制御メッセージに追加して、更新された第１の制御メッセージを取得するステップと、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに転送するステップとは、
    前記第２のSDNスイッチにより、前記第１のSDNスイッチから送信され、前記第１の制御メッセージを搬送する第２のTCP/IPパケットを受信するステップであって、前記第２のTCP/IPパケットは複数の特徴情報を含み、前記特徴情報は前記第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、ステップと、
    前記第２のSDNスイッチにより、前記第２のTCP/IPパケット内の特徴情報と前記正確なフロー・テーブルの間で正確な照合を行い、前記正確な照合が失敗し、かつ前記受信された第２のTCP/IPパケットが前記第１の制御メッセージを搬送すると判定された後に、前記TCP/IPパケット内の１つまたはより多くの特徴情報および前記正確なフロー・テーブルに従ってワイルドカード・マッチ照合を行い、前記ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的に前記SDNコントローラに到達することができるルートであり、前記ワイルドカード・マッチ照合が成功したならば、前記第２のSDNスイッチの経路情報を前記第１の制御メッセージに追加して、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを取得し、前記ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、前記更新された第１の制御メッセージを前記SDNコントローラに転送するステップとを含む、請求項２から４のいずれか一項に記載の方法。
  6. 前記ワイルドカード・マッチ照合が失敗したならば、前記第２のSDNスイッチの利用可能な出力ポートが獲得され、前記第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報が前記第１の制御メッセージに追加され、前記第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報が追加された前記更新された第１の制御メッセージが、前記利用可能な出力ポートから前記SDNコントローラに転送される、請求項５に記載の方法。
  7. 前記特徴情報は、宛先MAC、宛先IP、および宛先ポート番号を含み、前記正確なフロー・テーブル内のフロー・エントリ内の、ワイルドカード・マッチ照合のために使用される照合フィールドは、宛先MAC、宛先IP、および宛先ポート番号であり、前記複数の特徴情報における１つまたはより多くの特徴情報と前記正確なフロー・テーブルの間でワイルドカード・マッチ照合を行い、前記ワイルドカード・マッチ照合が成功したならば、前記ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、前記第１のタイプのTCPハンドシェイク・メッセージを搬送する前記受信された第１のTCP/IPパケットを処理することは、
    前記複数の特徴情報における宛先MAC、宛先IP、および宛先ポート番号と、フロー・エントリ内の宛先MAC、宛先IP、および宛先ポート番号の間で照合を行い、前記照合が成功したならば、前記照合において成功した正確なフロー・エントリ内の命令に従って、前記受信された第１のTCP/IPパケットを処理することを含む、請求項３に記載の方法。
  8. 前記SDNネットワークはOpenFlowプロトコルに基づいて実現され、前記第１の制御メッセージは前記OpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを含み、前記OFPT_HELLOメッセージのbodyフィールドは拡張された後に前記経路情報を搬送するために使用され、
    前記第２のSDNスイッチの経路情報を前記第１の制御メッセージに追加して、更新された第１の制御メッセージを取得するステップは、
    前記第２のSDNスイッチの経路情報を、前記OFPT_HELLOメッセージ内の、前記経路情報を搬送するために使用される前記拡張されたbodyフィールドに追加して、更新されたOFPT_HELLOメッセージを取得するステップを含み、
    前記更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信した後に、前記SDNコントローラが、各々のSDNスイッチによって前記最終的に更新された第１の制御メッセージに追加された経路情報に従って、前記SDNコントローラと前記第１のSDNスイッチの間のルーティング経路を決定し、前記ルーティング経路に従って正確なフロー・エントリを前記第１のSDNスイッチに配送するように、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに転送するステップは、
    前記更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、前記SDNコントローラが、各々のSDNスイッチによって前記最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、前記SDNコントローラと前記第１のSDNスイッチの間のルーティング経路を決定し、前記ルーティング経路に従って正確なフロー・エントリを前記第１のSDNスイッチに配送するように、前記第２のSDNスイッチの経路情報が追加された前記更新されたOFPT_HELLOメッセージを前記SDNコントローラに転送するステップを含む、請求項１から７のいずれか一項に記載の方法。
  9. 前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに転送するステップは、
    前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに直接的に転送するステップであって、前記最終的に更新された第１の制御メッセージは前記更新された第１の制御メッセージである、ステップ、または、
    １つまたはより多くの他のSDNスイッチを使用することによって、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに間接的に転送するステップであって、前記最終的に更新された第１の制御メッセージは、前記他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、前記他のSDNスイッチの各々の経路情報を前記第１の制御メッセージに追加した後に、前記他のSDNスイッチの各々によって前記SDNコントローラに最終的に送信された第１の制御メッセージである、ステップを含む、請求項１から８のいずれか一項に記載の方法。
  10. 前記SDNネットワークはOpenFlowプロトコルに基づいて実現され、前記方法は、
    前記SDNコントローラから送信され、前記OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するステップであって、前記OFPT_FLOW_MODメッセージは宛先SDNスイッチによって要求される複数の正確なフロー・エントリを搬送する、ステップと、
    前記受信されたメッセージが前記第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、前記OFPT_FLOW_MODメッセージ内で搬送された複数の正確なフロー・エントリを抽出し、そして前記複数の正確なフロー・エントリをローカルな正確なフロー・テーブルに追加するステップと、をさらに含む、請求項１から９のいずれか一項に記載の方法。
  11. 前記SDNネットワークはOpenFlowプロトコルに基づいて実現され、前記方法は、
    前記SDNコントローラから送信され、前記OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するステップであって、前記OFPT_FLOW_MODメッセージは、前記ルーティング経路上に位置する複数のSDNスイッチによって要求される複数の正確なフロー・エントリおよび前記ルーティング経路上の各々のSDNスイッチに対応する経路情報を搬送し、前記ルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを使用する、ステップと、
    前記受信されたメッセージが前記第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、前記第２のSDNスイッチに対応する経路情報に従って、前記第２のSDNスイッチによって使用される必要がある１つまたはより多くの正確なフロー・エントリを抽出し、前記抽出が完了した後に前記OFPT_FLOW_MODメッセージを前記ルーティング経路上の次のノードに転送するステップと、をさらに含む、請求項１から９のいずれか一項に記載の方法。
  12. 前記経路情報は、前記第１の制御メッセージを送信または受信するSDNスイッチのID、前記第１の制御メッセージを受信するために使用されるポート番号、および前記第１の制御メッセージを送信するために使用されるポート番号を含む、請求項１から１１のいずれか一項に記載の方法。
  13. ソフトウェア定義ネットワーク（SDN）スイッチであって、前記SDNスイッチは第２のSDNスイッチであり、前記第２のSDNスイッチは第１のSDNスイッチおよびSDNコントローラに接続されて、SDNネットワークを形成し、前記SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、前記第２のSDNスイッチは、
    前記第１のSDNスイッチと前記SDNコントローラの間で信頼できる接続が確立されるように、前記第１のSDNスイッチと前記SDNコントローラの間でメッセージ交換を行うように構成された接続確立ユニットと、
    前記第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信するように構成された第１の受信ユニットであって、前記第１の制御メッセージは前記第１のSDNスイッチの経路情報を搬送し、前記第１の制御情報は、前記信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、第１の受信ユニットと、
    前記第２のSDNスイッチの経路情報を前記第１の受信ユニットによって受信された第１の制御メッセージに追加して、更新された第１の制御メッセージを取得するように構成された経路追加ユニットと、
    前記更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信した後に、前記SDNコントローラが、各々のSDNスイッチによって前記最終的に更新された第１の制御メッセージに追加された経路情報に従って、前記SDNコントローラと前記第１のSDNスイッチの間のルーティング経路を決定し、前記ルーティング経路に従って正確なフロー・エントリを前記第１のSDNスイッチに配送するように、前記経路追加ユニットが前記第２のSDNスイッチの経路情報を追加した前記更新された第１の制御メッセージを前記SDNコントローラに転送するように構成された転送ユニットと、を含むSDNスイッチ。
  14. 前記第１のSDNスイッチと前記SDNコントローラの間で確立される信頼できる接続はTCP接続を含み、前記信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、
    前記接続確立ユニットは、具体的には、TCP接続が前記第１のSDNスイッチと前記SDNコントローラの間で確立されるように、前記第１のSDNスイッチと前記SDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送するように構成される、請求項１３に記載のSDNスイッチ。
  15. 前記第２のSDNスイッチは正確なフロー・テーブルを含み、前記正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび前記複数の照合フィールドに対応する命令を含み、
    前記接続確立ユニットは、
    前記第１のSDNスイッチから送信された第１のTCP/IPパケットを受信するように構成された受信サブユニットと、
    前記受信サブユニットによって受信された前記第１のTCP/IPパケット内の複数の特徴情報を獲得するように構成された特徴情報獲得サブユニットであって、前記特徴情報は前記第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応する、特徴情報獲得サブユニットと、
    前記特徴情報獲得サブユニットによって獲得された第１のTCP/IPパケット内の複数の特徴情報と、前記第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、前記正確な照合が失敗し、かつ前記受信された第１のTCP/IPパケットが第１のタイプのTCPハンドシェイク・メッセージを搬送すると判定されたならば、前記複数の特徴情報における１つまたはより多くの特徴情報と前記正確なフロー・テーブルの間でワイルドカード・マッチ照合を行うように構成された第１の照合サブユニットであって、前記ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的に前記SDNコントローラに到達することができるルートであり、前記第１の照合サブユニットは、前記ワイルドカード・マッチ照合が成功したならば、前記ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、前記第１のタイプのTCPハンドシェイク・メッセージを搬送する前記受信された第１のTCP/IPパケットを処理し、それによって,前記第１のTCP/IPパケットを前記SDNコントローラに転送するように構成され、前記第１のタイプのTCPハンドシェイク・メッセージはSYNメッセージである第１のTCPハンドシェイクのメッセージまたはACKメッセージである第３のTCPハンドシェイクのメッセージである、第１の照合サブユニットと、を含む、請求項１３または１４に記載のSDNスイッチ。
  16. 前記受信サブユニットは、前記SDNコントローラから送信された第３のTCP/IPパケットを受信するようにさらに構成され、前記第３のTCP/IPパケットはSYN-ACKメッセージである第２のTCPハンドシェイクのメッセージを搬送し、
    前記特徴情報獲得サブユニットは、前記受信サブユニットによって受信された第３のTCP/IPパケット内の複数の特徴情報を獲得するようにさらに構成され、前記特徴情報は前記第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、
    前記第１の照合サブユニットは、前記特徴情報獲得サブユニットによって獲得された第３のTCP/IPパケット内の複数の特徴情報と、前記第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、前記正確な照合が成功したならば、前記照合において成功した正確なフロー・エントリ内の命令に従って転送を行い、前記照合が失敗し、かつ前記第３のTCP/IPパケットが第２のTCPハンドシェイクの前記メッセージを搬送すると判定されたならば、前記第３のTCP/IPパケットをブロードキャストするようにさらに構成された、請求項１５に記載のSDNスイッチ。
  17. 前記第２のSDNスイッチは前記正確なフロー・テーブルを記憶し、前記正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび前記複数の照合フィールドに対応する命令を含み、
    前記第１の受信ユニットは、具体的には、
    前記第１のSDNスイッチから送信され、前記第１の制御メッセージを搬送する第２のTCP/IPパケットを受信するように構成され、前記第２のTCP/IPパケットは複数の特徴情報を含み、前記特徴情報は前記第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、
    前記経路追加ユニットは、
    第２の受信サブユニットによって受信された第２のTCP/IPパケット内の特徴情報および前記正確なフロー・テーブルに従って正確な照合を行い、前記正確な照合が失敗し、かつ前記受信された第２のTCP/IPパケットが前記第１の制御メッセージを搬送すると判定された後に、前記TCP/IPパケット内の１つまたはより多くの特徴情報および前記正確なフロー・テーブルに従ってワイルドカード・マッチ照合を行うように構成された第２の照合サブユニットであって、前記ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的に前記SDNコントローラに到達することができるルートである、第２の照合サブユニットと、
    前記第２の照合サブユニットのワイルドカード・マッチ照合が成功したとき、前記第２のSDNスイッチの経路情報を前記第１の制御メッセージに追加して、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを取得するように構成された追加サブユニットと、を含み、
    前記転送ユニットは、前記ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、前記追加サブユニットの処理の後に取得された前記更新された第１の制御メッセージを前記SDNコントローラに転送するように構成された第１の転送サブユニットを含む、請求項１３から１６のいずれか一項に記載のSDNスイッチ。
  18. 前記追加サブユニット（732）は、前記第２の照合サブユニットのワイルドカード・マッチ照合が失敗したならば、前記第２のSDNスイッチの利用可能な出力ポートを獲得し、前記第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報を前記第１の制御メッセージに追加するようにさらに構成され、
    前記転送ユニットは、前記追加サブユニットが、前記第２のSDNスイッチの、各々の利用可能な出力ポートに対応する経路情報を追加した前記更新された第１の制御メッセージを、前記利用可能な出力ポートから前記SDNコントローラに転送するように構成された第２の転送サブユニットをさらに含む、請求項１７に記載のSDNスイッチ。
  19. 前記SDNネットワークはOpenFlowプロトコルに基づいて実現され、前記第１の制御メッセージは前記OpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを含み、前記OFPT_HELLOメッセージのbodyフィールドは拡張された後に前記経路情報を搬送するために使用され、
    前記第１の受信ユニットは、具体的には、前記接続確立ユニットによって確立された信頼できる接続を使用することによって、前記第１のSDNスイッチによって送信され、前記経路情報を収集するために使用されるOFPT_HELLOメッセージを受信するように構成され、前記OFPT_HELLOメッセージ内の、前記経路情報を搬送するために使用される前記拡張されたbodyフィールドは、前記第１のSDNスイッチの経路情報を搬送し、
    前記経路追加ユニットは、具体的には、前記第１の受信ユニットによって受信されたOFPT_HELLOメッセージ内の、前記経路情報を搬送するために使用される前記拡張されたbodyフィールドに、前記第２のSDNスイッチの経路情報を追加して、更新されたOFPT_HELLOメッセージを取得するように構成され、
    前記転送ユニットは、具体的には、前記更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、前記SDNコントローラが、各々のSDNスイッチによって前記最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、前記SDNコントローラと前記第１のSDNスイッチの間のルーティング経路を決定し、前記ルーティング経路に従って正確なフロー・エントリを前記第１のSDNスイッチに配送するように、前記経路追加ユニットが前記第２のSDNスイッチの経路情報を追加した前記更新されたOFPT_HELLOメッセージを前記SDNコントローラに転送するように構成された、請求項１３から１８のいずれか一項に記載のSDNスイッチ。
  20. 前記転送ユニットは、具体的には、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに直接的に転送するように構成され、前記最終的に更新された第１の制御メッセージは前記更新された第１の制御メッセージであり、または、
    １つまたはより多くの他のSDNスイッチを使用することによって、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに間接的に転送するように構成され、前記最終的に更新された第１の制御メッセージは、前記他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、前記他のSDNスイッチの各々の経路情報を前記第１の制御メッセージに追加した後に、前記他のSDNスイッチの各々によって前記SDNコントローラに最終的に送信された第１の制御メッセージである、請求項１３から１９のいずれか一項に記載のSDNスイッチ。
  21. 前記SDNネットワークはOpenFlowプロトコルに基づいて実現され、前記SDNスイッチは、
    前記SDNコントローラから送信され、前記OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するように構成された第２の受信ユニットであって、前記OFPT_FLOW_MODメッセージは宛先SDNスイッチによって要求される複数の正確なフロー・エントリを搬送する、第２の受信ユニットと、
    前記第２の受信ユニットによって受信されたメッセージが前記第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、前記OFPT_FLOW_MODメッセージ内で搬送された複数の正確なフロー・エントリを抽出し、そして前記複数の正確なフロー・エントリをローカルな正確なフロー・テーブルに追加するように構成された第１のフロー・エントリ処理ユニットと、をさらに含む、請求項１３から２０のいずれか一項に記載のSDNスイッチ。
  22. 前記SDNネットワークはOpenFlowプロトコルに基づいて実現され、前記SDNスイッチは、
    前記SDNコントローラから送信され、前記OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するように構成された第３の受信ユニットであって、前記OFPT_FLOW_MODメッセージは、前記ルーティング経路上に位置する複数のSDNスイッチによって要求される複数の正確なフロー・エントリおよび前記ルーティング経路上の各々のSDNスイッチに対応する経路情報を搬送し、前記ルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを使用する、第３の受信ユニットと、
    前記第３の受信ユニットによって受信されたメッセージが前記第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、前記第２のSDNスイッチに対応する経路情報に従って、前記第２のSDNスイッチによって使用される必要がある１つまたはより多くの正確なフロー・エントリを抽出し、前記抽出が完了した後に前記OFPT_FLOW_MODメッセージを前記ルーティング経路上の次のノードに転送するように構成された第２のフロー・エントリ処理ユニットと、をさらに含む、請求項１３から２０のいずれか一項に記載のSDNスイッチ。
  23. 前記経路情報は、前記第１の制御メッセージを送信または受信するSDNスイッチのID、前記第１の制御メッセージを受信するために使用されるポート番号、および前記第１の制御メッセージを送信するために使用されるポート番号を含む、請求項１３から２２のいずれか一項に記載のSDNスイッチ。
  24. ソフトウェア定義ネットワークSDNシステムであって、第１のSDNスイッチ、第２のSDNスイッチ、およびSDNコントローラを含み、前記第２のSDNスイッチは前記第１のSDNスイッチおよび前記SDNコントローラに接続されて、SDNネットワークを形成し、前記SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、
    前記第１のSDNスイッチは、経路情報を収集するために使用される第１の制御メッセージを前記第２のSDNスイッチに送信するように構成され、前記第１の制御メッセージは前記第１のSDNスイッチの経路情報を搬送し、前記第１の制御情報は前記第１のSDNスイッチと前記SDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送され、
    前記第２のSDNスイッチは、前記第１の制御メッセージを受信し、前記第２のSDNスイッチの経路情報を前記第１の制御メッセージに追加して、更新された第１の制御メッセージを取得し、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに転送するように構成され、
    前記SDNコントローラは、前記第２のSDNスイッチによって送信され、前記更新された第１の制御メッセージを含む最終的に更新された第１の制御メッセージを受信し、各々のSDNスイッチによって前記最終的に更新された第１の制御メッセージに追加された経路情報に従って前記SDNコントローラと前記第１のSDNスイッチの間のルーティング経路を決定し、前記ルーティング経路に従って正確なフロー・エントリを前記第１のSDNスイッチに配送するように構成されたSDNシステム。
  25. 前記第１のSDNスイッチと前記SDNコントローラの間で確立される信頼できる接続はTCP接続を含み、前記信頼できる接続によって使用されるプロトコルに対応するパケットはTCP/IPパケットであり、前記TCP接続は、前記第２のSDNスイッチにより、前記第１のSDNスイッチと前記SDNコントローラの間で行われる３方向TCPハンドシェイクのメッセージを搬送するTCP/IPパケットを転送することによって確立される、請求項２４に記載のシステム。
  26. 前記第２のSDNスイッチは正確なフロー・テーブルを記憶し、前記正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび前記複数の照合フィールドに対応する命令を含み、
    前記第２のSDNスイッチは、具体的には、前記第１のSDNスイッチから送信された第１のTCP/IPパケットを受信し、前記受信された第１のTCP/IPパケット内の複数の特徴情報を取得するように構成され、前記特徴情報は前記第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、前記第２のSDNスイッチは、前記複数の特徴情報と前記第２のSDNスイッチにおける正確なフロー・テーブルの間で正確な照合を行い、前記正確な照合が失敗し、かつ前記受信された第１のTCP/IPパケットが第１のタイプのTCPハンドシェイク・メッセージを搬送すると判定されたならば、前記複数の特徴情報における１つまたはより多くの特徴情報と前記正確なフロー・テーブルの間でワイルドカード・マッチ照合を行うように構成され、前記ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的に前記SDNコントローラに到達することができるルートであり、前記第２のSDNスイッチは、前記ワイルドカード・マッチ照合が成功したならば、前記ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、前記第１のタイプのTCPハンドシェイク・メッセージを搬送する前記受信された第１のTCP/IPパケットを処理し、それによって前記第１のTCP/IPパケットを前記SDNコントローラに転送するように構成され、前記第１のタイプのTCPハンドシェイク・メッセージはSYNメッセージである第１のTCPハンドシェイクのメッセージまたはACKメッセージである第３のTCPハンドシェイクのメッセージであり、それによって前記第１のSDNスイッチ、前記他のOFS、および前記SDNコントローラの間で、前記信頼できる接続を確立するために使用されるメッセージの交換を実現して、前記信頼できる接続を確立する、請求項２５に記載のシステム。
  27. 前記第２のSDNスイッチは前記正確なフロー・テーブルを記憶し、前記正確なフロー・テーブルは複数の正確なフロー・エントリを含み、各々の正確なフロー・エントリは複数の照合フィールドおよび前記複数の照合フィールドに対応する命令を含み、
    前記第２のSDNスイッチは、具体的には、前記第１のSDNスイッチから送信され、前記第１の制御メッセージを搬送する第２のTCP/IPパケットを受信するようにさらに構成され、前記第２のTCP/IPパケットは複数の特徴情報を含み、前記特徴情報は前記第２のSDNスイッチにおける正確なフロー・テーブル内の正確なフロー・エントリ内の照合フィールドに対応し、前記第２のSDNスイッチは、前記第２のTCP/IPパケット内の特徴情報および前記正確なフロー・テーブルに従って正確な照合を行い、前記正確な照合が失敗し、かつ前記受信された第２のTCP/IPパケットが前記第１の制御メッセージを搬送すると判定された後に、前記TCP/IPパケット内の１つまたはより多くの特徴情報および前記正確なフロー・テーブルに従ってワイルドカード・マッチ照合を行うようにさらに構成され、前記ワイルドカード・マッチ照合の間に使用される１つまたはより多くの照合フィールドに対応する命令を使用することによって決定された転送ルートは、最終的に前記SDNコントローラに到達することができるルートであり、前記第２のSDNスイッチは、前記ワイルドカード・マッチ照合が成功したならば、前記第２のSDNスイッチの経路情報を前記第１の制御メッセージに追加して、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを取得し、前記ワイルドカード・マッチ照合において成功した正確なフロー・エントリ内の命令に従って、前記更新された第１の制御メッセージを前記SDNコントローラに転送するようにさらに構成された、請求項２５または２６に記載のシステム。
  28. 前記SDNネットワークはOpenFlowプロトコルに基づいて実現され、前記第１の制御メッセージは前記OpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを含み、前記OFPT_HELLOメッセージのbodyフィールドは拡張された後に前記経路情報を搬送するために使用される、請求項２４から２７のいずれか一項に記載のシステム。
  29. 前記第２のSDNスイッチは、具体的には、
    前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNコントローラに直接的に転送するように構成され、前記最終的に更新された第１の制御メッセージは前記更新された第１の制御メッセージであり、または、
    １つまたはより多くの他のSDNスイッチを使用することによって、前記第２のSDNスイッチの経路情報が追加された前記更新された第１の制御メッセージを前記SDNに間接的に転送するように構成され、前記最終的に更新された第１の制御メッセージは、前記他のSDNスイッチの各々が前のSDNスイッチによって送信された第１の制御メッセージを受信し、前記他のSDNスイッチの各々の経路情報を前記第１の制御メッセージに追加した後に、前記他のSDNスイッチの各々によって前記SDNコントローラに最終的に送信された第１の制御メッセージである、請求項２４から２８のいずれか一項に記載のシステム。
  30. 前記SDNネットワークはOpenFlowプロトコルに基づいて実現され、前記第２のSDNスイッチは、
    前記SDNコントローラから送信され、前記OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するようにさらに構成され、前記OFPT_FLOW_MODメッセージは宛先SDNスイッチによって要求される複数の正確なフロー・エントリを搬送し、
    前記第２のSDNスイッチは、前記受信されたメッセージが前記第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、前記OFPT_FLOW_MODメッセージ内で搬送された複数の正確なフロー・エントリを抽出し、そして前記複数の正確なフロー・エントリをローカルな正確なフロー・テーブルに追加するようにさらに構成された、請求項２４から２９のいずれか一項に記載のシステム。
  31. 前記SDNネットワークはOpenFlowプロトコルに基づいて実現され、前記第２のSDNスイッチは、
    前記SDNコントローラから送信され、前記OpenFlowプロトコルにおいて定義されたOFPT_FLOW_MODメッセージを受信するようにさらに構成され、前記OFPT_FLOW_MODメッセージは、前記ルーティング経路上に位置する複数のSDNスイッチによって要求される複数の正確なフロー・エントリおよび前記ルーティング経路上の各々のSDNスイッチに対応する経路情報を搬送し、前記ルーティング経路上の各々のSDNスイッチは１つまたはより多くの正確なフロー・エントリを使用し、
    前記第２のSDNスイッチは、前記受信されたメッセージが前記第２のSDNスイッチに送信されたOFPT_FLOW_MODメッセージであると判定されたとき、前記第２のSDNスイッチに対応する経路情報に従って、前記第２のSDNスイッチによって使用される必要がある１つまたはより多くの正確なフロー・エントリを抽出し、前記抽出が完了した後に前記OFPT_FLOW_MODメッセージを前記ルーティング経路上の次のノードに転送するようにさらに構成された、請求項２４から３０のいずれか一項に記載のシステム。
  32. 前記経路情報は、前記第１の制御メッセージを送信または受信するSDNスイッチのID、前記第１の制御メッセージを受信するために使用されるポート番号、および前記第１の制御メッセージを送信するために使用されるポート番号を含む、請求項２４から３１のいずれか一項に記載のシステム。
  33. SDNコントローラに適用される、ソフトウェア定義ネットワークSDNスイッチによりフロー・テーブルを獲得するための方法であって、前記SDNコントローラは第２のSDNスイッチに接続され、前記第２のSDNスイッチは第１のSDNスイッチに接続されて、SDNネットワークを形成し、前記SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、前記方法は、
    前記第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを受信するステップであって、前記最終的に更新された第１の制御メッセージは更新された第１の制御メッセージを含み、前記第２のSDNスイッチが、前記第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信した後に、前記第２のSDNスイッチにより、前記第２のSDNスイッチの経路情報を前記第１の制御メッセージに追加することによって、前記更新された第１の制御メッセージが取得され、前記第１の制御メッセージは前記第１のSDNスイッチの経路情報を搬送し、前記第１の制御情報は前記第１のSDNスイッチと前記SDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、ステップと、
    各々のSDNスイッチによって追加され、前記最終的に更新された第１の制御メッセージ内で搬送された経路情報に従って、前記SDNコントローラと前記第１のSDNスイッチの間のルーティング経路を獲得するステップと、
    前記ルーティング経路に従って正確なフロー・エントリを前記第１のSDNスイッチに配送するステップと、を含む方法。
  34. ソフトウェア定義ネットワークSDNコントローラであって、前記SDNコントローラは第２のSDNスイッチに接続され、前記第２のSDNスイッチは第１のSDNスイッチに接続されて、SDNネットワークを形成し、前記SDNコントローラは帯域内通信の形態で各々のSDNスイッチと通信し、前記SDNコントローラは、
    前記第２のSDNスイッチによって転送された最終的に更新された第１の制御メッセージを受信するように構成された第１の受信ユニットであって、前記最終的に更新された第１の制御メッセージは更新された第１の制御メッセージを含み、前記第２のSDNスイッチが、前記第１のSDNスイッチによって送信され、経路情報を収集するために使用される第１の制御メッセージを受信した後に、前記第２のSDNスイッチにより、前記第２のSDNスイッチの経路情報を前記第１の制御メッセージに追加することによって、前記更新された第１の制御メッセージが取得され、前記第１の制御メッセージは前記第１のSDNスイッチの経路情報を搬送し、前記第１の制御情報は前記第１のSDNスイッチと前記SDNコントローラの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、第１の受信ユニットと、
    各々のSDNスイッチによって追加され、前記第１の受信ユニットによって受信された前記最終的に更新された第１の制御メッセージ内で搬送された経路情報に従って、前記SDNコントローラと前記第１のSDNスイッチの間のルーティング経路を獲得するように構成された経路獲得ユニットと、
    前記経路獲得ユニットによって獲得されたルーティング経路を通して正確なフロー・エントリを前記第１のSDNスイッチに配送するように構成されたフロー・テーブル配送ユニットと、を含むSDNコントローラ。
  35. 第２のOFSに適用される、オープンフロー・スイッチOpenFlow Switch OFSにより、経路情報を収集するための方法であって、前記第２のOFSは第１のOFSおよびオープンフロー・コントローラOpenFlow Controller OFCに接続されて、OpenFlowネットワークを形成し、前記OFCは帯域内通信の形態で各々のOFSと通信し、前記方法は、
    前記第１のOFSによって送信され、経路情報を収集するために使用され、OpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを受信するステップであって、前記OFPT_HELLOメッセージのbodyフィールドは拡張された後に前記経路情報を搬送するために使用され、前記OFPT_HELLOメッセージは前記第１のOFSの経路情報を搬送し、前記OFPT_HELLOメッセージは前記第１のOFSと前記OFCの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、ステップと、
    前記第２のOFSの経路情報を前記OFPT_HELLOメッセージに追加して、更新されたOFPT_HELLOメッセージを取得するステップと、
    前記更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、前記OFCが、各々のOFSによって前記最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、前記OFCと前記第１のOFSの間のルーティング経路を決定し、前記ルーティング経路に従って正確なフロー・エントリを前記第１のOFSに配送するように、前記更新されたOFPT_HELLOメッセージを前記OFCに転送するステップと、を含む方法。
  36. オープンフロー・スイッチOpenFlow Switch OFSであって、
    前記OFSは第２のOFSであり、前記第２のOFSは、第１のOFS、オープンフロー・コントローラOpenFlow Controller OFC、および少なくとも１つの他のOFSに接続されて、OpenFlowネットワークを形成し、前記OFCは帯域内通信の形態で各々のOFSと通信し、前記第２のOFSは、
    前記第１のOFSによって送信され、経路情報を収集するために使用され、OpenFlowプロトコルにおいて定義されたOFPT_HELLOメッセージを受信するように構成された受信ユニットであって、前記OFPT_HELLOメッセージのbodyフィールドは拡張された後に前記経路情報を搬送するために使用され、前記OFPT_HELLOメッセージは前記第１のOFSの経路情報を搬送し、前記OFPT_HELLOメッセージは前記第１のOFSと前記OFCの間で確立される信頼できる接続によって使用されるプロトコルに対応するパケット内で搬送される、受信ユニットと、
    前記第２のOFSの経路情報を、前記受信ユニットによって受信されたOFPT_HELLOメッセージに追加して、更新されたOFPT_HELLOメッセージを取得するように構成された経路情報追加ユニットと、
    前記更新されたOFPT_HELLOメッセージを含む最終的に更新されたOFPT_HELLOメッセージを受信した後に、前記OFCが、各々のOFSによって前記最終的に更新されたOFPT_HELLOメッセージに追加された経路情報に従って、前記OFCと前記第１のOFSの間のルーティング経路を決定し、前記ルーティング経路に従って正確なフロー・エントリを前記第１のOFSに配送するように、前記経路情報追加ユニットが前記第２のOFSの経路情報を追加した前記更新されたOFPT_HELLOメッセージを前記OFCに転送するように構成された転送ユニットと、を含むOFS。
  37. コンピュータに請求項１乃至１２、３３、および３５のいずれか一項に記載の方法を実行させるプログラムをその中に有するコンピュータ可読記憶媒体。
JP2016526160A 2013-10-26 2014-09-15 Ｓｄｎスイッチにより正確なフロー・エントリを獲得するための方法、およびｓｄｎスイッチ、コントローラ、およびシステム Active JP6144834B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201310514564.2 2013-10-26
CN201310514564.2A CN104579968B (zh) 2013-10-26 2013-10-26 Sdn交换机获取精确流表项方法及sdn交换机、控制器、系统
PCT/CN2014/086484 WO2015058597A1 (zh) 2013-10-26 2014-09-15 Sdn交换机获取精确流表项方法及sdn交换机、控制器、系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2017093741A Division JP6500304B2 (ja) 2013-10-26 2017-05-10 Ｓｄｎスイッチにより正確なフロー・エントリを獲得するための方法、およびｓｄｎスイッチ、コントローラ、およびシステム

Publications (2)

Publication Number Publication Date
JP2016538768A JP2016538768A (ja) 2016-12-08
JP6144834B2 true JP6144834B2 (ja) 2017-06-07

Family

ID=52992228

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2016526160A Active JP6144834B2 (ja) 2013-10-26 2014-09-15 Ｓｄｎスイッチにより正確なフロー・エントリを獲得するための方法、およびｓｄｎスイッチ、コントローラ、およびシステム
JP2017093741A Active JP6500304B2 (ja) 2013-10-26 2017-05-10 Ｓｄｎスイッチにより正確なフロー・エントリを獲得するための方法、およびｓｄｎスイッチ、コントローラ、およびシステム

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2017093741A Active JP6500304B2 (ja) 2013-10-26 2017-05-10 Ｓｄｎスイッチにより正確なフロー・エントリを獲得するための方法、およびｓｄｎスイッチ、コントローラ、およびシステム

Country Status (7)

Country Link
US (2) US9742656B2 (ja)
EP (1) EP3062468B1 (ja)
JP (2) JP6144834B2 (ja)
KR (2) KR101776650B1 (ja)
CN (2) CN108183861B (ja)
AU (1) AU2014339535C1 (ja)
WO (1) WO2015058597A1 (ja)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103259728B (zh) 2013-05-24 2016-03-30 华为技术有限公司 一种ofs带内通信方法及ofs
CN104580025B (zh) 2013-10-18 2018-12-14 华为技术有限公司 用于开放流网络中建立带内连接的方法和交换机
US10257091B2 (en) * 2014-04-08 2019-04-09 Hewlett Packard Enterprise Development Lp Pipeline table identification
TW201605198A (zh) 2014-07-31 2016-02-01 萬國商業機器公司 智慧網路管理裝置以及管理網路的方法
US10015048B2 (en) 2014-12-27 2018-07-03 Intel Corporation Programmable protocol parser for NIC classification and queue assignments
US9998374B1 (en) * 2015-03-01 2018-06-12 Netronome Systems, Inc. Method of handling SDN protocol messages in a modular and partitioned SDN switch
US10009270B1 (en) * 2015-03-01 2018-06-26 Netronome Systems, Inc. Modular and partitioned SDN switch
KR102265861B1 (ko) * 2015-03-05 2021-06-16 한국전자통신연구원 플로우 제어 관리방법 및 그 장치
CN104980302B (zh) * 2015-05-12 2018-06-19 上海斐讯数据通信技术有限公司 一种在sdn框架下基于stp消除冗余链路的方法
CN107409088B (zh) * 2015-05-15 2020-02-14 华为技术有限公司 一种数据包转发方法和网络设备
US9825862B2 (en) 2015-08-26 2017-11-21 Barefoot Networks, Inc. Packet header field extraction
CN105337857B (zh) * 2015-11-23 2018-05-25 北京邮电大学 一种基于软件定义网络的多路径传输方法
US10171336B2 (en) * 2015-12-16 2019-01-01 Telefonaktiebolaget Lm Ericsson (Publ) Openflow configured horizontally split hybrid SDN nodes
US9912774B2 (en) 2015-12-22 2018-03-06 Intel Corporation Accelerated network packet processing
CN105871624B (zh) * 2016-05-24 2019-07-16 中国电子科技集团公司第三十研究所 不依赖于控制专网的动态sdn控制信令带内传输方法
CN107547293B (zh) 2016-06-29 2020-09-08 新华三技术有限公司 一种流路径探测方法和装置
US20180006833A1 (en) * 2016-06-29 2018-01-04 Argela Yazilim ve Bilisim Teknolojileri San. ve Tic. A.S. System and method for controller-initiated simultaneous discovery of the control tree and data network topology in a software defined network
CN107566277B (zh) 2016-06-30 2020-09-25 华为技术有限公司 拓扑确定方法、消息响应方法、控制器以及交换机
CN107786995A (zh) * 2016-08-26 2018-03-09 北京三星通信技术研究有限公司 用户平面建立的方法及相应设备
CN107786441B (zh) * 2016-08-30 2020-09-11 迈普通信技术股份有限公司 一种通信方法、OpenFlow交换机及通信系统
US10911317B2 (en) * 2016-10-21 2021-02-02 Forward Networks, Inc. Systems and methods for scalable network modeling
US10121011B2 (en) 2016-11-16 2018-11-06 The United States Of America As Represented By The Secretary Of The Air Force Apparatus, method and article of manufacture for partially resisting hardware trojan induced data leakage in sequential logics
KR101867880B1 (ko) * 2016-11-22 2018-06-18 아토리서치(주) 서비스 기능 체인을 운용하는 방법, 장치 및 컴퓨터 프로그램
US11223520B1 (en) 2017-01-31 2022-01-11 Intel Corporation Remote control plane directing data plane configurator
CN108390899B (zh) * 2017-02-03 2020-02-04 中国科学院声学研究所 一种基于软件定义网络的二层交换机内容协同的方法
US10694006B1 (en) 2017-04-23 2020-06-23 Barefoot Networks, Inc. Generation of descriptive data for packet fields
US10243859B2 (en) * 2017-05-23 2019-03-26 Dell Products L.P. Communications-capability-based SDN control system
CN109150729B (zh) * 2017-06-28 2021-11-19 中国移动通信有限公司研究院 一种数据转发控制方法、装置、系统、介质和计算设备
US11503141B1 (en) 2017-07-23 2022-11-15 Barefoot Networks, Inc. Stateful processing unit with min/max capability
CN108418755B (zh) * 2017-07-25 2019-10-11 新华三技术有限公司 数据流传输方法和装置
TWI639325B (zh) * 2017-09-01 2018-10-21 財團法人工業技術研究院 自動配置的交換機、自動配置交換機的方法、交換機自動部署的軟體定義網路系統及其方法
US10536379B2 (en) * 2017-09-28 2020-01-14 Argela Yazilim Ve Bilisim Teknolojileri San Ve Tic. A.S. System and method for control traffic reduction between SDN controller and switch
US10594630B1 (en) 2017-09-28 2020-03-17 Barefoot Networks, Inc. Expansion of packet data within processing pipeline
CN109787900B (zh) * 2017-11-15 2022-04-19 阿里巴巴集团控股有限公司 传输方法、装置、设备和机器可读介质
KR102592206B1 (ko) 2018-06-25 2023-10-20 현대자동차주식회사 차량 내 sdn 기반의 네트워크 관리 장치 및 그 제어 방법
JP2020005051A (ja) * 2018-06-26 2020-01-09 富士通株式会社 制御プログラム、制御装置、及び制御方法
CN109039959B (zh) * 2018-07-27 2021-04-16 广东工业大学 一种sdn网络规则的一致性判断方法及相关装置
US10798005B2 (en) * 2018-09-13 2020-10-06 International Business Machines Corporation Optimizing application throughput
US11095495B2 (en) * 2019-04-05 2021-08-17 Arista Networks, Inc. Multi-result lookups
US10849179B1 (en) * 2019-05-29 2020-11-24 Bank Of America Corporation Mobile network tool
US11252096B2 (en) 2019-06-20 2022-02-15 Microsoft Technology Licensing, Llc Network flow state management for connectionless protocol(s)
CN110380993B (zh) * 2019-07-12 2021-09-14 中国电信集团工会上海市委员会 一种基于ovsdb的流表保护方法
CN112769699B (zh) * 2019-11-05 2022-04-15 烽火通信科技股份有限公司 一种sd-wan网络中路由信息分发和更新的方法及控制器

Family Cites Families (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3609358B2 (ja) * 2000-08-17 2005-01-12 日本電信電話株式会社 フロー識別検索装置および方法
JP2003298613A (ja) * 2002-04-03 2003-10-17 Fujitsu Ltd アドレス検索方法及びこれを用いる検索システム
US8363790B2 (en) * 2008-07-17 2013-01-29 At&T Intellectual Property I, L.P. Method and apparatus for providing automated processing of a switched voice service alarm
JP5644775B2 (ja) * 2009-12-28 2014-12-24 日本電気株式会社 通信システムおよびトポロジー情報作成方法
JP5645139B2 (ja) * 2010-01-05 2014-12-24 日本電気株式会社 ネットワークシステム、コントローラ、ネットワーク制御方法
WO2011083785A1 (ja) * 2010-01-05 2011-07-14 日本電気株式会社 ネットワークシステム、及びネットワーク冗長化方法
JP5548892B2 (ja) 2010-01-08 2014-07-16 独立行政法人日本原子力研究開発機構 ピクセル型二次元イメージ検出器
CA2814072A1 (en) * 2010-10-15 2012-04-19 Nec Corporation Switch system, and monitoring centralized control method
JP5854049B2 (ja) * 2011-01-28 2016-02-09 日本電気株式会社 通信システム、制御情報中継装置、制御装置、制御情報の送信方法およびプログラム
US8873398B2 (en) * 2011-05-23 2014-10-28 Telefonaktiebolaget L M Ericsson (Publ) Implementing EPC in a cloud computer with openflow data plane
WO2012164958A1 (en) * 2011-06-02 2012-12-06 Nec Corporation Communication system, control device, forwarding node, and control method and program for communication system
US9167501B2 (en) * 2011-08-29 2015-10-20 Telefonaktiebolaget L M Ericsson (Publ) Implementing a 3G packet core in a cloud computer with openflow data and control planes
US20140241368A1 (en) 2011-10-21 2014-08-28 Nec Corporation Control apparatus for forwarding apparatus, control method for forwarding apparatus, communication system, and program
WO2013078685A1 (zh) 2011-12-02 2013-06-06 华为技术有限公司 发送消息的方法、接收消息方法、开放流控制器及第一开放流交换机
US9100203B2 (en) * 2012-01-12 2015-08-04 Brocade Communications Systems, Inc. IP multicast over multi-chassis trunk
US9444611B2 (en) 2012-01-16 2016-09-13 Nec Corporation Network system and method of synchronizing path information
CN102594689B (zh) * 2012-02-22 2015-06-10 中兴通讯股份有限公司 一种分布式网络控制方法及装置
CN102546351B (zh) * 2012-03-15 2014-05-14 北京邮电大学 openflow网络和现有IP网络互联的系统和方法
CN102710432B (zh) * 2012-04-27 2015-04-15 北京云杉世纪网络科技有限公司 云计算数据中心中的虚拟网络管理系统及方法
US8942085B1 (en) * 2012-05-23 2015-01-27 Google Inc. System and method for routing around failed links
US20140146664A1 (en) * 2012-11-26 2014-05-29 Level 3 Communications, Llc Apparatus, system and method for packet switching
US9246847B2 (en) * 2012-12-17 2016-01-26 Telefonaktiebolaget L M Ericsson (Publ) Extending the reach and effectiveness of header compression in access networks using SDN
US9203748B2 (en) * 2012-12-24 2015-12-01 Huawei Technologies Co., Ltd. Software defined network-based data processing method, node, and system
US9270618B2 (en) * 2013-02-28 2016-02-23 International Business Machines Corporation Source routing with fabric switches in an ethernet fabric network
WO2014136850A1 (ja) * 2013-03-06 2014-09-12 日本電気株式会社 通信システム、制御装置、転送ノード、制御方法およびプログラム
CN103347013B (zh) * 2013-06-21 2016-02-10 北京邮电大学 一种增强可编程能力的OpenFlow网络系统和方法
US9253086B2 (en) * 2013-07-09 2016-02-02 Telefonaktiebolaget L M Ericsson (Publ) Method and system of dynamic next-hop routing
US9769066B2 (en) * 2013-07-16 2017-09-19 Futurewei Technologies, Inc. Establishing and protecting label switched paths across topology-transparent zones
CN103346922B (zh) * 2013-07-26 2016-08-10 电子科技大学 基于sdn的确定网络状态的控制器及其确定方法
US9832102B2 (en) * 2013-08-07 2017-11-28 Telefonaktiebolaget L M Ericsson (Publ) Automatic establishment of redundant paths with cautious restoration in a packet network
US9843504B2 (en) * 2013-08-09 2017-12-12 Futurewei Technologies, Inc. Extending OpenFlow to support packet encapsulation for transport over software-defined networks
US9325609B2 (en) * 2013-08-23 2016-04-26 Futurewei Technologies, Inc. Segmented source routing in a network
US9571384B2 (en) * 2013-08-30 2017-02-14 Futurewei Technologies, Inc. Dynamic priority queue mapping for QoS routing in software defined networks
US9137140B2 (en) * 2013-09-10 2015-09-15 Cisco Technology, Inc. Auto tunneling in software defined network for seamless roaming
US9906439B2 (en) * 2013-11-01 2018-02-27 Futurewei Technologies, Inc. Ad-hoc on-demand routing through central control
US9407541B2 (en) * 2014-04-24 2016-08-02 International Business Machines Corporation Propagating a flow policy by control packet in a software defined network (SDN) based network
US9980179B2 (en) * 2014-05-15 2018-05-22 Cisco Technology, Inc. Managing computational resources in a network environment
US9479443B2 (en) * 2014-05-16 2016-10-25 Cisco Technology, Inc. System and method for transporting information to services in a network environment
CA2963580C (en) 2014-12-17 2020-04-21 Huawei Technologies Co., Ltd. Data forwarding method, device, and system in software-defined networking
US10069722B2 (en) * 2015-09-03 2018-09-04 International Business Machines Corporation Application information based network route modification

Also Published As

Publication number Publication date
JP2017163591A (ja) 2017-09-14
JP6500304B2 (ja) 2019-04-17
AU2014339535C1 (en) 2018-01-18
KR20170010452A (ko) 2017-01-31
WO2015058597A1 (zh) 2015-04-30
KR101700238B1 (ko) 2017-01-26
EP3062468A1 (en) 2016-08-31
KR101776650B1 (ko) 2017-09-08
JP2016538768A (ja) 2016-12-08
CN108183861A (zh) 2018-06-19
US10367718B2 (en) 2019-07-30
US20170346716A1 (en) 2017-11-30
CN104579968A (zh) 2015-04-29
CN108183861B (zh) 2021-09-07
US20160241459A1 (en) 2016-08-18
AU2014339535B2 (en) 2017-08-10
AU2014339535A1 (en) 2016-05-19
EP3062468B1 (en) 2021-03-31
KR20160073403A (ko) 2016-06-24
EP3062468A4 (en) 2016-11-02
CN104579968B (zh) 2018-03-09
US9742656B2 (en) 2017-08-22

Similar Documents

Publication Publication Date Title
JP6500304B2 (ja) Ｓｄｎスイッチにより正確なフロー・エントリを獲得するための方法、およびｓｄｎスイッチ、コントローラ、およびシステム
WO2018000443A1 (zh) 基于业务功能链sfc的报文转发方法、装置和系统
US20200396162A1 (en) Service function chain sfc-based communication method, and apparatus
US10009267B2 (en) Method and system for controlling an underlying physical network by a software defined network
US8730809B2 (en) Methods for packet forwarding through a communication link of a distributed link aggregation group using mesh tagging
US9548930B1 (en) Method for improving link selection at the borders of SDN and traditional networks
WO2014047784A1 (zh) 报文转发路径确定方法及网络设备、控制设备
US20230291682A1 (en) Method and device for processing data packet, storage medium, and electronic device
CN114422415B (zh) 在分段路由中的出口节点处理流
EP3032782B1 (en) Packet transmission method and apparatus
WO2012081721A1 (ja) 通信システム、ノード、パケット転送方法およびプログラム
WO2024001820A1 (zh) 一种数据传输方法及网关设备
WO2015045275A1 (ja) 制御装置、ネットワークシステム、パケット転送制御方法、制御装置用プログラム
US20230216785A1 (en) Source routing apparatus and method in icn
WO2023082706A1 (zh) 一种处理报文的系统、方法和网络装置
US20160036699A1 (en) Increased Network Scalability by Router Aware Switches
Nakamura et al. ovstack: A protocol stack of common data plane for overlay networks
WO2012064175A1 (en) A method to optimize path management in virtual machine environment

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161011

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161215

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170124

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170330

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: 20170411

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170511

R150 Certificate of patent or registration of utility model

Ref document number: 6144834

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250