JP5935913B2 - 通信システム、転送ノード、経路管理サーバおよび通信方法 - Google Patents

通信システム、転送ノード、経路管理サーバおよび通信方法 Download PDF

Info

Publication number
JP5935913B2
JP5935913B2 JP2015030198A JP2015030198A JP5935913B2 JP 5935913 B2 JP5935913 B2 JP 5935913B2 JP 2015030198 A JP2015030198 A JP 2015030198A JP 2015030198 A JP2015030198 A JP 2015030198A JP 5935913 B2 JP5935913 B2 JP 5935913B2
Authority
JP
Japan
Prior art keywords
transfer
route
information
packet
forwarding
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
JP2015030198A
Other languages
English (en)
Other versions
JP2015128304A (ja
Inventor
潤 粟野
潤 粟野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2015030198A priority Critical patent/JP5935913B2/ja
Publication of JP2015128304A publication Critical patent/JP2015128304A/ja
Application granted granted Critical
Publication of JP5935913B2 publication Critical patent/JP5935913B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/42Centralised routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/34Source routing

Landscapes

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

Description

[関連出願についての記載]
本発明は、日本国特許出願:特願2010−002875号(2010年01月08日出願)の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信システム、転送ノード、経路管理サーバおよび通信方法に関し、特に、ネットワークに配置された転送ノードによりパケットを転送して通信を実現する通信システム、転送ノード、経路管理サーバおよび通信方法に関する。
図30にIP(Internet Protocol)を使ったネットワーク構成を示す。図30において、通信ノード100(通信ノード100aおよび通信ノード100b)は、IPを使って通信を行う通信ノードである。転送ノード200は、通信ノード100が送信したIPパケットを受信した際に、前記IPパケットの転送先を決定し、決定された転送先に転送する。転送ノードは、これを繰り返し、最終的に宛先とする通信ノードにIPパケットを転送する。
前記IPパケットの転送先の決定には、転送ノード200が内部に保持するルーティングテーブルが使用される。ルーティングテーブルとは、どのネットワーク宛のパケットを、どのインタフェースを介して次の転送処理を担う転送ノードに送れば良いかを示すテーブルであり、宛先ネットワークアドレス、次の転送先のIPアドレス、送信先とするインタフェースの対応を1つのエントリとして、これを列挙したテーブルである。エントリには前述した情報以外の情報も含むが、ここでは簡単のため省略する。
前記ネットワークアドレスとは、IPアドレスの内、上位から一部のビット数を抜き出したアドレスであり、例えば、192.168.1.0/24といった形式で表現される。この場合、アドレスの上位24bitがネットワークアドレスであり、当該ネットワークには、192.168.1.1から192.168.1.255までのアドレスが含まれる。このとき、24をプレフィクス長と呼ぶ。
転送ノード200は、ルーティングテーブルから適切なルート情報を決定する際に、ロンゲストマッチという方法を使用する。これは、IPパケットの宛先アドレスとルーティングテーブルの個々のエントリを比較し、前記宛先アドレスの上位ビットから、より長いビット数が一致したものに決定するという方法である。
前記ルーティングテーブルは、転送ノード200に手動などの方法により事前に設定するか、ルーティングプロトコルと呼ばれるルート情報を交換するプロトコルにより自動的に設定される。
IPネットワークでは、以上の転送方式によりパケットを転送するが、この場合パケットの転送は、個々の転送ノードのルーティングテーブルに依存し、経路を完全には制御できないという問題点がある。また、宛先アドレスのみで転送先を決定するので、送信元アドレスや、どのアプリケーションによる通信か、といった違いによる緻密な経路制御ができないという問題点もある。
上記経路制御を行う方式として、ソースルーティングという手法が存在する。ソースルーティングとは、送信元となるノード(例えば、通信ノード100a)が、転送経路としたい転送ノード200のアドレスを送信パケット中に明示的に列挙する方法である。この場合、通信ノード100aは使用するアプリケーションなどにより意図した転送経路で宛先とするノード(例えば、通信ノード100b)にパケットを転送することができる。
また、MPLS(Multi−Protocol Label Switching)というパケット転送技術にも、ソースルーティングに相当する技術が存在する。MPLSは、受信したパケットに対してラベルを付与し、ラベルに基づいて転送処理を行う技術である。
前記ラベルの付与は、パケットがMPLSネットワークの境界に配置された転送ノードに入力された後、当該パケットを転送する際に実施され、以降MPLSネットワーク内の転送ノードは、当該パケット転送するたびラベルを貼り替えながら、転送処理を繰り返す。そして、MPLSネットワークの境界に配置された転送ノードにより外部のネットワークへ転送される際に、当該転送ノードによりラベルが除去される。
MPLSにおける、ソースルーティングに相当する技術とは、CR−LDP(Constraint Routing−Label Distribution Protocol)である。LDPは、MPLSネットワーク内の転送ノード間で前記ラベルを交換するためのプロトコルであるが、トラフィック・エンジニアリングなどの目的で、パケットの転送経路を厳密に指定することを目的としたLDPがCR−LDPである。
特許文献1には、上記ソースルーティング技術において、ルーティングヘッダ中に並列に位置する複数の中継ノードを格納し、中継ノードが所定のポリシーに基づいて、前記並列に位置する複数の中継ノードの中から一の中継ノードを選択するようにしたパケット通信方法が開示されている。
また同じく経路制御を行うものとして、非特許文献1、2にオープンフロー(OpenFlow)という技術が提案されている。オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。転送ノードとして機能するオープンフロースイッチは、オープンフローコントローラとの通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。フローテーブルには、フロー毎に、パケットヘッダと照合するルールと、処理内容を定義したアクションと、フロー統計情報との組が定義される。
例えば、オープンフロースイッチは、最初のパケット(first packet)を受信すると、フローテーブルから、受信パケットのヘッダ情報に適合するルール(FlowKey)を持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、受信パケットに対して、当該エントリのアクションフィールドに記述された処理内容を実施する。一方、前記検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対して受信パケットを転送し、受信パケットの送信元・送信先に基づいたパケットの経路の決定を依頼し、これを実現するフローエントリを受け取ってフローテーブルを更新する。
特開2004−153318号公報
Nick McKeownほか7名、"OpenFlow: Enabling Innovation in Campus Networks"、[online]、[平成21年12月14日検索]、インターネット〈URL:http://www.openflowswitch.org//documents/openflow−wp−latest.pdf〉 "OpenFlow Switch Specification" Version 0.9.0. (Wire Protocol 0x98) [平成21年12月14日検索] 、インターネット〈URL:http://www.openflowswitch.org/documents/openflow−spec−v0.9.0.pdf〉
上記特許文献1及び非特許文献1〜2の全開示内容はその引用をもって本書に繰込み記載する。
以下の分析は、本発明によってなされたものである。
IP技術に基づく転送ノード、すなわちスイッチやルータが保持するルーティングテーブルは増大の一途をたどり、ルート情報の爆発と呼ばれる問題が指摘されている。ルート増大の結果、ルーティングテーブルを保持するためのメモリの必要量が増えるとともに、ルート決定処理に時間がかかるため、パケット転送処理能力が劣化する。
MPLSは、IPルーティングと比してルート決定時間が削減できるものの、多様な転送ポリシを適用すれば、やはりルーティングテーブルのエントリ数は増大し、処理性能の劣化につながる。
以上のように、ルーティングテーブルのエントリ数の抑制は、メモリ削減や処理能力向上の観点で転送ノードの重要な課題となっている。
一方、上記したソースルーティングでは、パケット中に転送ノード100のアドレスを格納するため、パケットが含むことができる正味のデータ量が小さくなってしまうという問題点がある。このため、ソースルーティングは、ネットワークの試験など一部の用途に限られ、アプリケーションなどの通信で使われるパケット(これを以降「データパケット」と呼称する。)には使用されない。なお、正味のデータ以外の情報をオーバヘッドと呼ぶ。すなわち、前述の問題は、オーバヘッドが大きくなる問題と言い換えられる。
また、CR−LDPで使われるパケット中には、前述のIPルーティングにおけるソースルーティングと同様に、転送毎(1ホップ毎)の転送ノードの情報が含まれる。転送ノードの情報としては、例えばIPv4アドレスやIPv6アドレスが使われるが、この場合も転送経路中のすべての転送ノードの情報を列挙する場合は当該情報が大きくなるため、制御用パケット以外に用いるのは現実的ではない。結果として、データパケットの転送経路を厳密に決定する際には、前記CR−LDPなどで、転送ポリシごとの転送情報を転送ノード内に設定する必要が生じる。
特許文献1の方法も、上記したソースルーティングそのものであり、パケットが含むことができる正味のデータ量が小さくなってしまうという問題点がある。
また、非特許文献1、2の方法は、冒頭に述べたルーティングテーブルを参照する方式と同様に、個々の転送ノードが、フローテーブルを参照する必要があり、エントリの増大に従って、レイテンシ(遅延時間)の発生やノードへの負荷が掛かってしまうことが考えられる。
以上説明したように、ルーティングテーブルやフローテーブルに様々な転送ポリシごとのエントリを追加する方式は、エントリの追加・更新・削除の処理負荷と、ルーティングテーブルの情報量が増大するという問題点があり、転送経路を明示的に指定するソースルーティング等は、オーバヘッドが大きくなり、データパケットの送信には適さないという問題点がある。
本発明は、上記した事情に鑑みてなされたものであって、その目的とするところは、簡略化された転送テーブルを用いて実現可能であり、しかも、データパケットの経路制御、とりわけ、転送経路上の障害発生状況やトラフィックの負荷状況に応じて、代替経路への切替を可能とする通信システム、転送ノード、経路管理サーバ、通信方法およびプログラムを提供することにある。
本発明の第1の視点によれば、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースを識別するための識別子を並べることによって構成された複数の転送経路情報を送信する経路管理サーバと、前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択し、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行する転送ノードと、を含通信システムが提供される。
本発明の第2の視点によれば、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースを識別するための識別子を並べることによって構成された複数の転送経路情報を送信する経路管理サーバと接続され、前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットの転送処理を実行する転送ノードであって、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択し、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行する転送ノードが提供される。
本発明の第3の視点によれば、データ転送ネットワークの転送経路上の所定の転送ノードからの要求に応じて、前記転送経路上の個々の転送ノードに備えられている通信インタフェースを識別するための識別子を並べることによって構成された複数の転送経路情報を構成し、送信する経路管理サーバであって、前記複数の転送経路情報を格納したヘッダが付加されたパケットを受信した転送ノードに、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択させ、かつ、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行させる経路管理サーバが提供される。
本発明の第4の視点によれば、データ転送ネットワークの経路管理サーバが、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースを識別するための識別子を並べることによって構成された複数の転送経路情報を送信するステップと、前記転送経路上の転送ノードが、前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択し、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行するステップと、を含む通信方法が提供される。本方法は、上記した転送ノードおよび経路管理サーバという、特定の機械に結びつけられている。
本発明の第5の視点によれば、上記した通信システム、転送ノード、経路管理サーバ及び通信方法において、データ転送ネットワークの転送経路上の個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された転送経路情報を用いる構成が提供される。
本発明によれば、正味のデータ量の圧迫や、経路上にある転送ノードへの負荷増大の少ない、代替経路への切替の可能な経路制御が可能となる。その理由は、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報をヘッダに付加し、転送ノードに転送経路情報を解釈・実行させていく構成を採用したことにある。
本発明の第1の実施形態に係る通信システムを示す図である。 本発明の第1の実施形態に係る通信システムの境界転送ノードの構成を示す図である。 本発明の第1の実施形態の境界転送ノードおよび内部転送ノードの記録部に記録される転送テーブルを示す図である。 パケットへの経路情報ヘッダ、代替経路開始位置情報ヘッダおよび代替経路情報ヘッダの付与形態の一例を示す図である。 境界転送ノードにて付加される経路情報ヘッダのフォーマットの例である。 図5の経路転送ヘッダ中のローカルIDのフォーマット(拡張なしの例)を示す図である。 図5の経路転送ヘッダ中のローカルIDのフォーマット(拡張ありの例)を示す図である。 境界転送ノードにて付加される代替経路開始位置情報ヘッダのフォーマットの例である。 境界転送ノードにて付加される代替経路情報ヘッダのフォーマットの例である。 本発明の第1の実施形態に係る通信システムの内部転送ノードの構成を示す図である。 本発明の第1の実施形態に係る通信システムの経路管理サーバの構成を示す図である。 各転送ノードから通知される近隣情報を示す図である。 図12の近隣情報から構築したネットワークトポロジの例である。 境界転送ノードがパケットを受信した際の動作を示すフローチャートである。 図14の転送処理の詳細を示すフローチャートである。 図15の代替経路転送判定処理の詳細を示すフローチャートである。 内部転送ノードがパケットを受信した際の動作を示すフローチャートである。 境界転送ノードおよび内部転送ノードが近隣情報通知を送信する動作を示すフローチャートである。 経路管理サーバが近隣情報通知を受信した際の動作を示すフローチャートである。 経路管理サーバが経路情報を要求された際の動作を示すフローチャートである。 本発明の第1の実施形態の通信ノードが、パケットを対向の通信ノードに送信した際のパケット転送の流れを示すシーケンス図である。 本発明の第1の実施形態の通信ノードが、パケットを対向の通信ノードに送信した際のパケット転送の流れ(1回の転送失敗有り)を示すシーケンス図である。 本発明の第1の実施形態の通信ノードが、パケットを対向の通信ノードに送信した際のパケット転送の流れ(2回の転送失敗有り)を示すシーケンス図である。 本発明の第2の実施形態に係る通信システムの境界転送ノードの構成を示す図である。 本発明の第2の実施形態の境界転送ノードの記録部に記録される転送失敗経路情報テーブルの例を示す図である。 本発明の第2の実施形態の境界転送ノードで付加される経路転送ヘッダ中のローカルIDのフォーマット(拡張なしの例)を示す図である。 本発明の第2の実施形態に係る通信システムの内部転送ノードの構成を示す図である。 本発明の第2の実施形態における代替経路転送判定処理の詳細を示すフローチャートである。 本発明の第2の実施形態の通信ノードが、パケットを対向の通信ノードに送信した際のパケット転送の流れを示すシーケンス図である。 背景技術として説明する、パケット転送を行う通信システムを示す図である。
はじめに、本発明の概要を説明する。本発明の通信システムの転送ノードは、受信パケットに、複数の転送経路情報が含まれるヘッダが付与されている場合、これら複数の転送経路情報のうち、いずれかを選択して転送処理を実施する。
ここで、前記転送経路情報は、データ転送ネットワーク上の個々の転送ノードが、転送先とする通信インタフェースを識別可能な識別子を転送順に並べたものとすることができる。前記識別子は、各転送ノード内で、転送先の一意性を確保するに足る長さがあればよい。
転送ノードが備えるインタフェースの数はIPアドレス等に比べてはるかに少ない。冒頭に述べたソースルーティングと異なり、本発明の転送経路情報を構成する識別子は、例えば1バイト長などの短い情報で記述することが可能となるため、正味のデータ量に与える影響は軽微である。従って、一部の制御用パケットのみならず、データパケットなど、すべてのパケットに対して、転送経路を1ホップ毎に記述した情報を格納することが可能となり、高度な転送制御が可能となる。
さらに、個々の転送ノードは、前記識別子と、転送先の通信インタフェースとの対応関係を保持すればよく、膨大な数となる冒頭に述べたルーティングテーブル等の転送テーブルを保持する必要はないため、メモリ量を削減できる。また、転送先の決定も、簡単かつ高速に行えるため、パケットの転送遅延も小さくすることが可能となる。さらに、個々の転送ノードのCPUの処理能力も低くて済む。
なお、上記複数の転送経路情報を含んだヘッダの付加および削除は、転送ノードのうち、外部ネットワークとの境界に配置された転送ノード(境界転送ノード)に次のように実行させればよい。外部ネットワークからパケットを受信した境界転送ノードは、当該パケットの転送経路を、別途設けられた経路管理サーバまたは当該境界転送ノード内に記録された情報から取得し、複数の転送経路情報を格納したヘッダを受信したパケットに付与する。また、境界転送ノードは、外部ネットワークにパケットを送信する場合、前記ヘッダを削除する。
前記複数の転送経路情報のうち、どの転送経路情報を使用するかは、個々の転送ノードに判断させても良いが、転送経路情報の格納順序や別途優先順位情報を付加することにより、優先順位を付けることも可能である。
本発明において以下の形態が可能である。
[形態1]
データ転送ネットワークの転送ノードが、パケットの転送経路を一意に指定可能な情報を含む転送経路情報を複数格納したパケットを、前記複数の転送経路情報のいずれかを使って転送処理を行う通信システム、即ち、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を構成する経路管理サーバと、前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報のいずれかに従ってパケット転送処理を実行する転送ノードを含む通信システム。
[形態2]
前記パケットは、前記複数の転送経路情報のうちのどの転送経路情報を使うかを示す経路選択情報を格納可能であり、
前記転送ノードは、前記経路選択情報を参照して、前記パケット転送処理に用いる転送経路情報を決定することが好ましい。
[形態3]
前記複数の転送経路情報には、1つの転送経路から、別の転送経路へと分岐可能な転送ノードを判別するための情報が含まれており、
前記分岐可能な位置の転送ノードが、前記複数の転送経路情報のいずれかを選択することが好ましい。
[形態4]
前記パケットは、転送ノードが前記経路選択情報により決定された転送経路情報に基づき転送処理を行った際の転送結果を示す転送結果情報を格納可能であり、
前記転送ノードは、転送処理の結果により更新される前記転送結果情報を参照して、転送に失敗していない転送経路情報を選択することが好ましい。
[形態5]
前記パケットは、当該パケットを受信した転送ノードまで至る転送経路上における現在の転送経路から異なる転送経路へと分岐可能な転送ノードの数を示す分岐点情報を格納可能であり、
前記転送ノードは、転送処理に失敗した場合前記分岐点情報を減らし、前記分岐点情報を用いて当該パケットを破棄するか否かを決定することが好ましい。
[形態6]
前記パケットは、転送経路を変更した際に、変更前の転送経路情報を特定可能な情報を格納可能であり、
前記転送ノードは、前記パケットに含まれる変更前の転送経路情報を用いて、変更前の転送経路への復帰処理を行い、さらなる分岐先を探索することが好ましい。
[形態7]
前記転送ノードは、さらに、
転送失敗が発生した転送経路情報を記録する転送結果記録部を備え、
パケットを受信した際に、当該パケットに格納された転送経路情報と前記記録された転送失敗が発生した経路情報とを比較し、その結果、転送失敗が予測される場合、別の転送経路に切りかえることが好ましい。
[形態8]
データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を構成する経路管理サーバと接続され、前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報のいずれかを使ってパケット転送処理を実行する転送ノード。
[形態9]
上記した転送ノードからの経路要求を受信した際に、前記経路要求に含まれる情報に基づき、前記パケットを通信相手まで到達させ得る複数の転送経路情報を応答する経路管理サーバ。
[形態10]
データ転送ネットワークの経路管理サーバが、転送ノードからの経路要求を受信した際に、前記経路要求に含まれる情報に基づき、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースまたは前記個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を応答するステップと、前記経路管理サーバから取得した前記転送ノードを含む前記複数の転送経路情報のいずれかから選択された転送経路上の転送ノード群が、前記選択された転送経路情報を使って順次前記パケットを転送するステップと、を含む通信方法。
[形態11]
上記した転送ノード、経路管理サーバを構成するコンピュータに実行させるプログラム。
なお、上記形態8〜形態11に記載の転送ノード、経路管理サーバ、通信方法およびプログラムは、形態1の通信システムと同様に、それぞれの構成要素ないしステップについて、形態2〜形態7の内容に展開することが可能である。
以下の実施形態では、優先順位が2位以下の転送経路を、「代替転送経路」とする。このような代替転送経路は、ある転送経路を用いた転送に失敗したときに使用する。例えば、あるパケットの転送処理に失敗した場合、転送に失敗したパケット内部の転送経路情報に基づき、転送経路を逆方向に転送し、境界転送ノードまたは複数の転送経路上の分岐点となる転送ノードに到達させ、代替転送経路を用いた再送を行わせることができる。また、前記複数の転送経路情報に、このような代替経路の存在を示すヘッダ(後記する代替経路開始位置ヘッダはその一例である。)や、前記分岐点の有無(後記する経路情報ヘッダ内の‘Ex’フィールドはその一例である。)、転送結果を示す情報(後記する経路情報ヘッダ内の‘F’フィールドはその一例である。)、次に使用すべき代替経路の識別情報(後記する経路情報ヘッダ内の‘Alt’フィールドの値にインクリメントまたはデクリメントする。)、あるいは、データ転送ネットワークの状態(転送先のノードの故障・負荷増大、トラヒック状況等)などを経路選択情報として用いる構成も採用可能である。
[第1の実施形態]
続いて、本発明の第1の実施形態について図面を参照して詳細に説明する。図1は、本発明の第1の実施形態に係る通信システムを示す図である。図1を参照すると、通信ノード100a、100bと、境界転送ノード300a、300bと、内部転送ノード400と、経路管理サーバ500とが示されている。
データ転送ネットワーク600は、本発明の方式によりパケットの転送処理を行うネットワークであり、外部ネットワーク700は、IPネットワークなどのように、ネットワーク600とは異なる方式によりパケット転送処理を実施するネットワークである。ただし、ネットワーク600と同様の転送方式を使っている場合も、管理者が異なる場合は外部ネットワーク700となり得る。ここでは外部ネットワーク700は、IPネットワークとした説明を行う。外部ネットワーク700は、データ転送ネットワーク600と、境界転送ノード300a、300bを介して接続される。
通信ノード100a、100bは、それぞれ外部ネットワーク700に属する通信ノードであり、外部ネットワーク700のパケット転送方式に沿ったパケットの送受信を行う。つまり、本実施形態においてはIPパケットの送受信を行うノードである。通信ノード100a、100bは、一般的なIPノードと同様であるので詳細な説明は省略する。
境界転送ノード300a、300bは、データ転送ネットワーク600と外部ネットワーク700との間に配置され、通信ノード100a、100bから送信されたパケットを受信した場合には、後述の転送経路情報や代替転送経路情報を格納するヘッダを付与し、さらにヘッダ中のこれら複数の転送経路情報に基づきデータ転送ネットワーク600内の内部転送ノード400に当該パケットを転送する。
また、境界転送ノード300a、300bは、内部転送ノード400から転送経路情報等を格納したヘッダが付与されたパケットを受信した場合であってそのヘッダ中の転送経路情報または代替転送経路情報から転送経路上の最後のノードであると判定した場合、受信したパケットから前記経路情報ヘッダを削除し、その後、外部ネットワーク700の通信ノード100a、100b側にパケットを送信する。
なお、以下の説明では、転送経路情報は、経路管理サーバ500から取得するものとして説明するが、これに拘らず、境界転送ノード300内に保持した情報により転送経路情報を生成しても良い。
以下、本実施形態の境界転送ノード300a(300b)、内部転送ノード400、経路監視サーバ500の順に、その構成を説明する。
図2は、図1の境界転送ノード300a、300bの構成を示す図である。図2に示すとおり、境界転送ノード300は、通信インタフェース310と、パケット転送部320と、ヘッダ操作部330と、ローカルID決定部340と、近隣情報通知部350と、経路取得部360と、代替経路移行部370と、転送結果記録部380と、記録部390とを備えて構成される。
通信インタフェース310は、パケットの送受信を行うためのインタフェースであり、例えばLANカードのようなNetwork Interface Card(NIC)と、それを動作させるソフトウェア(ドライバ)により実現される。ただし、前記のような物理的なインタフェースのみならず、論理的なインタフェースであっても良い。この場合、物理的なインタフェース1つを使って、複数のインタフェースを備えているように動作させることができる。
境界転送ノード300は、上記のような1つ以上の物理インタフェース、あるいは論理インタフェースを備える。各々の通信インタフェース310は、データ転送ネットワーク内の内部転送ノード400や他の境界転送ノード300と接続される。また、一部の通信インタフェース310は、外部ネットワーク700の通信ノード100とも接続される。さらに、一部の通信インタフェース310は、経路管理サーバ500とも接続される。経路管理サーバ500は、データ転送ネットワーク600内に配置していても構わないし、経路管理サーバ500専用のネットワークを介して接続することとしても構わない。
パケット転送部320は、受信パケットに転送経路情報等を格納したヘッダが付与されていた場合、まず代替経路移行部370(詳細は後述)にて代替経路へ移行するかどうかの判定と、移行する場合はそのための準備を終えた後、前記ヘッダ内の転送経路情報または代替転送経路情報と、記録部390に記録された情報に基づき、パケットを転送する機能を備える。
記録部390には、後に図3を用いて説明するとおり、ローカルIDと、転送先とする通信インタフェースと、当該通信インタフェース310と接続している近隣の境界転送ノード300、あるいは内部転送ノード400の識別子の対応情報を1つのエントリとした転送テーブルが記録されている。パケット転送部320は、前記ローカルIDに対応する次ノードにパケットを転送することができる。
なお、以降では、境界転送ノード300と内部転送ノード400の総称を転送ノードとする。また、直接接続しているノード(通信ノード100、境界転送ノード300、内部転送ノード400)同士を近隣ノードと呼称する。
図3は、境界転送ノード300および内部転送ノード400の記録装置(記録部390または後記記録部470に相当。)に記録される転送テーブルの例である。本実施形態では、図3に示すとおり、ローカルIDとして、隣接する転送ノード間あるいは境界転送ノード300と通信ノード100a(100b)間の、物理リンクあるいは論理リンクに割当てた識別子(リンクID)を使用する。したがって、「ローカルID」のフィールドには前記リンクIDが設定される。転送先とする通信インタフェースを示す「インタフェース」のフィールドには、リンクIDが割当てられたリンクに接続した通信インタフェース310を識別する情報が設定される。また、図3の例では、近隣ノードの情報を示す「次ホップ」のフィールドに、前記リンクに接続された転送ノードの識別子が設定されている。
なお、転送先とする通信インフェースがIPにより通信を行う通信ノード100a(100b)と接続されていた場合は、「次ホップ」のフィールドの識別子として、例えば、通信ノード100a(100b)のIPアドレスを使用できる。一方、境界転送ノード300、あるいは内部転送ノード400の場合は、一意に割当てた識別子(例えば、図3のNode_1、Node_2等)を使用する。前記転送ノードの識別子は、事前に設定することとしても良いし、経路管理サーバ500など、外部のノードから設定する方式としても構わない。さらに、前記「次ホップ」フィールドの識別子は、転送処理に必ず必要なわけではなく、省略することもできる。
また、ローカルIDとして、通信インタフェース310を識別する情報そのものを使うこともできる。通信インタフェース310を識別する情報は、短い情報量(例えば、1〜2バイト程度)で記述できる情報であることが望ましいため、通信インタフェース310を識別する情報が長い場合(例えば、通信インタフェースの名前などを使う場合)は、1バイトなど短い情報で記述できる別の識別子を別途割り振った上でローカルIDとして適用する。ただし、ここでは特に説明しない場合、ローカルIDとしてリンクIDを使用するものとして説明する。
一般的なレイヤ3で転送処理を行うルータやL3スイッチ、また、レイヤ2での転送処理を行うL2スイッチが備えている通信インタフェースは基本的に数十個程度であるため、リンクの識別子や通信インタフェースの識別子は、1バイトで十分表現できる。実際の通信インタフェースの識別子が数バイトを要するような長い情報である場合は、1バイト、あるいは2バイトに格納可能な範囲とした識別子を別途作成し、通信インタフェースの識別子に対応づければよい。
なお、図3の転送テーブルは、本発明を端的に説明するために例示したものであり、個々のエントリに、他の情報をさらに対応づけて記録することとしても構わない。
図4は、境界転送ノード300によるパケットへの経路情報ヘッダ、代替経路開始位置情報ヘッダおよび代替経路情報ヘッダの付与形態の一例を示す図である。図4の例では、経路情報ヘッダは、パケットの先頭部分に付与される。さらに、代替経路情報を含める場合は、経路情報ヘッダ、代替経路開始位置情報ヘッダ(後に詳述する。)、代替経路情報ヘッダの順で付与される。代替経路情報ヘッダは複数付与することが可能であり、複数付与する場合は最初の代替経路情報ヘッダに続けて、次の代替経路情報ヘッダを配置する。
代替経路情報ヘッダの数に制限はないが、先に述べた正味のデータ量の圧迫を回避することが本発明の目的の一つであるから、代替経路情報ヘッダの数に上限を設けることも望ましい。以下、本実施形態では、最大3個の代替経路情報ヘッダを付加できるものとして説明する。
図5は、本実施形態で用いる経路情報ヘッダのフォーマットの1例である。図5において、‘D’(=Direction)は転送方向を示す。例えば、‘0’なら順方向の転送を示し、‘1’なら逆方向の転送を示す。‘Alt’(=Alternate Route Number)は転送時に参照している代替経路情報を示す値が設定される。本実施形態では、‘Alt’は2bitなので、設定値は0〜3となる。‘Alt’が0のときは代替経路を使わず、‘Local ID#n’以降の経路情報を参照して転送処理を行う。一方、‘Alt’が1〜3の場合は、それぞれの値に対応した代替経路情報ヘッダに記載された代替経路を参照して転送処理を行うことを示す。代替経路情報ヘッダについては後に詳細に説明する。
図5の‘Ex’(=Alternate Route Existence)は、現在当該パケットの転送処理を行おうとしている転送経路における代替経路への分岐点の数を示す。転送ノードは、当該パケットの転送にあたり、自ノードから代替経路に分岐可能な場合は、‘Ex’フィールドをインクリメントする。したがって、現在転送処理を実施する転送ノードまでに代替経路が無い場合は、当該値は‘0’となる。代替経路がある場合は、存在した代替経路への分岐点の数が設定されていることになる。‘Ex’は、代替経路に移行する場合にデクリメントされる。
‘F’(Failure Flag)は、転送ノードが何らかの理由により次ホップとなる転送ノードへの転送処理に失敗した場合、‘1’に設定される。
‘Rsv’(Reserved)は予約フィールドであり、本発明の実施形態では使用しない。したがって、0などの固定値が設定される。
‘Current Offset’は、転送時に参照すべきローカルID情報のオフセット情報が設定される(単位はバイト)。この値は、‘LocalID #0’からのオフセットバイト数で示される。境界転送ノード300で経路情報ヘッダを付与する際には、‘Current Offset’の値は‘0’に設定される。
‘Header Length’は、‘Route Length’以降のヘッダの長さをバイト数で示す。本実施形態では、パケットの整形(アライメント)を考慮し、4バイト単位の値とする。正味のデータの終わりが4バイト単位の境界に合わない場合は、スタッフィング(パディング)を行う(0を設定したダミーの情報を後置する。)。
‘Route Length’は、後に続くローカルIDの列挙により示された経路情報の合計バイト数を示す。
‘Local ID#n’は、nホップ目の境界転送ノード300あるいは内部転送ノード400が転送先として参照すべきローカルIDが設定される。上記図5のフォーマットはあくまで一例であり、種々の変形フォーマットで情報を格納したとしても構わない。
上記のように、転送経路の情報として、転送ノード内、あるいは、隣接する転送ノード間といった局所的な範囲において一意となるローカルIDを用いることで、経路情報ヘッダの情報量を削減できる。
なお、本実施形態では、各々のローカルIDは1バイトとしたが、論理的なリンクでは1バイトでは表現できない可能性がある。また、代替経路に関わる情報(優先順位や選択条件など)を個々の経路情報に設定する場合も1バイトでは不足すると考えられる。
この場合は、図6に示すように、‘LocalID#n’の最上位bitを、ローカルIDが1バイト表記か2バイト表記かを示すローカルID拡張フラグ(‘E’(Extension)ビット)として使用しても良い。この場合、最上位ビットが0の場合、転送ノードは、ローカルIDを1バイトの識別子と解釈し、最上位ビットが1の場合、ローカルIDを2バイトの識別子として解釈することになる。
図6は、ローカルID拡張フラグ(‘E’)が‘0’の場合のローカルIDを示す図である。図7は、ローカルID拡張フラグ(‘E’)が‘1’の場合のローカルIDを示す図であり、1ホップあたりの経路情報長は2バイトとなる。なお、ローカルIDの長さとして、1バイトまたは2バイトを選択できるものとして説明したが、なるべく短いビット長で1ホップあたりの経路を記述することが重要なのであって、厳密に1バイト、2バイトである必要はなく、1バイト未満の固定長としたり、適当なデリミタ文字で区切られた任意の可変長とすることも可能である。
なお、図7の‘Alt’(=Alternative Route)は、当該ローカルIDを参照する転送ノードから分岐可能な代替経路の存在の有無と、代替経路に分岐する場合に参照すべき代替経路情報ヘッダを指定する値が設定される。具体的には、‘Alt’が0の場合は、当該ローカルIDを参照する転送ノードから分岐する代替経路が無いことを示す。一方、‘Alt’が1〜3の場合は、前記転送ノードから分岐する代替経路があることを示し、さらにその値は、代替経路へ分岐する際に参照すべき転送情報ヘッダの番号を示す。
図7の‘U’(=Used)は、‘Alt’により示された代替経路への転送処理が実施されたことを示す。言い換えれば代替経路が使われたことを示す。転送ノードは、代替経路にパケットを転送する際に、当該ビットを‘1’に設定する。
図7の‘Local ID type2’は、図6の‘Local ID’同様、ローカルIDを設定するためのフィールドであるが、図6よりもビット長が大きいため、より多くのリンク識別子、あるいはインタフェース識別子を記述することが可能である。
次に、図4の代替経路開始位置情報ヘッダについて説明する。図8は、代替経路開始位置情報ヘッダのフォーマットの1例である。図8において、‘Reserved’は予約フィールドであり本実施の形態では使用しない。‘Offset#n’は、経路情報ヘッダの先頭バイトからn番目の代替経路情報ヘッダまでのオフセットが設定される。単位はバイトである。なお、オフセットを代替経路開始位置情報ヘッダからの先頭バイトからのオフセットとしても構わない。
次に、図4の代替経路情報ヘッダについて説明する。図9は、代替経路情報ヘッダのフォーマットの1例である。図9において、‘Frm’(=From)には当該代替経路に移行する前の経路情報の番号が設定される。‘Reserved’は予約フィールドであり本実施形態では使用しない。
上記で例示した、経路情報ヘッダ、代替経路開始位置情報ヘッダ、代替経路情報ヘッダのフォーマットや、設定される情報はあくまで一例であり、異なるフォーマットとしても良いし、各ヘッダが含む情報を他のヘッダの一部としても良いし、あるいは、別のヘッダとして格納する形態も採用可能である。
パケット転送部320は、受信パケットの経路情報ヘッダの‘Alt’フィールドを参照し、これが‘0’の場合、経路情報ヘッダを使った転送処理を行い、それ以外の場合は、代替経路情報ヘッダによる転送処理を行う。
‘Alt’が‘0’の場合、パケット転送部320は、前述のように経路情報ヘッダを参照しての転送処理を行う。より具体的には、受信パケットの経路情報ヘッダの‘D’フィールドが‘0’であった場合、すなわち順方向への転送を示していた場合、パケット転送部320は、‘Current Offset’を参照し、対応するローカルIDを参照して転送先の通信インタフェース310を決定した後、‘Current Offset’の値を参照したローカルIDの長さ分(例えば、1バイト、あるいは2バイト)増やし、前記決定した通信インタフェース310からパケットを送出する。一方、‘D’が‘1’である場合、すなわち逆方向への転送を示していた場合、パケット転送部320は、‘Current Offset’を参照し、対応するローカルIDの1つ手前のローカルIDを参照し、転送先とする通信インタフェース310を決定する。その後、‘Current Offset’の値を参照したローカルIDの長さ分減らし、決定した通信インタフェース310からパケットを送出する。
一方、‘Alt’が‘0’以外の場合、パケット転送部320は、代替経路開始位置情報ヘッダを参照し、前記‘Alt’フィールドに設定された値を代替経路の番号とみなし、対応する‘Offset#n’フィールドを読み取る。例えば、‘Alt’が‘1’の場合は、‘Offset#1’フィールドの値を読み取る。ここで読み取られた値が、経路情報ヘッダの先頭バイトから、参照すべき代替経路情報ヘッダまでのオフセットバイトとなる。したがって、パケット転送部320はオフセットバイト数で示された代替経路情報ヘッダを参照し、転送処理を実行する。代替経路情報ヘッダにより転送処理を行う場合でも、転送の制御に使われる‘D’フィールド、‘Ex’フィールド、‘F’フィールドは経路情報ヘッダのものが参照される。
代替経路情報ヘッダの‘Frm’フィールドは、当該代替経路情報ヘッダが示す代替経路に経路を移行した際に、移行元となった経路の番号が設定される。代替経路からさらに代替経路に移行することも可能であるため、移行元となる経路は、経路情報ヘッダで示される経路だけでなく、代替経路情報ヘッダで示される経路も含まれる。
パケット転送部320は、また、現在転送用に参照する経路情報ヘッダ、あるいは、代替経路情報ヘッダの‘LocalID#n’フィールドの‘Alt’フィールドが‘0’以外の場合、すなわち当該転送ノードから代替経路に分岐可能である場合、経路情報ヘッダの‘Ex’フィールドをインクリメントし、経路上に代替経路への分岐点が存在することを受信パケットに記録する機能を備える。
パケット転送部320は、さらに、当該転送ノードが代替経路への分岐点であり、前記代替経路においても転送失敗が発生して送り戻されたパケットを受信した場合、前記代替経路へ移行する前の経路に戻した上で、さらに当該パケットを逆方向に送り戻す機能を備える。具体的には、経路情報ヘッダの‘F’フィールド、‘D’フィールドが共に‘1’であり、‘Alt’フィールドが‘0’以外のパケットを受信した場合で、代替経路情報ヘッダの‘Current Offset’が0の場合、パケット転送部320は、代替経路情報ヘッダの‘Frm’フィールドの情報を経路情報ヘッダの‘Alt’フィールドにコピーする機能を備える。
ヘッダ操作部330は、外部ネットワーク700からパケットを受信した場合、経路取得部360から、当該境界転送ノード300から出口となる境界転送ノード300までの1ホップ毎の経路情報を取得し、図5に示した経路情報ヘッダと、さらに必要に応じて代替経路開始位置情報ヘッダおよび代替経路情報ヘッダを構成し、前記パケットに付与する機能を備える。例えば、ヘッダ操作部330は、経路情報ヘッダを付与する際には、‘D’フィールドには順方向への転送を意味する‘0’を設定し、同様に‘Alt’、‘Ex’、‘F’の各フィールドにも‘0’に設定する。さらに、ヘッダ操作部330は、‘Current Offset’には‘0’を、‘Local ID#n’には取得した1ホップ毎の経路情報を設定する。ヘッダ操作部330は、他のフィールドにもそれぞれ適切な値を設定する。
ヘッダ操作部330は、また、経路情報ヘッダが付与されていたパケットを外部ネットワーク700に転送する場合、経路情報ヘッダと、必要に応じて代替経路開始位置情報ヘッダおよび代替経路情報ヘッダを削除する機能を備える。
ローカルID決定部340は、当該境界転送ノード300と近隣ノードとの間で情報交換を行って、重複しないリンクIDを決定する機能を備える。例えば、以下の方法で隣接するノードとのリンクIDの重複設定を回避することができる。
まず、転送ノードは、自身が既に割当てたリンクID以外のリンクIDを設定したパケットを近隣ノードに送信することでリンクID候補を提案する。リンクIDを提案された近隣ノードは、自ノード内に重複したリンクIDがないかどうか確認し、重複するリンクIDがない場合は、提案されたリンクIDと自ノードの識別情報を設定した応答パケットを、提案元となる転送ノードに送信する。一方、近隣ノードにおいて重複するリンクIDがあった場合は、重複することを意味する情報と自ノードの識別子を設定した応答パケットを送信する。この処理を、重複するリンクIDがなくなるまで繰り返す。
このようにして決定されたリンクIDや、近隣ノードの情報は、記録部390に転送テーブルとして記録される。
以上、リンクIDの決定方法の例を示したが、他の方法でリンクIDを決定することとしても構わない。例えば、経路管理サーバ500など、他のノードが決定し、各転送ノードに通知することとしても良い。
なお、ローカルIDとして通信インタフェースの識別子を使う場合は、上記近隣ノードとのネゴシエーションを省略することができる。代わりに、前記のようにインタフェース識別子に数バイトを要するような長い情報である場合は、1バイト、あるいは2バイトに格納可能な範囲とした識別子をインタフェース識別子に対応づける処理を行う。ただし、ローカルIDとして、インタフェース識別子のように近隣ノードが知りえない情報を使い、さらに、その情報をお互い交換しないこととした場合は、前記した逆方向の転送ができなくなるため、リンク識別子のような近隣ノードと情報を共有された情報を使うことが好ましい。
近隣情報通知部350は、ローカルID決定部340によりローカルIDとして決定したリンクIDと、リンクに接続された近隣ノードの識別子と、自らの識別子と、を格納した近隣情報を経路管理サーバ500に送信する機能を備える。リンクに接続されているのが外部ネットワーク700の通信ノード100a、100bであった場合は、外部ネットワークのノードと判定できる情報も前記情報に追加する。また、経路管理サーバ500での経路計算のため、前記近隣情報には、各リンクの帯域、信頼性、混雑状況といった情報や、近隣ノードの故障情報などを含めることとしても良い。経路管理サーバ500に前記近隣情報を送信する契機は、ローカルIDの決定処理が完了したタイミングでも良いし、所定の時間間隔で送信するものとしてもよい。また、リンクの情報や、近隣ノードの故障情報も含めて送信する場合は、これらの情報に変化が生じた契機で送信しても良い。
経路取得部360は、外部ネットワーク700の通信ノード100a、100bからパケットを受信した際に、当該受信パケットの情報と、当該境界転送ノード300の識別子を格納した経路要求信号を経路管理サーバ500に送信し、当該パケットの転送経路を取得する機能を備える。前記受信パケットの情報とは、転送経路決定に影響を与えうる情報であり、最も単純な場合は、宛先アドレスのみである。しかし、より緻密な経路制御を実施する場合には、宛先アドレスに加え、送信元アドレス、当該パケットヘッダ以降に格納されたプロトコル情報、TCP(Transmission Control Protocol)あるいはUDP(User Datagram Protocol)使用時の宛先ポート番号、送信元ポート番号といった情報の一部、あるいはすべてを含めることができる。さらに、他の情報を含むこととしてもかまわない。
前記経路要求信号を送った結果、経路管理サーバ500から経路応答信号が返される。前記経路応答信号に含まれる転送経路情報には、当該境界転送ノード300を起点とした転送経路に沿って、ローカルIDを1ホップ毎に列挙した情報が格納される。代替経路が存在する場合は、代替経路情報についての情報も格納される。
なお、宛先アドレスなど、前記転送経路に影響を与えうる情報と、転送経路を示すローカルID群との対応情報は、当該境界転送ノード300に事前に設定し、予め経路管理サーバから受信しておくこともできる。この場合は、経路取得部360は、経路管理サーバ500ではなく、内部に設定された情報から転送経路情報を取得する。
また、上記の例では、当該境界転送ノード300が最初に転送先とする通信インタフェースを識別可能なローカルIDを起点としたが、前記パケットを受信した通信インタフェース310を識別可能なローカルIDを、起点としても構わない。
代替経路移行部370は、前記受信パケットを代替経路に転送すべきかどうかを判定する機能を備える。より具体的には、代替経路移行部370は、前記受信パケットが、転送に失敗した結果として送り戻されたパケットであり、さらに当該転送ノードから分岐可能な未使用の代替経路が存在する場合に、代替経路に転送すべきと判定する。すなわち、現在転送処理に使用している経路情報ヘッダの‘D’フィールド、および‘F’フィールドが共に‘1’であり、代替経路情報ヘッダ中の現在参照しているローカルIDが、さらに、‘E’フィールド=‘1’、‘Alt’フィールド=‘0’以外、‘U’フィールド=‘0’、の場合に代替経路に転送すべきと判定する。
代替経路移行部370は、また、代替経路に移行すると判定した場合、代替経路情報を使った転送に移行する処理を行う。具体的には、代替経路移行部370は、前記ローカルID中の、‘U’フィールドを‘1’に設定し、同じくローカルID中の‘Alt’フィールドの値を経路情報ヘッダ中の‘Alt’フィールドにコピーする。さらに、代替経路移行部370は、経路情報ヘッダの‘D’フィールド、‘F’フィールドを共に‘0’に設定し、また、‘Ex'フィールドをデクリメントする。
転送結果記録部380は、パケット転送処理部320により、前記受信パケットを適切な通信インタフェース310から転送した後に、リンクダウンなど、何らかの理由により転送に失敗した場合、現在の転送経路による転送が失敗したことを示す情報を当該受信パケットに記録し、さらに当該受信パケットが転送されてきた経路を辿って送り戻すための処理を行う。具体的には、転送結果記録部380は、現在転送処理用に参照している経路情報ヘッダ、あるいは代替経路情報ヘッダの‘F’フィールドを‘1’とし、さらに‘D’フィールドも‘1’に設定し、さらにパケット転送手段320に出力する。この結果、逆方向への転送処理が行われる。
記録部370は、図3に示す転送テーブルを保持し、パケット転送部320や、ローカルID決定部340や、近隣情報通知部350に、参照させる。
内部転送ノード400は、データ転送ネットワーク600内に配置され、近隣ノードから送信されたパケットを受信した場合には、パケット中の経路情報ヘッダまたは代替経路情報ヘッダの情報に基づきデータ転送ネットワーク600内の近隣ノードに当該パケットを転送する機能を備える。
図10は、図1の内部転送ノード400の構成を示す図である。内部転送ノード400は、図10に示すように、通信インタフェース410と、パケット転送部420と、近隣情報通知部430と、ローカルID決定部440と、代替経路移行部450と、転送結果記録部460と、記録部470とを備えて構成されている。
内部転送ノード400の通信インタフェース410、パケット転送部420、ローカルID決定部430、近隣情報通知部440、代替経路移行部450、転送結果記録部460および記録部470は、それぞれ、境界転送ノード300の、通信インタフェース310、パケット転送部320、ローカルID決定部340、近隣情報通知部350、代替経路移行部370と、転送結果記録部390と、記録部390と同等であるため、ここでは詳細な説明を省略する。
つまり内部転送ノード400は、境界転送ノード300から、ヘッダ操作部330と、経路取得部360を差し引いたものとみなすことができる。反対に、境界転送ノード300は、内部転送ノード400に、ヘッダ操作部330と、経路取得部360を追加した転送ノードであるということができる。
経路管理サーバ500は、境界転送ノード300と内部転送ノード400から通知された近隣情報を収集し、データ転送ネットワーク600内の境界転送ノード300および内部転送ノード400の接続関係を記述したネットワークトポロジ情報を構築する。このネットワークトポロジ情報には、境界転送ノード300に接続する通信ノード100a、100bとの接続情報も含まれる。前記通知された経路情報に、各転送ノード間のリンクや転送ノードの状態を示す情報(混雑状況、故障状況など)が含まれていた場合は、それも前記接続情報に対応づけて管理する。そして、境界転送ノード300から、転送経路情報を要求された場合には、経路要求に含まれる情報と、内部に構築したネットワークトポロジ情報を使って適切な転送経路を求める計算を実施し、経路要求を行った境界転送ノード300を起点として、外部ネットワーク700への出口となる境界転送ノード300までの転送経路を、1ホップ毎のローカルID(リンクID)を順に列挙した情報として応答する機能を備える。ここで、転送ノードの故障やリンクの断線などにより転送が失敗した場合を考慮し、経路管理サーバ500は、1つないしは複数の代替経路を算出し、算出された代替経路の情報を前記応答する情報に含めても良い。
図11は、図1の経路管理サーバ500の構成を示す図である。経路管理サーバ500は図11に示すように、通信インタフェース510と、経路情報収集部520と、経路要求処理部530と、経路計算部531と、経路情報記録部540とを備えて構成されている。
通信インタフェース510は、パケットの送受信を行うためのインタフェースである。前述のように、例えばLANカードのようなNICと、それを動作させるソフトウェア(ドライバ)により実現できる。
経路情報収集部520は、境界転送ノード300および内部転送ノード400から送られた近隣情報を受信すると、近隣情報に格納された、前記近隣情報を送信したノードの識別子、ローカルID(リンクID)、近隣ノード識別子を使って、経路情報記録部540内にデータ転送ネットワーク600内のネットワークトポロジ情報を構築する。前記近隣情報に、リンクの帯域、信頼性、混雑状況や、近隣ノードの故障情報といった付帯情報が含まれていた場合は、前記ネットワークトポロジ情報に前記付帯情報を関連づけて記録する。これらの情報は、例えば、後述する経路計算のときにリンクのコストとして使用することができる。
図12は、各転送ノードから受信した近隣情報の例である。図13は、図12の近隣情報から構築したネットワークトポロジの例である。図13の例では、簡単のため、付帯情報は省略している。また、外部ネットワークはIPネットワークであることを想定している。
図12中の‘senderID’は近隣情報を送信した転送ノードの識別子を示している。図12中の‘LinkID’は、前記転送ノードが接続するリンクに割当てたリンクIDを示している。図12中の‘neighborID’は前記リンクに接続している近隣ノードの識別子を示している。外部ネットワークはIPネットワークとの想定なので、通信ノード100の識別子としてIPアドレスを使用する。また、上述のように隣接する転送ノード間でネゴシエーションが行われているため、リンクIDは、一の転送ノードに重複して設定されないが、隣接しない転送ノード同士が同一のリンクIDを用いることは許容される。例えば、LinkID=1のリンクは、ID=1のノードと、ID=10のノード間およびID=5のノードと、ID=6のノード間に用いられているが、それぞれの転送ノード内で一意にリンクを識別することが可能である。つまり、リンクIDの長さは、一の転送ノード内で一意性を確保するに足る長さがあればよい。
経路情報収集部520は、例えば、図12の近隣情報が得られている場合、図13に示すようなネットワークトポロジを構築し、経路情報記録部540に記録する。
図12の近隣情報と、それに基づいて構築された図13のネットワークトポロジ情報にはリンクIDを使ったが、インタフェース識別子など、他の情報をローカルIDとした場合でも、同様にネットワークトポロジ情報の構築は可能である。
経路要求処理部530は、境界転送ノード300から送信された経路要求信号を受信し、そこに含まれる情報と共に、経路計算要求を経路計算部531に通知する。
経路要求処理部530はまた、経路計算部531から、1つないしは複数の転送経路情報(1ホップ毎のリンクIDを転送経路順に列挙した情報)を取得した際に、当該転送経路情報を格納した経路応答信号を前記経路要求信号の送信元となる境界転送ノード300に送信する。
経路計算部531は、経路要求処理部530から経路計算要求を通知された場合、共に入力された、経路要求元の境界転送ノード300の識別子と、宛先アドレスをそれぞれ始点、終点ポイントとして、経路情報記録部540に記録された図13のようなネットワークトポロジ情報を使って、経路の計算を行う。経路計算には、Dijkstra法と呼ばれる最短経路を求めるアルゴリズムを適用することができる。ただし、他のアルゴリズムを適用することとしても構わない。このとき、最適な経路のほかにも幾つかの代替経路を求めることとしても良い。
経路計算要求にIPパケットの送信元アドレスを含む場合は、始点として送信元アドレス(即ち境界転送ノード300が受信したパケットの送信元となる通信ノード100aまたは100bの識別子)を使っても良い。また、前記したように経路計算を行う上で、TCP、あるいはUDPの宛先/送信元ポート番号など、他の情報を使って経路計算を行っても良い。さらには、リンクに付帯する情報(帯域、混雑具合など)や、故障した境界/内部転送ノードの識別子といった情報を経路計算に使用しても良い。
経路情報記録部540には、経路情報収集部520により、図13に示すようなネットワークトポロジ情報が記録される。前記ネットワークトポロジ情報は、経路計算のため経路計算部531から参照される。
以上本発明の実施の形態で説明した、通信インタフェース310、410、510は、前記したとおり、例えばLANカードのようなNICと、それを動作させるソフトウェア(ドライバ)により実現できる。
また、記録部390、記録部470、経路情報記録部540は、半導体メモリ、ハードディスクドライブなど情報を記録可能な装置で実現することができる。
その他の機能ブロックについては、それぞれの機器に搭載された1つあるいは複数のCPUにて実行されるコンピュータプログラム(ソフトウェア)あるいはハードウェアで実現できる。機能ブロックが行うべき処理の一部をコンピュータプログラム(ソフトウェア)で担わせ、それ以外をハードウェアで構成することとしても良い。
続いて、本実施形態の動作について図面を参照して詳細に説明する。はじめに、境界転送ノード300の動作を説明する。
図14は、境界転送ノード300が、データ転送ネットワーク600あるいは外部ネットワーク700からパケットを受信した場合の処理の流れを示している。
まず、パケット転送部320は、通信インタフェース310を介してパケットを受信すると、当該パケットに経路情報ヘッダが付与されているかどうかをチェックする(ステップS100)。
経路情報ヘッダが付与されていた場合は‘Y’に進み、その経路情報ヘッダに従って転送処理が行われる(ステップS103へ)。一方、経路情報ヘッダが付与されていなかった場合は‘N’に進み、経路取得部360から、経路要求信号を経路管理サーバ500に送信することで転送経路情報を取得する経路取得処理が行われる(ステップS101)。
転送経路情報の取得が完了すると、ヘッダ操作部330は、前記取得した転送経路情報の転送経路の順に従って、図5の経路情報ヘッダのローカルIDフィールド(‘LocalID#n’)に、ローカルIDを設定する。また、ヘッダ操作部330は、また、‘D’、‘Alt’、‘Ex’、‘F’フィールドを‘0’に設定し、‘Current Offset’を‘0’に設定する。ヘッダ操作部330は、その他のフィールドも適切な値に設定する。
また、上記ステップS101で取得した経路情報に代替経路の情報が含まれていた場合、ヘッダ操作部330は、代替経路の数だけ代替経路情報ヘッダも付与する。このとき、ヘッダ操作部330は、図9に示す代替経路情報ヘッダの‘Frm’および‘Current Offset’に‘0’を設定し、ローカルIDフィールド(‘Local ID#n’)には取得した代替経路を設定する。さらに、ヘッダ操作部330は、その他のフィールドも適切な値に設定するとともに、代替経路開始位置情報ヘッダの‘Offset#n’フィールドに、前記したように、経路情報ヘッダの先頭バイトからn番目の代替経路情報ヘッダまでのオフセットバイト数をそれぞれ設定する。
ヘッダ操作部330は、上記経路情報ヘッダ、代替経路開始位置情報ヘッダ、代替経路情報ヘッダを図4に示す順番で、前記受信したパケットの先頭に付加する(ステップS102)。
パケット転送部320は、前記した経路情報ヘッダおよび代理経路情報ヘッダのいずれかに従って転送処理を実施する(ステップS103)。
図15は、図14のステップS103の転送処理の詳細を表したフローチャートである。図15を参照すると、まず、代替経路移行部370が、代替経路を使って転送処理するか、通常の経路情報を使って転送処理をするかを判定する。ここでの判定処理の詳細は後に図16を用いて説明する。
パケット転送部320は、経路情報ヘッダの‘D’フィールドをチェックし順方向への転送をすべきか、逆方向の転送をすべきかを判定する(ステップS201)。
‘D’フィールドの値が順方向の転送を示す(‘0’)場合(ステップS201の‘Y’)、当該パケットの転送先が外部ネットワーク700であるかどうかが判定される(ステップS202)。順方向の転送において、外部ネットワーク700への転送かどうかの判定は、‘Current Offset’と‘Route Length’を比較することにより判定できる。判定方法は他にも、ローカルIDを外部ネットワーク700への転送かどうかを区別可能な値とすることとしても良いし、経路情報ヘッダ中の最後のローカルIDの後に、終端を意味する情報を格納しても良い。さらに、他の方法としても構わない。
外部ネットワーク700への転送でないと判定された場合は、‘N’に進み、経路情報ヘッダの‘Alt’フィールドの値に従い、経路情報ヘッダまたは代替経路情報ヘッダを参照し、参照したヘッダの‘Current Offset’に1ホップ分のバイト数が加算される(詳細は後述)。1ホップ分のバイト数とは、現在参照している‘LocalID#n’フィールドのバイト数となる。ここで、‘Current Offset’の値を加算する前に参照先となっていたローカルIDを保持しておく。また、ローカルID(‘LocalID#n’)中の‘Alt’フィールドが‘0’以外の場合、すなわち当該受信パケットにとって、当該転送ノードが代替経路への分岐ポイントとなっている場合、経路情報ヘッダの‘Ex’フィールドをインクリメントする。
そして、パケット転送部320は、前記保持しておいたローカルIDを用いて、順方向へのパケットの転送処理を行う(ステップS203)。具体的には、記録部370に記録された転送テーブルの情報を使ってローカルIDから、転送先とすべき通信インタフェース310を決定し、当該通信インタフェース310からパケットを転送する。
ここで、パケット転送部320が参照すべき経路情報が、経路情報ヘッダか、代替経路情報ヘッダか(複数存在する場合は、そのいずれか)を判定する方法について説明する。まず、パケット転送部320は、経路情報ヘッダの‘Alt’フィールドを参照し、‘Alt’フィールドが‘0’であれば経路情報ヘッダを参照し、‘0’以外であれば、その値を代替経路番号nとし、n番目の代替経路情報ヘッダを参照する。n番目の代替経路情報ヘッダまでのオフセットバイト数は、代替経路開始位置情報ヘッダ中の‘Offset#n’フィールドを参照することで得られる。
前記順方向のパケット転送の結果、パケット転送が成功した場合(ステップS204の‘Y’)、当該パケットに関する処理は終了する。一方、パケット転送に失敗した場合(ステップS204の‘N’)、代替経路の有無の確認が行われる(ステップS205)。なお、パケットの転送失敗には、通信インタフェースの故障、またはリンクが機能していないことの検出、送信バッファがあふれた場合など、多種多様ものが考えられるが、これらのいずれかを検出したものとする。
代替経路の有無の確認は、経路情報ヘッダの‘Ex’フィールドを用いて行われる。‘Ex’フィールドが‘0’以外の場合、パケット転送部320は、代替経路有りと判定し(ステップS205の‘Y’)、代替経路への分岐点(自転送ノードが分岐点のケースもありえる)となる転送ノードまで受信パケットが送り戻されるように、経路情報ヘッダの各フィールドを適切に設定する復帰用設定を行う(ステップS206)。具体的には、経路情報ヘッダの‘D’フィールドおよび‘F’フィールドを共に‘1’に設定し、ステップS200の代替経路転送判定が行われる。
一方、‘EX’フィールドが‘0’の場合は代替経路無しと判定され(ステップS205の‘N’)、 パケット転送部320は、当該パケットを破棄して(ステップS207)、当該パケットに関する処理を終了する。‘Ex’フィールドは‘0’であれば代替経路情報ヘッダが付与されていないとみなせるが、上記方法に代えて、経路情報ヘッダを辿ることで代替経路が存在していることを確認することとしても良い。
一方、‘D’フィールドの値が逆方向の転送を示す(‘1’)場合(ステップS201の‘N’)、当該パケットの転送先が外部ネットワーク700であるかどうかが判定される(ステップS208)。
逆方向の転送における外部ネットワーク700への転送かどうかの判定は、経路情報ヘッダの‘Alt’フィールドが‘0’であり、かつ‘Current Offset’の値が‘0’かどうかにより判定することができる(‘0’のとき外部ネットワークへの転送と判定)。これは、パケットをはじめに送信する通信ノード100a(100b)と、それを受信する境界転送ノード300間のリンクのリンク識別子を、1番最初のローカルIDとして使わない場合の判定方法となる。前記リンク識別子を1番最初のローカルIDとして使う場合は、現在の‘Currrent Offset’を、1ホップ分減算した値が‘0’の場合、外部ネットワークへの転送と判定できる。逆方向への転送時の判定方法は他にも、ローカルIDを、外部ネットワーク700への転送かどうかを区別可能な値とすることとしても良いし、経路情報ヘッダ中の最初のローカルIDの前に、開始を意味する情報を格納しても良い。さらに、他の方法としても構わない。
外部ネットワーク700への転送でないと判定された場合(ステップS208の‘N’)、 パケット転送部320は、経路情報ヘッダの‘Alt’フィールドの値に従い、経路情報ヘッダまたは代替経路情報ヘッダを参照し、参照したヘッダの‘Current Offset’から1ホップ分のバイト数が減算される(詳細は後述)。ここで、減算後の‘Current Offset’の値で参照先となるローカルIDを保持しておく。
その後、パケット転送部320は、前記保持しておいたローカルIDに基づき、パケットの転送処理を行う(ステップS209)。具体的には、記録部390に記録された転送テーブルを使って前記ローカルIDから、転送先とすべき通信インタフェース310を決定し、当該通信インタフェース310からパケットを転送し、処理を完了する。
ここで、経路情報ヘッダか、代替経路情報ヘッダのいずれか(代替経路情報が複数存在する場合も含む。)を判定する方法はステップS203の順方向転送と同様である。
一方、ステップS202、S208にて、外部ネットワーク700への転送であると判定された場合(ステップS208の‘Y’)、受信パケットのヘッダから、経路情報ヘッダ、代替経路開始位置情報ヘッダや代替経路情報ヘッダが削除される(ステップS210)。前記ヘッダが削除されたパケットは、外部ネットワーク700のノード100a(100b)へと転送される(ステップS211)。
次に、図16のフローチャートを参照して図15のステップS200の代替経路転送判定処理の詳細を説明する。
まず、代替経路移行部370は、受信パケットが、当該転送ノードおよび当該転送ノードを経由し何処かの転送ノードにおいて転送失敗が発生し、経由した転送ノードを逆方向に送り戻されたパケットであるかどうかを判定する(ステップS300)。具体的には、当該受信パケットの経路情報ヘッダ中の‘D’フィールド、および‘F’フィールドを参照し、それらが両方ともに‘1’であるかどうかを判定する。ここで、当該パケットが逆方向のパケットでも転送失敗パケットでもない場合、代替経路移行部370は、代替経路へと転送経路を移行させないことに決定し、処理が完了する(ステップS300の‘N’)。
一方、ステップS300の判定の結果、失敗による逆方向への転送(‘D’、‘F’共に‘1’)だった場合(ステップS300の‘Y’)、代替経路移行部370は、‘Current Offset’フィールドにより、当該転送ノードが参照すべきローカルIDをチェックし、当該転送ノードは、代替経路へと移行できる分岐点であり、かつ代替経路が未使用かどうかを判定する(ステップS301)。具体的には、前記ローカルID(‘LocalID#n’)中の‘Alt’フィールドが‘0’以外であり、かつ‘U’フィールドが‘0’であるかを確認する。
ステップS301の判定の結果、当該転送ノード自身が未使用の代替経路への分岐点となっていると判定できた場合、代替経路へパケットを転送するために、経路情報ヘッダ、代理情報ヘッダの各フィールドに適切な値を設定する(ステップS302)。設定内容は、以下に列挙する。
・経路情報ヘッダの‘D’フィールドを‘0’に設定(順方向の転送に戻す)
・経路情報ヘッダの‘F’フィールドを‘0’に設定(転送失敗情報をクリア)
・経路情報ヘッダの‘Ex’フィールドをデクリメント
・代替経路情報ヘッダの‘Frm’フィールドに代替経路への移行元となる、経路情報の番号を設定する。つまり、経路情報ヘッダの‘Alt’フィールドの値を、代替経路情報ヘッダの‘Frm’フィールドにコピーする。
・前記ローカルID(‘LocalID#n’)中の‘U’フィールドを‘1’に設定
・前記ローカルID(‘LocalID#n’)中の‘Alt’フィールドの値を、経路情報ヘッダの‘Alt’フィールドにコピーする。
以上の設定により、代替経路に移行して転送をするか否かの判定および代替経路への移行のための処理が完了する。
一方、ステップS301で未使用の代替経路が無いと判定された場合、つまり、当該転送ノード自身が、代替経路への分岐点ではないか、あるいは分岐点ではあるが分岐先の代替経路が既に当該パケットが転送済みの経路であった場合(ステップS301の‘N’)、代替経路移行部370は、現在参照しているのが代替経路情報ヘッダであり、その中で最初の経路情報(ローカルID)を参照しているかどうか(代替経路の起点であるかどうか)を判定する(ステップS303)。ここで、代替経路情報ヘッダを参照しているかどうかは、経路情報ヘッダの‘Alt’フィールドを参照すれば判定できる。また、最初かどうかは代替経路情報ヘッダの‘Current Offset’が‘0’かどうかで判定できる。
ステップS303の判定の結果、当該転送ノード自身が代替経路の起点であると判定された場合(ステップS303の‘Y’)、代替経路移行部370は、元経路への復帰処理を実行する(ステップS304)。この元経路への復帰処理は、現在参照対象としている代替経路情報ヘッダ中の‘Frm’フィールドの値を、経路情報ヘッダの‘Alt’フィールドにコピーすることで行われる。その後は、ステップS301に戻って、未使用の代替経路があるかどうかの判定が行われる。
それ以外の場合(ステップS303の‘N’)、元経路への復帰処理は行われることなく、処理を終了する。
続いて、内部転送ノード400の動作を説明する。図17は、内部転送ノード400が、データ転送ネットワーク600の境界転送ノード300あるいは内部転送ノード400からパケットを受信した場合の処理を示している。
図17を参照すると、まず、パケット転送部420は、通信インタフェース410を介してパケットを受信すると、当該パケットに経路情報ヘッダが付与されているかどうかをチェックする(ステップS400)。
経路情報ヘッダが付与されていた場合は‘Y’に進み、代替経路転送判定が実行される。ここでは、図16に示した境界転送ノード300における代替経路転送判定処理と同じ処理が行われる(ステップS401)。一方、経路情報ヘッダが付与されていなかった場合は‘N’に進み、受信したパケットの破棄処理が行われる(ステップS407)。
次に、パケット転送部420は、経路情報ヘッダの‘D’フィールドをチェックし、順方向への転送をすべきか、逆方向の転送をすべきかを判定する(ステップS402)。
ここで、‘D’フィールドの値が順方向の転送を示す(‘0’)場合は、‘Y’に進み、経路情報ヘッダの‘Alt’フィールドの値に従い、経路情報ヘッダまたは代替経路情報ヘッダを参照し、参照したヘッダの‘Current Offset’に1ホップ分のバイト数を加算する。1ホップ分のバイト数とは、現在参照しているローカルID(‘Local ID#n’)フィールドのバイト数となる。ここで、‘Current Offset’の値を加算する前に参照先となっていたローカルIDを保持しておく。また、ローカルIDフィールド中の‘Alt’フィールドが‘0‘以外の場合、すなわち当該受信パケットにとって、当該転送ノードが代替経路への分岐点となっている場合、経路情報ヘッダの‘Ex’フィールドをインクリメントする。
その後、前記保持しておいたローカルIDに基づき、順方向のパケットの転送処理が行われる(ステップS403)。具体的には、記録部470に記録された転送テーブルを使って前記ローカルIDから、転送先とすべき通信インタフェース410を決定し、当該通信インタフェース410からパケットが転送される。
ここで、経路情報ヘッダまたは代替経路情報ヘッダ(複数存在する場合は、そのいずれか)のうちのどれを参照するかは、経路情報ヘッダの‘Alt’フィールドを用いて決定することができる。‘Alt’フィールドが‘0’であれば経路情報ヘッダを参照し、‘0’以外であれば、その値を代替経路番号nとし、n番目の代替経路情報ヘッダを参照する。n番目の代替経路情報ヘッダまでのオフセットバイト数は、代替経路開始位置情報ヘッダ中の‘Offset#n’フィールドを参照することで得られる。
前記順方向のパケット転送の結果、パケット転送が成功した場合(ステップS404の‘Y’)、当該パケットに関する処理は終了する。一方、パケット転送に失敗した場合(ステップS404の‘N’)、代替経路の有無の確認が行われる(ステップS405)。
代替経路の有無(受信したパケットが当該転送ノードまでに経由した経路中に代替経路への分岐点があるかどうか)の確認は、経路情報ヘッダの‘Ex’フィールドを用いて行われる。‘Ex’フィールドが‘0’以外の場合、パケット転送部420は、代替経路有りと判定し(ステップS405の‘Y’)、代替経路への分岐点(自転送ノードが分岐点のケースもありえる)となる転送ノードまで受信パケットが送り戻されるように、経路情報ヘッダの各フィールドを適切に設定する復帰用設定を行う(ステップS406)。具体的には、経路情報ヘッダの‘D’フィールドおよび‘F’フィールドを共に‘1’に設定し、その後は、ステップS401の代替経路転送判定が行われる。
一方、‘EX’フィールドが‘0’の場合は代替経路無しと判定され(ステップS405の‘N’)、パケット転送部420は、当該パケットを破棄して(ステップS407)、当該パケットに関する処理を終了する。‘Ex’フィールドは‘0’であれば代替経路情報ヘッダが付与されていないとみなせるが、上記方法に代えて、経路情報ヘッダを辿ることで代替経路が存在していることを確認することとしても良い。
一方、ステップS402にて‘D’フィールドの値が逆方向の転送を示す(‘1’)場合(ステップS402の‘N’)、 パケット転送部420は、経路情報ヘッダの‘Alt’フィールドの値に従い、経路情報ヘッダまたは代替経路情報ヘッダを参照し、参照したヘッダの‘Current Offset’の値を1ホップ分減算する。ここで、パケット転送部420は、減算後の‘Current Offset’で参照先となるローカルIDを保持しておく。
その後、パケット転送部420は、前記保持しておいたローカルIDに基づき、逆方向のパケットの転送処理を行う(ステップS408)。具体的には、記録部470に記録された転送テーブルを使って前記ローカルIDから、転送先とすべき通信インタフェース410を決定し、当該通信インタフェース410からパケットを転送し、処理を完了する。
ここで、参照すべき経路情報を、経路情報ヘッダとするか、代替経路情報ヘッダとするか(複数存在する場合は、そのいずれか)の判定は、ステップS403の順方向転送と同様である。
続いて、境界転送ノード300および内部転送ノード400によるローカルIDの決定およびその結果を経路管理サーバ500に近隣情報として通知する処理を説明する。
図18は、境界転送ノード300および内部転送ノード400が近隣情報通知を送信する動作を示すフローチャートである。
図18を参照すると、まず、ローカルID決定部340(430)が、ローカルIDを決定する(ステップS500)。ローカルIDとしてリンクIDを使う場合は、近隣ノードとリンクIDのネゴシエーションを実施することでリンクIDを決定する。なお、ローカルIDとして、通信インタフェースの識別子を使う場合は、当該境界転送ノード300あるいは内部転送ノード400は、自らが備える通信インタフェース310(410)に割当てた識別子をローカルIDとする。
ここで、前記リンクIDは、当該境界転送ノード300あるいは内部転送ノード400が使用可能なすべての物理的あるいは論理的なリンクに対して決定される。同じように、通信インタフェースの識別子は、全ての物理的あるいは論理的な通信インタフェースに対して決定される。ただし、管理上の理由などにより、一部のリンクや、通信インタフェースを対象外としても構わない。
次に、ローカルID決定部340(440)は、前記決定したローカルIDと通信インタフェース情報(当該通信インタフェースをパケット転送先とするのに必要な情報)とを対応づけて、記録部390(470)中の転送テーブル(図3参照)に記録する(ステップS501)。転送テーブルには、各リンクの先に接続された近隣ノードの識別子も対応づけて記録する。さらに、各リンクに関連する情報や、近隣ノードの故障情報なども付帯情報として記録しても良い。
前記転送テーブルへの記録が完了すると、近隣情報通知部350(430)が、記録部390(470)に記録された転送テーブルの情報から、ローカルIDと、近隣ノードの識別子を設定した近隣情報(図12参照)を構成し、これを経路管理サーバ500へ送信する(ステップS502)。近隣情報には、各リンクに関連する情報や、近隣ノードの故障情報などといった付帯情報も格納することとしても良い。
続いて、経路管理サーバ500の動作を説明する。図19は、上記近隣情報を受信した経路管理サーバ500の処理を表したフローチャートである。図19を参照すると、まず、経路情報収集部520にて境界転送ノード300あるいは内部転送ノード400から送られた近隣情報を受信すると(ステップS600)、経路管理サーバ500は、受信した近隣情報から、ローカルIDや近隣ノードの識別子といった情報を取得し、取得した情報を用いてネットワークトポロジ情報を構築し、記録部540に記録する(ステップS601)。
図20は、境界転送ノード300から経路情報を要求された経路管理サーバ500の処理を表したフローチャートである。図20を参照すると、まず、境界転送ノード300から経路要求信号を受信すると、経路要求処理部530は、経路要求信号に含まれる情報を経路計算部531に通知する(ステップS700)。
次に、経路計算部531は、ステップS700で通知された経路要求信号に含まれていた情報と、経路情報記録部540に記録されたネットワークトポロジ情報とにより、最適な転送経路の計算を行う(ステップS701)。このとき、前記決定された転送経路での転送に失敗した場合を考慮し、前記転送経路上の任意の転送ノードにおいて経路を分岐させた代替経路をいくつか計算することとしても良い。転送経路の計算が完了すると、経路計算部531は、決定された経路および代替経路についてそれぞれ転送順に1ホップ毎のローカルIDを読み出し、経路要求処理部530に通知する。
前記転送経路の計算結果(代替経路がある場合は代替経路情報も含む)を受け取った経路要求処理部530は、通知された転送経路情報(ローカルIDの並び)を、経路情報応答信号に設定して、経路要求信号の送信元である境界転送ノード300に送信する(ステップS702)。
次に、図21のシーケンス図を参照して、IPノードである通信ノード100aが境界転送ノード300aにパケットを送信し、それが順次転送処理され、最終的にIPノードである通信ノード100bに届くまでの一連の流れを説明する。
ここでは、例として、各ノードの接続状況が図13に示したネットワークトポロジのようになっているものとして説明する。境界転送ノード300aは、図13のID=1のノードに相当する。境界転送ノード300bは、図13のID=8のノードに相当する。IPパケットの送信元アドレスは、192.168.0.50であり、宛先アドレスは、192.168.0.20であるものとする。また、代替経路は使わないものとする。
通信ノード100aから送信されたIPパケットが境界転送ノード300aに届くと(ステップS800)、境界転送ノード300aは、図14に示すフローチャートに従った処理を実行する。ここでは、IPパケットには経路情報ヘッダが付与されていないため、図14のステップS101において経路情報要求信号が経路管理サーバ500に送信される(ステップS801)。
前記経路情報要求信号を受信した経路管理サーバ500は、図20のフローチャートに従い、経路情報を計算し、転送経路を決定した後、経路情報応答信号を境界転送ノード300aに送信する(ステップS802)。
リンクの帯域や、混雑具合は考慮せず、最短パスを計算する場合、以下のとおり、転送経路が計算される。図13のネットワークトポロジの最短パスは、ID=1のノード −> ID=10のノード −> ID=8のノード −> 192.168.0.20のノード(パケットの宛先となる外部ネットワークのIPノード)が転送経路として選択される。従って、前記経路情報応答信号には、図13のネットワークトポロジのパス上のリンクIDである、1、2、0の値がローカルIDとして上記順番で格納される。
ここで、ID=192.168.0.50のノード(外部ネットワーク700のIPノード)からID=8のノード間のリンクID(=0)を経路情報応答に含めることとしても構わない。この場合、前記経路情報応答信号に含めるローカルIDの格納順序は、0、1、2、0となる。また逆に、外部ネットワーク(通信ノード100b)へのリンクID(=0)を経路情報応答に含めないこととしても構わない。この場合、ローカルIDの格納順序は、1、2となる。
さらに、外部ネットワークのIPノードのIDとしてIPアドレスを使ったが、IPアドレスの上位から任意のbit長を抜き出したネットワークアドレスとしても良いし、MAC(Media Access Control)アドレスなどレイヤ2の情報や、それ以外の情報を用いても構わない。
境界転送ノード300は前記経路情報応答信号を受信すると(ステップS803)、図14のステップS102以降の処理にしたがい、ステップS800で受信したIPパケットに経路情報ヘッダを付与し、その後、図14のステップS103において、付与した経路情報ヘッダに従い、転送すべきローカルID(=1)に対応した通信インタフェースからパケットを送出する(ステップS804)。この結果、ID=10の内部転送ノード400にパケットが転送される。
内部転送ノード400は、経路情報ヘッダが付与されたパケットを受信すると(ステップS805)、図17に示すフローチャートに従い転送処理を行う(ステップS806)。ここでは、転送経路情報に従って、転送すべきローカルID(=2)に対応した通信インタフェースからパケットが送出され、ID=8の境界転送ノード300bにパケットが転送される。
境界転送ノード300bは、経路情報ヘッダが付与されたパケットを受信すると(ステップS807)、図14に示すフローチャートにそって処理を実施する。さらに図14のステップS103では、さらに図15に示すフローチャートに示した転送処理が実施される。ここでは、図15のステップS202で外部ネットワークへの転送と判定されるため、境界転送ノード300bは、前記受信したパケットから経路情報ヘッダが除去した後、除去前の経路情報ヘッダの情報に従い、転送すべきローカルID(=0)に対応した通信インタフェースからパケットを送出する(ステップS808)。この結果、最終的に通信ノード100bへとIPパケットが転送される。
次に、図22のシーケンス図を参照して、IPノードである通信ノード100aが境界転送ノード300aにパケットを送信し、それが順次転送処理されるが、第1に計算された最適な経路(基本経路)で転送している途中で送信失敗が発生し、代替経路を用いて転送に成功した場合の一連の流れを説明する。
以下図21と同様に、各ノードの接続状況が図13に示したネットワークトポロジのようになっているものとして説明する。
通信ノード100aから送信されたIPパケットが境界転送ノード300aに届くと(ステップS900)、境界転送ノード300aは、経路管理サーバ500から経路情報を取得し、前記IPヘッダに経路情報ヘッダを付与する処理を行う(ステップS901)。ステップS901は、図21におけるステップS802からステップS803に相当するが、ここでは、経路情報として、以下のとおり、基本経路に加え、2つの代替経路を取得できたものとする。
基本経路情報(代替経路ではない経路)は、図21の場合と同様、ID=1のノード −> ID=10のノード −> ID=8のノード −> 192.168.0.20のノードという経路とする。
第1の代替経路情報は、基本経路のID=10のノードを分岐点として、ID=10のノード −> ID=5 −> ID=6 −> ID=8のノード −> 192.168.0.20のノード という経路とする。
第2の代替経路情報は、基本経路のID=1のノードを分岐点として、ID=1のノード −> −> ID=5 −> ID=6 −> ID=8のノード −> 192.168.0.20のノードという経路とする。
このとき、基本経路、第1の代替経路、第2の経路のローカルIDの並びは以下となる。
基本経路:1(第2の代替経路への分岐有り),2(第1の代替経路への分岐有り),0
第1の代替経路:3,1,3,0
第2の代替経路:2,1,3,0
この結果、前記受信したIPパケットには、上記ローカルIDを並べた経路情報ヘッダに加え、代替経路開始位置情報ヘッダ、そして上記ローカルIDを並べた2つの代替経路情報ヘッダが付与される。
前記基本情報ヘッダにおいて、ローカルID=1および2となる箇所が代替経路への分岐点となっているので、これらのローカルIDは、図7の拡張されたローカルIDとなる。それぞれ‘Alt’フィールドには、分岐先の代替経路の番号が設定される。
境界転送ノード300は、上記のように付与した経路情報ヘッダに従い、転送すべきローカルID(=1)に対応した通信インタフェースからパケットを送出する(ステップS902)。このとき、境界転送ノード(ID=1)は、代替経路への分岐点を持つので、経路情報ヘッダの‘Ex’フィールドはインクリメントされ‘1’となる。
前記パケットを受信したノードID=10の内部転送ノード400aは、図17に示すフローチャートに従い転送処理を実施し、転送すべきローカルID(=2)に対応した通信インタフェースからパケットを送出する。このとき、内部転送ノード400aは、代替経路への分岐点を持つので、経路情報ヘッダの‘Ex’フィールドはインクリメントされ‘2’となる。
ここで、内部転送ノード400aにてパケット転送失敗を検出したものとする(図17のステップS404の‘N’)。
このとき、内部転送ノード400aは、代替経路の有無を確認する。ここでは、経路情報ヘッダの‘Ex’フィールドが‘0’でない(‘2’)ため、当該転送ノードまでの経路の途中に代替経路が存在していると判定される。
その結果、内部転送ノード400aは、当該パケットの経路情報ヘッダに代えて、代替経路により当該パケットを転送するため、分岐点までパケットを逆方向に転送する設定を行う(図17のステップS406の「復帰用設定」)。具体的には、経路情報ヘッダの‘D’フィールド、‘F‘フィールドを共に’1‘が設定される。
その後、内部転送ノード400aは、当該パケットを直ちに逆方向に転送するのではなく、図17のステップS401の代替経路転送判定処理を再度実施する。
当該転送ノード(ID=10)は、第1の代替経路への分岐点であるため、代替経路へ移行するために経路情報ヘッダの値の設定が行われる。
図16に示した代替経路転送判定処理が行われた結果として経路情報ヘッダの‘D’フィールド、‘F’フィールドはすぐに‘0’に再設定され、‘Ex’フィールドもデクリメントされる。この結果‘Ex’フィールドは‘1’となる。参照していたローカルIDの’U’フィールドを’1’として、さらに同じくローカルIDの’Alt’フィールドを代替経路情報ヘッダの’Alt’フィールドにコピーする。この結果当該フィールドには’1’が設定される。
以上の処理により、当該内部転送ノード400aおよび以降の転送ノードは、第1の代替経路を使った転送処理を実行する。まず、内部転送ノード400aは、経路情報ヘッダの’Alt’フィールドが’1’であるため、第1の代替経路情報が設定された代替経路情報ヘッダのローカルIDを参照する。その結果ローカルID(リンク識別子)が’3’であるため、リンク識別子=’3’に接続された通信インタフェースから前記パケットを送出する(ステップS905)。この際、前記代替経路ヘッダの’Current Offset’フィールドは、当該ローカルIDのバイト数分だけ加算される。
前記転送の結果、前記パケットは内部転送ノード400b(ID=5)に受信される。以降では、第1の代替経路情報ヘッダの’Current Offset’により示された位置のローカルIDを参照し、次ホップとなる転送ノードへとパケットを順次転送され、最終的に、通信ノード100bへとパケットが転送される(ステップS906〜ステップS908)。
次に、図23のシーケンス図を参照して、IPノードである通信ノード100aが境界転送ノード300aにパケットを送信し、それが順次転送処理されるが、第1に計算された最適な経路(基本経路)および第1の代替経路で転送している途中で送信失敗が発生し、第2の代替経路を用いて転送に成功した場合の一連の流れを説明する。
以下図21と同様に、各ノードの接続状況が図13に示したネットワークトポロジのようになっているものとして説明する。
図23のステップS1000からステップS1004までは、図22のステップS900からステップS904までと全く同じであるため説明を省略する。
ステップS1005において、内部転送ノード400aは、第1の代替経路への分岐点となっているため、第1の代替経路が設定された代替経路情報ヘッダのローカルIDを参照する。その結果ローカルID(リンク識別子)が’3’であるため、リンク識別子=’3’に接続された通信インタフェースから前記パケットを送出する。この際、前記代替経路ヘッダの’Current Offset’フィールドは、当該ローカルIDのバイト数分だけ加算される。
ここまではステップS905と同じであるが、ここで、内部転送ノード400aにてパケット転送失敗を検出したものとする(図17のステップS404の‘N’)。
このとき、内部転送ノード400aは、代替経路の有無を確認する(ステップS1006)。ここでは、経路情報ヘッダの’Ex’フィールドが’0’でない(’1’)ため、当該転送ノードまでの経路の途中に代替経路が存在していると判定される。
その結果、内部転送ノード400aは、当該パケットの経路情報ヘッダに代えて、代替経路により当該パケットを転送するため、分岐点までパケットを逆方向に転送する設定を行う(図17のステップS406の「復帰用設定」)。具体的には、経路情報ヘッダの’D’フィールド、’F’フィールドを共に’1’が設定される。
その後、内部転送ノード400aは、当該パケットを直ちに逆方向に転送するのではなく、図17のステップS401の代替経路転送判定処理を再度実施する。
そして、図16に示した代替経路転送判定処理に従い、第1の代替経路で参照しているローカルIDには、さらなる代理経路への分岐点となる情報がないので、図16のステップS300の‘Y’およびステップS301の‘N’と遷移し、図16のステップS303で、代替経路の起点に戻ったかどうかが判定される。
このとき、第1の代替経路情報ヘッダの’Current Offset’は’0’であるため、起点に戻っていることが判定できる。したがって、図16のステップS304に進み、元経路への復帰処理が実行される。前記元経路への復帰処理は、第1の代替経路情報ヘッダの’Frm’フィールドの値を、経路情報ヘッダの’Alt’フィールドにコピーすることで行われる。
この結果、前記’Alt’フィールドは’0’に設定され、内部転送ノード400aを含め、これ以降当該パケットを受信した転送ノードは、基本経路情報(経路情報ヘッダに設定された経路)により転送処理を行うこととなる。
図16のフローチャートにしたがい、この後、再度ステップS301で未使用の代替経路があるかどうかが判定される。ここでの判定には経路情報ヘッダのローカルIDが使用される。この結果、当該内部転送ノード400aから第1の代替経路への経路があるが、使用済み(’U’=’1’)なので、図16のステップS301では’N’に進み、次に図16のステップS303で、代理経路の起点かどうかが判定される。当該内部転送ノード400aは基本経路の起点では無く、そもそも代替経路ではないので、判定結果は’N’となり代替経路転送判定処理は完了する。
その後、図17のステップS402で転送方向の判定は、‘D’フィールドが‘1’であることにより、’N’(逆方向)となるため、図17のステップS408で逆方向への転送処理が実行される。この結果、受信パケットは、リンク識別子=’1’に接続された通信インタフェースから、境界転送ノード300a(ID=1)へと送られる(ステップS1007)。
次にステップS1008において、前記逆方向へ転送されたパケットを受信すると、境界転送ノード300aは、図15に示す転送処理を実行する。まず、ステップS200の代替経路転送判定処理で、受信パケットは、逆方向、かつ転送失敗(’D’フィールド=1、’F’フィールド=1)であり、さらに未使用の代替経路がある(第2の代替経路)ため、図16のステップS302で代替経路への移行処理が実施される。
具体的には、経路情報ヘッダの’D’フィールド、’F’フィールドは、’0’に設定される。また、同じく経路情報ヘッダの’Alt’フィールドには、ローカルIDの’Alt’フィールドがコピーされ、結果として’2’が設定される。また、前記ローカルID中の’U’フィールドは’1’に設定される。この後は、図15のステップS201以降に従い、第2の代替経路情報ヘッダを使って受信パケットの転送処理が行われる。
ここでは、第2の代替経路情報ヘッダ中の最初のローカルID情報は’2’(リンク識別子=’2’)であるため、当該境界転送ノード300a(ID=1)の通信インタフェースのうち、リンク識別子=’2’のリンクに接続された通信インタフェースよりパケットが送出される(ステップS1009)。
内部転送ノード400b(ID=5)によりステップS1009で受信したパケットの転送処理が行われる(ステップS1010)。転送の手順は、これまで説明したように経路情報ヘッダの’Alt’フィールドを参照し、これが’0’でない(’2’)ことから、第2の代替経路情報ヘッダ使った転送が開始される。第2の代替経路情報ヘッダの’Current Offset’フィールドにより参照すべきローカルIDを特定する。ここでは’Current Offset’は’C1’なので、第2の代替経路情報ヘッダの‘Local ID#1’が参照される。前記したとおり‘Local ID#1’は、’1’であるため、当該内部転送ノード400bは、リンク識別子が’1’であるリンクに接続された通信インタフェースから、当該パケットを送出する(ステップS1011)。
次に、内部転送ノード400c(ID=6)は、ステップS1011で送出されたパケットの転送処理を行う(ステップS1012)。処理内容は、ステップS1010で説明した内部転送ノード400bにおける転送処理と同様である。結果として、当該内部転送ノード400cは、リンク識別子が’3’であるリンクに接続された通信インタフェースから、当該パケットを送出する(ステップS1013)。
最後にステップS1014では、境界転送ノード300b(ID=8)は、ステップS1013で送出されたパケットの転送処理を行う。この際、境界転送ノード300bは、図14に示すフローチャートにそって処理を実施する。さらに図14のステップS103では、さらに図15の示すフローチャートに示した転送処理が実施される。ここでは、外部ネットワークへの転送となるので、図15のステップS210で経路情報ヘッダ、代替経路開始位置情報ヘッダ、代替経路情報ヘッダが除去され、その後、外部ネットワークに接続された通信インタフェースから当該パケットが送出される(ステップS1015)。その結果、通信ノード100bにパケットが送られる。
以上のとおり、本実施形態によれば、IPアドレス等のグローバルに一意性が確保される経路情報ではなく、転送ノード内、あるいは、隣接する転送ノード間といった局所的な範囲での一意性だけが保証されたローカルIDを使って転送先を指定するよう構成している。このため、1バイトあるいは2バイト程度の情報量に1ホップ分の転送経路が格納可能となり、当該転送経路の情報を経路情報ヘッダに格納してパケットに付与した場合でも、付与するヘッダによるオーバヘッドを極めて小さいサイズに抑制することが可能になる。この結果、用途を限らずすべてのパケットに経路情報ヘッダを格納することが可能となる。
また本実施形態では、転送ノードに備える転送テーブルのエントリ数を、各転送ノードが備える通信インタフェースの数程度とすることが可能になる。また、転送テーブルの格納・更新・利用のため、転送ノードに必要とされるメモリのサイズやCPUの処理能力も抑制可能となり、転送ノードを安価とすることができる。
これらの結果として、本実施形態によれば、転送経路を1ホップ毎に厳密に指定した場合においても正味の情報を効率よく、さらに高速に転送可能となる。
さらに、本実施形態によれば、パケットに代替転送経路情報を付加し、転送ノードに、適宜代替転送経路への移行機能を備えたため、転送経路に障害が発生した場合や、トラヒックが過大となった場合などにも、影響を受けることなく、宛先にパケットを転送することが可能となっている。
[第2の実施形態]
続いて、本発明の第1の実施形態に変更を加え、転送失敗経路を記憶保持するようにした本発明の第2の実施形態について図面を参照して詳細に説明する。
本発明の第2の実施形態の全体の構成は、第1の実施形態とほぼ同じ構成、機能となるが、境界転送ノード301、および内部転送ノード401に変更が加えられている。以下のその相違点を中心に説明を加える。
図24は、本発明の第2の実施形態の境界転送ノード301の構成を示す図である。第1の実施形態の境界転送ノード300と、同等の機能ブロックは、同一の符号を付している。以下、第1の実施形態の境界転送ノード300と異なる符号が付された、代替経路移行部371、転送結果記録部381、記録部391について説明する。
代替経路移行部371は、本発明の第1の実施形態の代替経路移行部370とほぼ同じ機能を備えるが、受信パケット中の経路情報ヘッダ(代替経路を使っている場合は代替経路情報ヘッダ)中の経路情報(ローカルIDの並び)を、記録部391に記録されている転送失敗経路情報テーブルの各エントリと比較し、一致する場合は、当該受信パケットを無効な経路を経由するパケットとみなし、転送経路を代替経路または他の代替経路へと移行させる機能をさらに備える。
ここで、記録部391に記録される転送失敗経路情報テーブルについて説明する。転送失敗経路情報テーブルは、例えば、図25に示すようなフォーマットであり、各エントリは転送失敗経路と有効時刻の情報を含む。
前記転送失敗経路情報とは、当該転送ノードにおいて参照するローカルIDから、当該転送ノード以降の転送ノードにおいて転送に失敗したローカルIDまでを並べた情報である。ここで、本実施形態のローカルIDは、後記するように第1の実施形態とフォーマットが異なるのみであり、転送に失敗した転送ノードが、転送を試みた通信インタフェースの識別子または前記通信インタフェースに接続したリンクのリンク識別子のいずれかである。
有効時刻情報は、時刻が、ここに記録された有効時刻を超過した場合は当該エントリが削除されるか無効となることを意味する。ただし、有効時刻を使わないこととしても良い。
代替経路移行部371は、また、転送が失敗し、逆方向に転送されてきたパケット(すなわち、’D’フィールド、’F’フィールドともに’1’のパケット)を受信した場合、当該転送ノードが代替経路への分岐点となっている場合、前記受信パケットを代替経路へ転送すると共に、受信パケットの経路情報ヘッダまたは代替経路情報ヘッダの情報を使って前記転送失敗経路情報テーブルにエントリを追加する機能を備える。
図26は、本実施形態で用いるローカルIDのフォーマットである。第1の実施形態におけるローカルIDに対し、’B’(BrokenLink)フィールドが追加されている。転送失敗が発生した場合、転送失敗が発生した通信インタフェース識別子、あるいはリンク識別子に相当するローカルIDの’B’フィールドが’1’に設定される。したがって、当該転送ノードが参照するローカルIDから、転送失敗したローカルIDまでを読み出し、転送失敗経路情報テーブルに記録することができる。
転送結果記録部381は、本発明の第1の実施形態の転送結果記録部380とほぼ同じ機能を備えるが、転送に失敗した際に、経路情報ヘッダの’D’フィールド、および’F’フィールドを’1’に設定するのに加え、転送を試みた際に参照していたローカルIDの’B’フィールドに’1’を設定する機能を備える。
記録部391には、本発明の第1の実施形態において記録される転送テーブルに加え、図25に例示した転送失敗経路情報テーブルが記録される。
図27は、本発明の第2の実施形態の内部転送ノード401の構成を示す図である。第1の実施形態の内部転送ノード400と、同等の機能ブロックは、同一の符号を付している。
第1の実施形態の内部転送ノード400と異なる符号が付された、代替経路移行部451、転送結果記録部461、記録部471は、それぞれ境界転送ノード301の代替経路移行部371、転送結果記録部381、記録部391と同等の機能であるため、これらの説明は省略する。
続いて、第2の実施形態における境界転送ノード301および内部転送ノード401が近隣ノードからパケットを受信した際の処理の流れを説明する。
境界転送ノード301、内部転送ノード401ともに、第1の実施形態における境界転送ノード300、内部転送ノード400とほぼ同等の動作となる。異なるのは、図16に示す代替経路転送判定処理と、図15の境界転送ノード300における復帰用設定(ステップS206)、図17の内部転送ノード400における復帰用設定(ステップS406)である。以下、第1の実施形態との相違点を中心に説明する。
まず、図28に示すフローチャートを用いて、本発明の第2の実施形態における代替経路転送判定処理を説明する。
まず、転送ノードは、受信パケットが、当該転送ノードおよび当該転送ノードを経由し、それ以降の転送ノードにおいて転送失敗が発生し、経由した転送ノードを逆方向に送り戻されたパケットであるかどうかを判定する(ステップS1100)。具体的には、当該受信パケットの経路情報ヘッダ中の’D’フィールド、および’F’フィールドを参照し、それらが両方ともに’1’であるかどうかを判定する。
受信パケットが失敗による逆方向への転送パケットでなかった場合(ステップS1100の’N’)、転送ノードは、受信パケットの経路情報ヘッダ(代替経路を使用している場合は代替経路情報ヘッダ)において現在参照しているローカルIDと、それに続くローカルIDを、図25に示した転送失敗経路情報テーブルの各エントリと比較する(ステップS1101)。比較の結果、一致するエントリがある場合は、当該受信パケットは転送失敗するパケットとして代替経路へと移行することに決定する(ステップS1101の’Y’)。一方、一致するエントリが無い場合は’N’に進み、処理が完了する(ステップS1101の’N’)。
上記ステップS1101の処理は、本発明の第2の実施形態における代替経路移行部371および代替経路移行部451により新たに加わった処理である。
一方、受信パケットが失敗による逆方向への転送パケット(’D’フィールド、’F’フィールド共に’1’)であった場合(ステップS1100の’Y’)、転送ノードは、’Current Offset’フィールドにより、参照すべきローカルIDをチェックし、当該転送ノードは代替経路へと移行できる分岐点であり、かつ代替経路が未使用かどうかを判定する(ステップS1102)。具体的には、前記ローカルID(’Local ID#n’)中の’Alt’フィールドが’0’以外であり、かつ’U’フィールドが’0’であるかを判定する。
前記判定の結果、未使用の代替経路の分岐点となっていると判定できた場合(ステップS1102の’Y’)、転送ノードは、経路情報ヘッダ(代替経路を使用している場合は代替経路情報ヘッダ)から、当該転送ノードが参照するローカルIDから、前記’B’(BrokenLink)フィールドが’1’に設定されたローカルIDまでの一連のローカルIDを読み出し、これを図25に示した転送失敗経路情報テーブルのエントリとして登録する。
上記ステップS1103の処理は、本発明の第2の実施形態における代替経路移行部371および代替経路移行部451により新たに加わった処理である。
次に転送ノードは、代替経路へパケットを転送するために、経路情報ヘッダ、代理情報ヘッダの各フィールドに適切な値を設定する(ステップS1104)。具体的な設定内容は、図16のS302と同様であるため、ここでは省略する。前記設定が完了した後、代替経路転送判定処理は終了となる。
一方、前記の条件が満たされなかった場合、つまり代替経路への分岐点ではないか、あるいは分岐点ではあるが、分岐先の代替経路が、既に当該パケットを転送したことのある経路であった場合(ステップS1102の’N’)、転送ノードは、現在参照しているのが代替経路情報ヘッダであり、その中で最初の経路情報(ローカルID)を参照しているかどうかを判定する(ステップS1105)。ここで、代替経路情報ヘッダを参照しているかどうかは、経路情報ヘッダの’Alt’フィールドを参照すれば判定できる。また、最初かどうかは代替経路情報ヘッダの’Current Offset’が’0’かどうかで判定できる。
前記判定の結果、代替経路の最初の経路情報でない、つまり、自ノードが代替経路の起点でないと判定した場合(ステップS1105の’N’)、代替経路転送判定処理は終了となる。
前記判定の結果、代替経路の最初の経路情報と判定した場合、つまり、自ノードが代替経路の起点であると判定した場合(ステップS1105の’Y’)、転送ノードは、元経路への復帰処理を実行する。前記元経路への復帰処理は、現在参照対象としている代替経路情報ヘッダ中の’Frm’フィールドの値を、経路情報ヘッダの’Alt’フィールドにコピーすることで行う。
次に、本発明の第2の実施形態における境界転送ノード301での復帰用設定処理と、図15の第1の実施形態における復帰用設定処理(ステップS206)との相違点を説明する。
本発明の第1の実施形態における復帰用設定処理(図15のステップS206)では、代替経路への分岐点(自転送ノードが分岐点のケースもありえる)となる転送ノードまで受信パケットを戻す処理が実施されるように、経路情報ヘッダの各フィールドが適切に設定するものである。具体的には、経路情報ヘッダの’D’および’F’フィールドを共に’1’に設定している。
これに対し、本発明の第2の実施形態の復帰用設定処理では、上記に加え、転送結果記録部381により、結果として失敗に終わった転送を行う際に参照したローカルID情報の’B’フィールドを’1’に設定する処理が行われる。
続いて、本発明の第2の実施形態の内部転送ノード401での復帰用設定処理と、第1の実施形態の復帰用設定処理(図17のステップS406)との相違点を説明する。
本発明の第1の実施形態の復帰用設定処理(図17のステップS406)は、代替経路への分岐点(自転送ノードが分岐点のケースもありえる)となる転送ノードまで受信パケットを戻す処理が実施されるように、経路情報ヘッダの各フィールドを適切に設定するものである。具体的には、経路情報ヘッダの’D’および’F’フィールドを共に’1’に設定している。
これに対し、本発明の第2の実施形態の復帰用設定処理では、上記に加え、転送結果記録部461により、結果として失敗に終わった転送を行う際に参照したローカルID情報の’B’フィールドを’1’に設定する。
続いて、図29のシーケンス図を参照して、IPノードである通信ノード100aが境界転送ノード300aにパケットを送信し、それが順次転送され、最終的にIPノードである通信ノード100bに届くまでの処理の説明を行う。
ただし、ここでは、本発明の第2の実施形態をよりわかりやすく説明するため、次のようにパケットが送信されたものとして説明する。
まず、最初のパケットの転送途中に転送失敗が発生し、当該パケットを代替経路への分岐点となる転送ノード(ここでの例では境界転送ノード300a)まで戻した後に、代替経路で転送する。
次に、同じように通信ノード100aから通信ノード100bに送られたパケットを境界転送ノード300aが受信した場合、当該パケットの失敗が予測されるため、境界転送ノード300aは、基本経路ではなく、ただちに代替経路での転送を行う。
図29を参照すると、通信ノード100aから送信されたIPパケットが境界転送ノード300aに届くと(ステップS1200)、前記IPパケットを受信した境界転送ノード300aが、経路管理サーバ500から経路情報を取得し、前記IPヘッダに経路情報ヘッダを付与する処理を実行する(ステップS1201)。
以下第1の実施形態と同様に、各ノードの接続状況が図13に示したネットワークトポロジのようになっているものとし、以下のように、基本の経路情報のほかに、1つの代替経路を取得できたものとして説明する。
基本の経路情報(代替経路ではない経路):
ID=1のノード −> ID=10のノード −> ID=8のノード −> 192.168.0.20のノードという経路。
第1の代替経路情報:
基本経路のID=1のノードを分岐点として、ID=1のノード −> ID=10のノード −> ID=5 −> ID=6 −> ID=8のノード −> 192.168.0.20のノード という経路。
このとき、基本経路、第1の代替経路のローカルIDの並びは以下となる。
基本経路 :1(第1の代替経路への分岐有り),2,0
第1の代替経路:2,1,3,0
この結果、前記受信したIPパケットには、経路情報ヘッダに加え、代替経路開始位置情報ヘッダ、そして1つの代替経路情報ヘッダが付与される。
前記基本情報ヘッダにおいて、ローカルID=1を参照する転送ノード(境界転送ノード300a)が第1の代替経路への分岐点となっているので、これらのローカルIDは、図26下段の拡張された(’E’=’1’)ローカルIDとなり、そして前記ローカルID中の’Alt’フィールドには、分岐先の代替経路の番号が設定される。
次に境界転送ノード300aは、付与した経路情報ヘッダに従い、転送すべきローカルID(リンク識別子)で示されるリンクに接続された通信インタフェースからパケットを送出する(ステップS1202)。このとき、境界転送ノード300aは、代替経路への分岐点を持つので、経路情報ヘッダの’Ex’フィールドがインクリメントされ’1’となる。
この後、内部転送ノード400a(ID=10)にパケットが転送される。次に、経路情報ヘッダが付与されたパケットを受信した内部転送ノード400aは、図17に示すフローチャートに従い転送処理を実施し、リンク識別子=2に接続された通信インタフェースからパケットを送出する(ステップS1203)。
ここで、内部転送ノード400aにてパケット転送失敗を検出したものとする(図17のステップS404の‘N’)。このとき、ステップS1204では、代替経路の有無が確認される。経路情報ヘッダの’Ex’フィールドが’0’でない(’1’)ため、当該転送ノードまでの経路に代替経路が存在していると判定される。
その結果、当該パケットの経路情報ヘッダに代えて、代替経路により当該パケットを転送するため、分岐点までパケットを逆方向に転送する設定が行われる(ステップS1204)。具体的には、経路情報ヘッダの’D’フィールド、’F’フィールドがともに’1’に設定される。
さらに、ここでは失敗した転送を行う際に参照したローカルIDの’B’フィールドも’1’に設定される。なお、ここでの例ではローカルID=’2’となるローカルIDの’B’フィールドが’1’に設定される。
前記処理の結果、内部転送ノード400aは、当該パケットを逆方向に転送する(ステップS1205)。
前記逆方向へ転送されたパケットを受信した境界転送ノード300aは、図15に示す境界転送ノードの転送処理のとおり、まずステップS200の代替経路転送判定処理を実行する(ステップS1206)。この結果、逆方向転送、かつ転送失敗(’D’フィールド=1、’F’フィールド=1)であり、さらに未使用の代替経路がある(第1の代替経路)ため、代替経路へ移行することが決定される。
このとき、図28のステップS1103にて、図25の転送失敗経路情報テーブルにエントリが追加される。この例の場合、追加されたエントリには、{1,2}という転送失敗経路が記述される。この後、ステップS1104で代替経路への移行処理が実施される。
具体的には、経路情報ヘッダの’D’フィールド、’F’フィールドは’0’に設定される。そして’Alt’フィールドには、ローカルIDの’Alt’フィールドがコピーされ、結果として’1’が設定される。また、前記ローカルID中の’U’フィールドが’1’に設定される。この後は、図15のステップS201以降の処理に従い、第1の代替経路情報ヘッダを使って受信パケットの転送処理が行われる。そして、当該パケットはこれまで説明した手順により複数の転送ノード間を転送されていき、最終的に通信ノード100bまで送られる(ステップS1207)。
その後、通信ノード100aから通信ノード100bに送信された別のIPパケットが境界転送ノード300aに届いた場合(ステップS1208)、境界転送ノード300aは、前記ステップS1201と同様に経路管理サーバ500に転送経路に問い合わせ、経路情報を取得する。ただし、ステップS1201で取得した経路情報をキャッシュとして保持しておくことで、宛先IPアドレス等が同様の値となるIPパケットを受信した際には、前記キャッシュの情報を使い経路管理サーバ500への問い合わせを省略することとしても構わない。いずれにせよ、ここでもステップS1201と同じ経路情報が取得でき、前記経路情報を使って構成した経路情報ヘッダ、代替経路開始位置情報ヘッダ、代替経路情報ヘッダがIPパケットに付与されたものとする。
前記ヘッダが付与された後、境界転送ノード300aは、図15のフローチャートに従って転送処理を実行するが、まずはステップS200で代替経路転送判定処理が実施される(ステップS1209)。
ここでの代替経路転送判定処理は、図28に示すフローチャートに示す流れとなる。前記ヘッダが付与されたパケットは、順方向であり、転送失敗もしていないので、図28のステップS1100では’N’に進み、ステップS1101が処理される。ステップS1101では前記したように、前記パケットの経路情報ヘッダと図25の転送失敗経路情報テーブルのエントリとが比較され、一致したエントリが無いかどうかが調べられる。
前記したように、転送失敗経路情報テーブルには、転送失敗経路が{1,2}であるエントリが存在する。一方、前記パケットに付与された経路情報ヘッダ中の転送経路情報のうち、当該境界転送ノード300aが転送時に参照するローカルIDを起点とした場合のローカルIDの並びは、{1,2,0}である。
前記比較の結果、{1,2}の部分が一致するため、前記のステップS1101では’Y’に進みステップS1104が処理される。すなわち、受信パケットを内部転送ノード400aに転送すること無く、転送経路を直ちに代替経路に切り替えることができ、高効率な転送することができる。当該パケットは代替経路により最終的に通信ノード100bへと送られる(ステップS1210)。
以上の本発明の第2の実施形態によれば、第1の実施形態の効果に加えて、転送失敗が予測される経路情報ヘッダが付与されたパケットを受信した際には、即座に代替経路に転送することが可能になる。結果として、サービス途絶時間を抑制するだけでなく、無駄な転送を回避し、リンクの帯域や処理能力を有効に使うことが可能となる。
以上、本発明の好適な実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、上記した各実施形態では、リンクの両端の近隣ノード間で共有しているリンクIDを用いるものとして説明したが、ローカルIDとして、通信インタフェースの識別子を用いることも可能である。
またさらに、リンクIDや通信インタフェースの識別子に代えて、第3のローカルIDを採番し、これをリンクIDや通信インタフェースに紐付けておく変形構成も採用可能である。
また、例えば、上記した実施形態では、個々の転送ノードがローカルID決定部を備えて、それぞれローカルIDを決定するものとして説明したが、経路管理サーバにて各転送ノードの構成情報を入手可能である場合には、経路管理サーバがローカルIDを決定し、それぞれの記録部に転送テーブルを記憶させる構成も採用可能である。この場合、個々の転送ノードのローカルID決定部を省略することができる。またさらに、経路管理サーバが各転送ノードの接続関係も入手可能であり、隣接するノード同士が重複しないようにローカルIDを設定可能である場合には、個々の転送ノードの近隣情報通知部も省略することが可能である。
また、上記した実施形態の経路管理サーバ500は、非特許文献1のオープンフローコントローラにて実現することができ、この場合、転送ノードは、オープンフロースイッチにて実現することができる。
また、上記した実施形態の経路管理サーバ500は、専用のサーバとして実現することもでき、転送ノードとしては、上記オープンフロースイッチのほか、IP網におけるルータ、MPLS網におけるMPLSスイッチにて実現することができる。その他、サーバがネットワーク内の転送ノードを集中管理するようなネットワークであれば、本発明を適用することが可能である。
データセンタなどの商用ネットワークでは、QoS(Quality of Service)や、負荷分散のため、宛先アドレス、送信元アドレス、使用プロトコルといった様々な条件により、パケットの転送経路を厳密に制御する必要がある。本発明によれば、経路情報を増やすことなくパケットのオーバヘッドを抑制しつつ、転送経路を厳密に指定することを可能とする。また、リンクに障害が発生した際にも、サービスを継続することが重要となる。本発明の通信システムは、経路情報を増やすことなくパケットのオーバヘッドを抑制しつつ、転送経路を厳密に指定することを可能とするとともに、特定のリンクに障害が発生した場合でも、ヘッダに格納した幾つかの代替経路を使ってパケットの転送ができ、耐障害性、可用性に優れたネットワークシステムを構築することが可能となる。
したがって、本発明はデータセンタなどの商用ネットワークへ好適に適用可能である。
なお、本発明の全開示(請求の範囲を含む)の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
最後に、本発明の特許請求の範囲に繰り込み可能な発明を付記する。
[付記1]
上記した通信システムにおいて、
前記転送結果記録部は、パケット内の前記転送失敗した転送ノードが使用した通信インタフェースまたは隣接ノードとの間に張られたリンクを識別するための識別子を用いて、前記転送失敗が発生した転送経路情報を生成し、記録する通信システム。
[付記2]
上記した転送ノードにおいて、
さらに、パケット内の複数の転送経路情報のうちのどの転送経路情報を使うかを示す経路選択情報を参照して、前記パケット転送処理に用いる転送経路情報を決定する転送ノード。
[付記3]
上記した転送ノードにおいて、
パケットに含まれる、1つの転送経路から、別の転送経路へと分岐可能な転送ノードを判別するための情報を用いて、転送経路を異なる転送経路に切り替える転送ノード。
[付記4]
上記した転送ノードにおいて、
パケットに含まれる、転送処理の結果により更新される前記転送結果情報を参照して、転送に失敗していない転送経路情報を選択する転送ノード。
[付記5]
上記した転送ノードにおいて、
転送処理に失敗した場合、当該パケットに含まれる、当該パケットを受信した転送ノードまで至る転送経路上における現在の転送経路から異なる転送経路へと分岐可能な転送ノードの数を示す分岐点情報を減らし、前記分岐点情報を用いて当該パケットを破棄するか否かを決定する転送ノード。
[付記6]
上記した転送ノードにおいて、
転送失敗が発生した転送経路情報を記録する転送結果記録部を備え、
パケットを受信した際に、当該パケットに格納された転送経路情報と前記記録された転送失敗が発生した経路情報とを比較し、その結果、転送失敗が予測される場合、別の転送経路に切りかえる転送ノード。
[付記7]
上記した転送ノードにおいて、
前記転送結果記録部は、パケット内の前記転送失敗した転送ノードが使用した通信インタフェースまたは隣接ノードとの間に張られたリンクを識別するための識別子を用いて、前記転送失敗が発生した転送経路情報を生成し、記録する転送ノード。
[付記8]
上記した転送ノードにおいて、
さらに、前記転送経路情報を含まないパケットを受信した場合、経路管理サーバに問い合わせることで取得した、前記パケットを通信相手まで到達させ得る複数の転送経路情報を用い、前記パケットに前記複数の転送経路情報を格納する転送ノード(境界転送ノード)。
100、100a、100b 通信ノード
200 転送ノード
300、300a、300b、301、301a、301b 境界転送ノード
310 通信インタフェース
320 パケット転送部
330 ヘッダ操作部
340 ローカルID決定部
350 近隣情報通知部
360 経路取得部
370、371 代替経路移行部
380、381 転送結果記録部
390、391 記録部
400 内部転送ノード
410 通信インタフェース
420 パケット転送部
430 ローカルID決定部
440 近隣情報通知部
450、451 代替経路移行部
460、461 転送結果記録部
470、471 記録部
500 経路管理サーバ
510 通信インタフェース
520 経路情報収集部
530 経路要求処理部
531 経路計算部
540 経路情報記録部
600 データ転送ネットワーク
700 外部ネットワーク

Claims (14)

  1. データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースを識別するための識別子を並べることによって構成された複数の転送経路情報を送信する経路管理サーバと、
    前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択し、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行する転送ノードと、を含通信システム。
  2. 前記パケットは、前記転送経路情報に含まれる識別子のうち参照すべき識別子を示す所定の情報を格納可能であり、
    前記転送ノードは、前記所定の情報を参照して、前記パケットの転送処理に用いる識別子を決定する請求項1の通信システム。
  3. 前記パケットは、前記複数の転送経路情報のうち参照すべき転送経路情報を示す経路選択情報を格納可能であり、
    前記転送ノードは、前記経路選択情報を参照して、前記パケット転送処理に用いる転送経路情報を決定する請求項の通信システム。
  4. 記データ転送ネットワークにおいて、前記転送経路が分岐する位置の転送ノードに転送経路情報の選択を行わせる請求項1から3いずれか一の通信システム。
  5. データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースを識別するための識別子を並べることによって構成された複数の転送経路情報を送信する経路管理サーバと接続され、
    前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットの転送処理を実行する転送ノードであって、
    前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択し、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行する転送ノード。
  6. データ転送ネットワークの転送経路上の所定の転送ノードからの要求に応じて、前記転送経路上の個々の転送ノードに備えられている通信インタフェースを識別するための識別子を並べることによって構成された複数の転送経路情報を構成し、送信する経路管理サーバであって、
    前記複数の転送経路情報を格納したヘッダが付加されたパケットを受信した転送ノードに、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択させ、かつ、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行させる経路管理サーバ
  7. データ転送ネットワークの経路管理サーバが、データ転送ネットワークの転送経路上の個々の転送ノードに備えられている通信インタフェースを識別するための識別子を並べることによって構成された複数の転送経路情報を送信するステップと、
    前記転送経路上の転送ノードが、前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択し、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行するステップと、
    を含む通信方法。
  8. データ転送ネットワークの転送経路上の個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を送信する経路管理サーバと、
    前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択し、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行する転送ノードと、を含通信システム。
  9. 前記パケットは、前記転送経路情報に含まれる識別子のうち参照すべき識別子を示す所定の情報を格納可能であり、
    前記転送ノードは、前記所定の情報を参照して、前記パケットの転送処理に用いる識別子を決定する請求項の通信システム。
  10. 前記パケットは、前記複数の転送経路情報のうち参照すべき転送経路情報を示す経路選択情報を格納可能であり、
    前記転送ノードは、前記経路選択情報を参照して、前記パケット転送処理に用いる転送経路情報を決定する請求項の通信システム。
  11. 記データ転送ネットワークにおいて、前記転送経路が分岐する位置の転送ノードに転送経路情報の選択を行わせる請求項8から10いずれか一の通信システム。
  12. データ転送ネットワークの転送経路上の個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を送信する経路管理サーバと接続され、
    前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットの転送処理を実行する転送ノードであって、
    前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択し、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行する転送ノード。
  13. データ転送ネットワークの転送経路上の所定の転送ノードからの要求に応じて、前記転送経路上の個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を構成し、送信する経路管理サーバであって、
    前記複数の転送経路情報を格納したヘッダが付加されたパケットを受信した転送ノードに、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択させ、かつ、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行させる経路管理サーバ
  14. データ転送ネットワークの経路管理サーバが、データ転送ネットワークの転送経路上の個々の転送ノードとその隣接ノードとの間に張られたリンクを識別するための識別子を並べることによって構成された複数の転送経路情報を送信するステップと、
    前記転送経路上の転送ノードが、前記経路管理サーバから取得した前記複数の転送経路情報を格納したヘッダが付加されたパケットについて、前記複数の転送経路情報からパケット転送処理に用いる転送経路情報を選択し、前記選択した転送経路情報に含まれる識別子のいずれかに従ってパケット転送処理を実行するステップと、
    を含む通信方法。
JP2015030198A 2010-01-08 2015-02-19 通信システム、転送ノード、経路管理サーバおよび通信方法 Active JP5935913B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2015030198A JP5935913B2 (ja) 2010-01-08 2015-02-19 通信システム、転送ノード、経路管理サーバおよび通信方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2010002875 2010-01-08
JP2010002875 2010-01-08
JP2015030198A JP5935913B2 (ja) 2010-01-08 2015-02-19 通信システム、転送ノード、経路管理サーバおよび通信方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2011549034A Division JP5699939B2 (ja) 2010-01-08 2011-01-07 通信システム、転送ノード、経路管理サーバおよび通信方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2016095970A Division JP6137384B2 (ja) 2010-01-08 2016-05-12 通信システム、転送ノード、経路管理サーバおよび通信方法

Publications (2)

Publication Number Publication Date
JP2015128304A JP2015128304A (ja) 2015-07-09
JP5935913B2 true JP5935913B2 (ja) 2016-06-15

Family

ID=44305582

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2011549034A Active JP5699939B2 (ja) 2010-01-08 2011-01-07 通信システム、転送ノード、経路管理サーバおよび通信方法
JP2015030198A Active JP5935913B2 (ja) 2010-01-08 2015-02-19 通信システム、転送ノード、経路管理サーバおよび通信方法
JP2016095970A Active JP6137384B2 (ja) 2010-01-08 2016-05-12 通信システム、転送ノード、経路管理サーバおよび通信方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2011549034A Active JP5699939B2 (ja) 2010-01-08 2011-01-07 通信システム、転送ノード、経路管理サーバおよび通信方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2016095970A Active JP6137384B2 (ja) 2010-01-08 2016-05-12 通信システム、転送ノード、経路管理サーバおよび通信方法

Country Status (5)

Country Link
US (1) US20110286326A1 (ja)
EP (1) EP2523405A4 (ja)
JP (3) JP5699939B2 (ja)
CN (2) CN105141516A (ja)
WO (1) WO2011083846A1 (ja)

Families Citing this family (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9001645B2 (en) * 2006-05-17 2015-04-07 Rajant Corporation System and method for packet delivery backtracking
USRE48951E1 (en) 2015-08-05 2022-03-01 Ecolab Usa Inc. Hand hygiene compliance monitoring
US9300491B2 (en) 2011-02-11 2016-03-29 Qualcomm Incorporated Frame delivery path selection in hybrid communication networks
US8897169B2 (en) 2011-03-02 2014-11-25 Qualcomm Incorporated Discovery of conventional devices and bridges in hybrid communication networks
US9025603B2 (en) * 2011-03-08 2015-05-05 Qualcomm Incorporated Addressing scheme for hybrid communication networks
US9461777B2 (en) 2011-11-21 2016-10-04 Qualcomm Incorporated Hybrid networking system with seamless path switching of streams
KR101887581B1 (ko) * 2011-12-26 2018-08-14 한국전자통신연구원 플로우 기반의 패킷 전송 장치 및 그것의 패킷 처리 방법
US9185166B2 (en) * 2012-02-28 2015-11-10 International Business Machines Corporation Disjoint multi-pathing for a data center network
JP5817078B2 (ja) * 2012-04-17 2015-11-18 株式会社日立製作所 伝送システム、集中制御計算機、及び伝送方法
JP2014003408A (ja) * 2012-06-18 2014-01-09 Hitachi Ltd 中継転送システム、経路制御装置およびエッジ装置
US9722943B2 (en) * 2012-12-17 2017-08-01 Qualcomm Incorporated Seamless switching for multihop hybrid networks
CA2895685A1 (en) * 2012-12-19 2014-06-26 Nec Corporation Communication node, control apparatus, communication system, packet processing method, communication node controlling method and program
US10447575B1 (en) 2012-12-27 2019-10-15 Sitting Man, Llc Routing methods, systems, and computer program products
US10397100B1 (en) 2012-12-27 2019-08-27 Sitting Man, Llc Routing methods, systems, and computer program products using a region scoped outside-scope identifier
US10212076B1 (en) 2012-12-27 2019-02-19 Sitting Man, Llc Routing methods, systems, and computer program products for mapping a node-scope specific identifier
US10411998B1 (en) 2012-12-27 2019-09-10 Sitting Man, Llc Node scope-specific outside-scope identifier-equipped routing methods, systems, and computer program products
US10411997B1 (en) 2012-12-27 2019-09-10 Sitting Man, Llc Routing methods, systems, and computer program products for using a region scoped node identifier
US10419334B1 (en) 2012-12-27 2019-09-17 Sitting Man, Llc Internet protocol routing methods, systems, and computer program products
US10374938B1 (en) 2012-12-27 2019-08-06 Sitting Man, Llc Routing methods, systems, and computer program products
US10404583B1 (en) 2012-12-27 2019-09-03 Sitting Man, Llc Routing methods, systems, and computer program products using multiple outside-scope identifiers
US10476787B1 (en) 2012-12-27 2019-11-12 Sitting Man, Llc Routing methods, systems, and computer program products
US10904144B2 (en) 2012-12-27 2021-01-26 Sitting Man, Llc Methods, systems, and computer program products for associating a name with a network path
US10404582B1 (en) 2012-12-27 2019-09-03 Sitting Man, Llc Routing methods, systems, and computer program products using an outside-scope indentifier
US10397101B1 (en) 2012-12-27 2019-08-27 Sitting Man, Llc Routing methods, systems, and computer program products for mapping identifiers
US10587505B1 (en) 2012-12-27 2020-03-10 Sitting Man, Llc Routing methods, systems, and computer program products
US10419335B1 (en) 2012-12-27 2019-09-17 Sitting Man, Llc Region scope-specific outside-scope indentifier-equipped routing methods, systems, and computer program products
US9282034B2 (en) 2013-02-20 2016-03-08 International Business Machines Corporation Directed route load/store packets for distributed switch initialization
CN105075196A (zh) * 2013-02-25 2015-11-18 日本电气株式会社 控制器、通信系统、路径切换方法和程序
JP5987971B2 (ja) 2013-02-26 2016-09-07 日本電気株式会社 通信システム、スイッチ、制御装置、制御用チャネルの構築方法及びプログラム
US9444748B2 (en) * 2013-03-15 2016-09-13 International Business Machines Corporation Scalable flow and congestion control with OpenFlow
US9252965B2 (en) 2013-03-15 2016-02-02 International Business Machines Corporation Directed route load/store packets for distributed switch initialization
CN103248536B (zh) * 2013-04-28 2017-12-29 新华三技术有限公司 一种虚链路pw检测方法及设备
WO2014177190A1 (en) * 2013-04-30 2014-11-06 Telefonaktiebolaget L M Ericsson (Publ) Technique of operating a network node for load balancing
JP6229318B2 (ja) * 2013-06-05 2017-11-15 富士通株式会社 通信システム、通信制御方法、及び、伝送装置
CN104426815B (zh) * 2013-08-27 2019-07-09 中兴通讯股份有限公司 一种sdn中流表下发的方法和系统、of控制器和of交换机
US9455901B2 (en) 2013-10-04 2016-09-27 Nicira, Inc. Managing software and hardware forwarding elements to define virtual networks
US9444677B2 (en) 2013-10-18 2016-09-13 Cisco Technology, Inc. Scalable edge node protection using IPv6 segment routing extension header
JP6312019B2 (ja) * 2013-12-09 2018-04-18 パナソニックIpマネジメント株式会社 通信システム及び通信方法
US20150229618A1 (en) * 2014-02-11 2015-08-13 Futurewei Technologies, Inc. System and Method for Securing Source Routing Using Public Key based Digital Signature
US9912577B2 (en) * 2014-04-17 2018-03-06 Cisco Technology, Inc. Segment routing—egress peer engineering (SP-EPE)
US9923799B2 (en) * 2014-04-25 2018-03-20 Metaswitch Networks Ltd. Data processing
JP2016025400A (ja) * 2014-07-16 2016-02-08 富士電機株式会社 無線通信システム、無線機、中継ルート決定方法、および、プログラム
US20160099859A1 (en) * 2014-10-06 2016-04-07 Futurewei Technologies, Inc. Reverse Path Validation for Source Routed Networks
CN105634942B (zh) * 2014-10-31 2020-01-03 华为技术有限公司 转发报文的方法和交换机
CN104378380A (zh) * 2014-11-26 2015-02-25 南京晓庄学院 一种基于SDN架构的识别与防护DDoS攻击的系统及方法
CN105991435B (zh) * 2015-02-05 2019-08-27 华为技术有限公司 用于获取端口路径的方法及装置
US9942058B2 (en) 2015-04-17 2018-04-10 Nicira, Inc. Managing tunnel endpoints for facilitating creation of logical networks
CN106302252B (zh) 2015-05-15 2019-11-26 华为技术有限公司 数据交换系统架构、发送数据流量的方法以及交换装置
US10554484B2 (en) 2015-06-26 2020-02-04 Nicira, Inc. Control plane integration with hardware switches
US9967182B2 (en) 2015-07-31 2018-05-08 Nicira, Inc. Enabling hardware switches to perform logical routing functionalities
US9847938B2 (en) 2015-07-31 2017-12-19 Nicira, Inc. Configuring logical routers on hardware switches
US9819581B2 (en) 2015-07-31 2017-11-14 Nicira, Inc. Configuring a hardware switch as an edge node for a logical router
WO2017022833A1 (ja) * 2015-08-06 2017-02-09 日本電気株式会社 Vnf提供システム、vnf id管理装置、vnfのid管理方法及びプログラム
US10313186B2 (en) 2015-08-31 2019-06-04 Nicira, Inc. Scalable controller for hardware VTEPS
US9948577B2 (en) 2015-09-30 2018-04-17 Nicira, Inc. IP aliases in logical networks with hardware switches
US10230576B2 (en) 2015-09-30 2019-03-12 Nicira, Inc. Managing administrative statuses of hardware VTEPs
US10263828B2 (en) 2015-09-30 2019-04-16 Nicira, Inc. Preventing concurrent distribution of network data to a hardware switch by multiple controllers
US9998324B2 (en) 2015-09-30 2018-06-12 Nicira, Inc. Logical L3 processing for L2 hardware switches
US10250553B2 (en) 2015-11-03 2019-04-02 Nicira, Inc. ARP offloading for managed hardware forwarding elements
US9998375B2 (en) 2015-12-15 2018-06-12 Nicira, Inc. Transactional controls for supplying control plane data to managed hardware forwarding elements
US9917799B2 (en) 2015-12-15 2018-03-13 Nicira, Inc. Transactional controls for supplying control plane data to managed hardware forwarding elements
US9992112B2 (en) 2015-12-15 2018-06-05 Nicira, Inc. Transactional controls for supplying control plane data to managed hardware forwarding elements
US10200343B2 (en) 2016-06-29 2019-02-05 Nicira, Inc. Implementing logical network security on a hardware switch
CN106603415A (zh) * 2016-12-16 2017-04-26 成都西加云杉科技有限公司 数据处理方法及装置
BR112019018376B1 (pt) 2017-03-07 2024-02-20 Ecolab Usa Inc Dispositivo, e, módulo de sinalização de dispensador
CN107689921B (zh) * 2017-09-15 2020-11-13 深圳市盛路物联通讯技术有限公司 一种转发节点的选择方法及系统
US10574561B2 (en) * 2017-10-04 2020-02-25 Cisco Technology, Inc. Centralized error telemetry using segment routing header tunneling
JP6773088B2 (ja) * 2018-08-09 2020-10-21 沖電気工業株式会社 無線中継装置、無線中継プログラム、及び無線通信システム
US11245667B2 (en) * 2018-10-23 2022-02-08 Akamai Technologies, Inc. Network security system with enhanced traffic analysis based on feedback loop and low-risk domain identification
CA3123862A1 (en) * 2018-12-20 2020-06-25 Ecolab Usa Inc. Adaptive route, bi-directional network communication
CN112583745A (zh) * 2019-09-27 2021-03-30 华为技术有限公司 一种在sr网络中转发报文的方法、设备和系统
US11102121B2 (en) * 2019-10-23 2021-08-24 Cisco Technology, Inc. Path signatures for data flows
CN111277630B (zh) * 2020-01-13 2022-09-09 腾讯科技(深圳)有限公司 一种路由控制方法、装置、电子设备和存储介质

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03195235A (ja) * 1989-12-25 1991-08-26 Mitsubishi Electric Corp パケット交換網のルーチング制御方式
JP2570963B2 (ja) * 1993-05-31 1997-01-16 日本電気株式会社 パケット網における中継経路情報を用いたシグナリング方式
JP3790655B2 (ja) * 2000-03-06 2006-06-28 富士通株式会社 ラベルスイッチネットワークシステム
US6788689B1 (en) * 2000-03-07 2004-09-07 Cisco Technology, Inc. Route scheduling of packet streams to achieve bounded delay in a packet switching system
JP2002185513A (ja) * 2000-12-18 2002-06-28 Hitachi Ltd パケット通信ネットワークおよびパケット転送制御方法
JP2002198989A (ja) * 2000-12-25 2002-07-12 Yaskawa Electric Corp 制御システムにおけるネットワーク中継方法および制御システム
JP2002314586A (ja) * 2001-02-09 2002-10-25 Mitsubishi Electric Corp 送信装置及び多重通信方式及び多重通信方法及び多重通信プログラム及び多重通信プログラムを記録した計算機で読み取り可能な記録媒体
IL141855A0 (en) * 2001-03-07 2002-03-10 Onetiercommunications Inc A method and apparatus for providing an improved quality of service for data transfer over the internet
DE60131551T2 (de) * 2001-12-12 2008-10-23 Alcatel Lucent Telekommunikationsnetzwerk und entsprechenden Paketkopf
US7047315B1 (en) * 2002-03-19 2006-05-16 Cisco Technology, Inc. Method providing server affinity and client stickiness in a server load balancing device without TCP termination and without keeping flow states
JP2004153318A (ja) * 2002-10-28 2004-05-27 Ntt Docomo Inc パケット通信方法、パケット通信システム、送信元ノード、中継ノード及び中継器
JP2004356883A (ja) * 2003-05-28 2004-12-16 Nippon Telegr & Teleph Corp <Ntt> データ通信システム、および方法
JP2005045681A (ja) * 2003-07-24 2005-02-17 Nec Engineering Ltd スイッチネットワーク装置及びその転送制御方法
US8081566B1 (en) * 2004-04-19 2011-12-20 Rockstar BIDCO, LLP Method and apparatus for indicating congestion in a source routed network
JP2005333454A (ja) * 2004-05-20 2005-12-02 Nippon Telegr & Teleph Corp <Ntt> パス設定用サーバ装置、パス設定方法およびパス設定用プログラム
US7471669B1 (en) * 2004-09-30 2008-12-30 Nortel Networks Limited Routing of protocol data units within a communication network
JP4549961B2 (ja) * 2004-11-01 2010-09-22 株式会社日立製作所 通信路監視システム及び通信ネットワークシステム
JP4388464B2 (ja) * 2004-12-07 2009-12-24 株式会社日立製作所 パケット中継装置およびパケット通信ネットワーク
JP4726498B2 (ja) * 2005-01-14 2011-07-20 富士通株式会社 情報処理方法及びルータ
US7522603B2 (en) * 2006-03-14 2009-04-21 Cisco Technology, Inc. Technique for efficiently routing IP traffic on CE-CE paths across a provider network
CN101047614B (zh) * 2006-05-01 2010-08-25 华为技术有限公司 一种IPv6网络环境中流传输路径建立方法和数据传输系统
US8982887B2 (en) * 2007-05-18 2015-03-17 International Business Machines Corporation System, method and program for making routing decisions
US7911944B2 (en) * 2007-12-26 2011-03-22 Nortel Networks Limited Tie-breaking in shortest path determination
JP5062845B2 (ja) * 2008-06-30 2012-10-31 日本電信電話株式会社 経路切替方法、サーバ装置、境界ノード装置、経路切替システム及び経路切替プログラム
CN101436998A (zh) * 2008-12-16 2009-05-20 华为技术有限公司 报文转发路径获取方法和报文转发装置
CN102498694A (zh) * 2009-09-14 2012-06-13 日本电气株式会社 通信系统、转发节点、路径管理服务器、通信方法和程序
WO2011080870A1 (ja) * 2009-12-28 2011-07-07 日本電気株式会社 通信システムおよびポート情報収集方法

Also Published As

Publication number Publication date
US20110286326A1 (en) 2011-11-24
CN102714629B (zh) 2015-07-29
JP2016165150A (ja) 2016-09-08
JP6137384B2 (ja) 2017-05-31
JPWO2011083846A1 (ja) 2013-05-16
CN105141516A (zh) 2015-12-09
JP5699939B2 (ja) 2015-04-15
JP2015128304A (ja) 2015-07-09
EP2523405A1 (en) 2012-11-14
CN102714629A (zh) 2012-10-03
EP2523405A4 (en) 2016-09-07
WO2011083846A1 (ja) 2011-07-14

Similar Documents

Publication Publication Date Title
JP6137384B2 (ja) 通信システム、転送ノード、経路管理サーバおよび通信方法
JP5790850B2 (ja) 通信システム、転送ノード、経路管理サーバ、通信方法およびプログラム
EP1411678B1 (en) Method and system for content-oriented routing of packets in a storage-embedded network
US8065434B2 (en) Method and device for maintaining routes
WO2021169258A1 (zh) 转发报文的方法、发布路由信息的方法、装置及系统
JP4491397B2 (ja) トラフィック迂回機能を備えるパケット転送装置。
JP4541745B2 (ja) ホームエージェント管理装置及び管理方法
JP5672235B2 (ja) 通信システム、フロー制御装置、フローテーブルの更新方法およびプログラム
JP5800019B2 (ja) 通信経路制御システム、経路制御装置、通信経路制御方法および経路制御プログラム
US20140369356A1 (en) Opportunistic compression of routing segment identifier stacks
EP2523402A1 (en) Communication system, control apparatus, processing rule setting method, packet transmitting method and program
JPWO2002087175A1 (ja) リストレーション・プロテクション方法及び装置
JP2010161473A (ja) 通信システム、管理計算機、スタックドスイッチ、フロー経路決定方法
JP5001966B2 (ja) 経路情報管理方法およびその管理システム
JP4638849B2 (ja) 機能分散型通信装置および経路制御方法
JP5022412B2 (ja) 経路情報管理システム、経路情報管理方法、およびプログラム
JP5045551B2 (ja) ルート集約装置、及び集約処理方法
JP4530697B2 (ja) 通信システム
JP6724427B2 (ja) コントローラ、通信スイッチ、通信システム、通信制御方法、及びプログラム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20151111

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151117

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160118

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160425

R150 Certificate of patent or registration of utility model

Ref document number: 5935913

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150