(57)【要約】      （修正有）【課題】コンピュータ・ネットワークにおけるマルチパス・パケット・ルーティング・デバイス及び方法を提供する。【解決手段】デバイス（ルータ）は、アクティブなフローの識別子と、関係するルータの発信インターフェース識別子とを収容するフロー転送テーブル（ＦＦＴ）を維持する。新たなフローを表す最初のパケットが、ルータに到達すると、ルーティング・テーブルを利用する既存の方法を用いて、発信インターフェース識別子が選択される。次いで、ＦＦＴにしたがって、パケットが発信インターフェースに導かれる。ルーティング・テーブルは、ＦＦＴにおけるフロー識別子と発信インターフェースとの間の関係を形成するために使用する。【選択図】図１
2015057879.tif 000002
【特許請求の範囲】
【請求項１】
専用ルータであって、
前記ルータがＦＦＴの記憶のために物理メモリを備え、前記ＦＦＴ自体が、フロー識別子と、アウトバウンド・トラフィックが送られるときに通るルータ・インターフェースとを格納する、専用ルータ。
【請求項２】
請求項１記載のルータであって、特定の方法で機能し、前記ＦＦＴを格納するメモリが、パケットが前記ルータに入る毎にアクセスされ、前記メモリが、前記パケットの発信インターフェースを記録するために使用される、ルータ。
【請求項３】
請求項１記載のルータにおいて、前記ＦＦＴが、分析されたパケットに対するエントリを含まない場合、それに対するエントリが、前記ルータにおける既存のルーティング・テーブルから確定されるという事実を特徴とする、ルータ。
【請求項４】
請求項１記載のルータにおいて、更に、前記ＦＦＴを格納するメモリが、このフローに属するパッケージについて、前記フロー識別子およびアウトバウンド・インターフェース識別子に対して少なくとも２つの専用フィールドを含むことを特徴とする、ルータ。
【請求項５】
請求項４記載のルータにおいて、更に、前記ＦＦＴが、時間間隔識別を可能にする追加のフィールドを含むことを特徴とし、前記時間間隔が、所与のフローにおける最後のパッケージの到達からの経過時間を表す、ルータ。
【請求項６】
フロー制御方法であって、ＦＦＴに格納された情報を用いて、所与の発信パケットにルータ・ポートを選択することを特徴とする、フロー制御方法。
【請求項７】
請求項１記載のルータにおいて、更に、前記ＦＦＴが、ＩＰｖ４プロトコル・パケット・ヘッダからのＴＴＬフィールド、またはＩＰｖ６プロトコル・パケット・ヘッダからのホップ限度フィールドの値のために追加のフィールドを含むことを特徴とする、ルータ。
【請求項８】
請求項６記載のフロー制御方法において、前記ＩＰｖ４プロトコル・パケット・ヘッダからの前記ＴＴＬフィールド値（またはＩＰｖ６プロトコル・パケット・ヘッダからのホップ限度フィールド値）が、前記対応するフローに対して前記ＦＦＴに格納された値と一致しない場合、前記フローがＦＦＴから除去される、フロー制御方法。
【請求項９】
請求項１記載のルータにおいて、前記ルータがその発信リンクのトラフィック特性（例えば、負荷）を分析し、指定された閾値を超過する場合、前記ルータが、それぞれのインターフェースのルーティング・プロトコルにおけるコストを、指定された値に増大し、前記情報を前記ネットワークにおける他の全てのルータに分散させ、その結果後続のルータにおけるルーティング・テーブル変更を促すことを特徴とする、ルータ。
【請求項１０】
請求項１記載のルータにおいて、前記ルーティング・テーブルの変更が、発信フローのパスには影響を及ぼさないことを特徴とする、ルータ。
【請求項１１】
請求項１記載のルータにおいて、リンク・コストに影響を及ぼすトラフィック特性の変化によって生ずる前記ルーティング・テーブルの変更が、前記発信フローのパスを変化させないことを特徴とする、ルータ。
【請求項１２】
請求項６記載のネットワークにおけるフロー制御方法において、リンク・コストに影響を及ぼすトラフィック特性の変化によって生ずるルーティング・テーブルの変更が、発信フローのパスを変化させないことを特徴とする、フロー制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチパスＩＰ（インターネット・プロトコル）ネットワークにおけるパケットのマルチパス・ルーティング・デバイス、およびその使用方法を紹介する。提案する解決策は、現在のリンク・スループット・レベルを考慮して、インテリジェントにトラフィックのために送信パスを決定することができる。このようにして、一層効果的な方法で、リソースを割り当てることができる。
【従来技術】
【０００２】
本発明によって提案するデバイスの主なエレメントは、ルータである。ルータは、ＩＰパケットのために宛先ノードまでのパスを設定し、パケットを適正な発信インターフェース(outgoing interface)に転送する。現在使用されているルータでは、配給されるパケットに発信インターフェースを決定するために、ルーティング・テーブルが使用される。このテーブルは、ノードのリストのような、ルータのメモリに格納される情報を収容し、このリストによって宛先ネットワークを見ることができる。
【０００３】
ルーティング・テーブルは、ルータに到達したパケットを各宛先ネットワークまたはサブネットワークに転送することを可能にするエントリを収容する。ルーティング・テーブルは、設定され、ルータの物理メモリに維持される。ルーティング・テーブルにおける典型的なエントリは、宛先サブネットワークのアドレス、メトリック、および発信インターフェースの識別子またはアドレスを収容し、これらによってサブネットワークが利用可能になる。殆どの場合、ルーティング・テーブルにおける宛先サブネット毎に１つだけのインターフェース、即ち、最も好ましいインターフェースがある。
【０００４】
コンピュータ・ネットワークに輻輳が生ずることは望ましくない。輻輳は、送ることができるよりも多い情報を処理しなければならないときに観察される。負荷均衡化は、輻輳を解消する１つの方法であり、その主な目標は、様々なパスを通ってトラフィックを宛先ノードまで送ることである。
【０００５】
負荷均衡化は、同じ宛先サブネットワークに向けた、メトリックが同じまたは異なる様々なインターフェースをルーティング・テーブルに維持することを可能にする。現在の負荷に基づいて、割り当てられた重みにしがって、利用可能な発信インターフェースの各々にトラフィックが送られる。言い換えると、ルータは、異なる発信インターフェースを介してパケットを宛先ネットワークに送る。負荷均衡化を使用すると、１つのフローのパケットが異なるパスを通ってそして異なる順序で宛先ノードに来る場合がある。更に、これは、ネットワークにかかる負荷が非効率になる可能性もある。あるエレメントには輻輳を生じ、他のエレメントには生じないこともある。
【０００６】
パケットのグループが同じノード間で送られ、そのパケット・ヘッダにおいて選択されたフィールドに同じ値を有するとき、これらを「フロー」と見なすとよい。これらのフィールドは、通常、ソースおよび宛先アドレス、ポート番号（ソースおよび宛先）、ならびにトランスポート・レイヤ・プロトコル（オープン・システム相互接続、ＯＳＩ／ＩＳＯモデルに従う）の識別子である。
【０００７】
現在、マルチパス送信は、ＭＰＬＳ（マルチプロトコル・ラベル・スイッチング）プロトコルの下で可能である。ＭＰＬＳ規格は、ＲＦＣ３０３１において定められる。ＭＰＬＳプロトコルを使用するルータは、レイヤ２およびレイヤ３ヘッダ間に置かれるラベルに基づいてパケットを送る。要するに、ＭＰＬＳプロトコルを使用するルータは、ＭＰＬＳドメインを構成する(comprise)。プロバイダ・エッジ・ルータ（ＰＥルータ）として知られるＭＰＬＳドメインの境界ルータに到達したパケットは、ＭＰＬＳラベルが与えられ、適正な発信インターフェースに送られる。ＭＰＬＳドメイン内部では、ルータはパケット転送のためにＭＰＬＳラベルのみを使用する。このようなルータは、プロバイダ・ルータ（Ｐルータ）として知られている。パケットのパス上にある各ルータは、それ自体のラベル・スイッチング・テーブルを有する。ＭＰＬＳドメインの境界にある発信パケットは、ＰＥルータによってまたは、ＰＥルータの前にあるＭＰＬＳドメイン外部の１つのルータによってそれらのＭＰＬＳラベルが除去され、パケットはＩＰルーティング規則に基づいて配給(serve)される。ＭＰＬＳラベルの使用により、不等価な(un-equivalent)パスの作成、およびその後の異なるパスを通るパケットの送出が可能になる。
【０００８】
ルータにおけるラベル・スイッチング規則は、パケットが送られる前に設定されなければならない。何故なら、ネットワークにおけるラベル配布には特殊なプロトコルが使用されるからである。パケットが送られるときに通るパスも、予め設定される必要がある。割り当てられるパスが、ルーティング・テーブルから推定されるパスとは異なるような方法でラベルを配布することが可能であり、これは、トラフィック設計の要素になる。通常、ルーティング・テーブルにおいて設定されたパスとは異なるパスは、人間の操作者によって統計的に設定されており、殆どの場合、ＲＦＣ３２０９（ＲＦＣ５１５１において更新および拡張される）に記載されたリソース予約プロトコル−トラフィック設計（ＲＳＶＰ−ＴＥ）に従う。ＭＰＬＳは、ネットワークの現在のトラフィック負荷に基づく動的なパスの作成および除去を許可せず、操作者によって永続的に設定される。また、ＭＰＬＳは代わりの最適なパスを運営者(operator)のネットワークにおいて発見することも考慮しない。しかしながら、本発明において提案するルータは、代わりの最適なパスを発見することができる。
【０００９】
ルータが宛先ノードまでのルートを選択する方法が、２０１２年に公開された米国特許第６１１４７号において紹介され、この方法では、スループット、遅延、およびジッタというようなメトリックが考慮される。この特許では、２つのノード間に様々なパスが確立され、ルーティング・テーブルに書き込まれ周期的に更新される。その結果、最も効果的なパスをいずれの所与の時点においても選択することができる。
【００１０】
ＩＰネットワークにおけるマルチパス・パケット・ルーティングのための同等の方法が、米国特許第ＣＮ２０１１１２４４１８号において紹介された。ここでは、ネットワーク全体についての情報を保持する中央制御システムが、どのパスを選択すべきか判断する。このように、実際のネットワーク状態に基づいて、最適なパスを選択することができる。その主な利点は、遅延の最短化、ネットワークを通じて送信されるトラフィック量の増大、およびジッタの抑制である。しかしながら、集中制御システムは、スケーラビリティの欠如を招く虞がある。
【００１１】
グループに纏められたパケットのマルチパス送信方法が、米国特許第ＷＯ２００６ＥＰ６５９７５に記載されている。集合体は、トラフィック・マトリクスに基づいて選択され、ネットワークにおける中央ポイントによって選択されたパスを通って送信され、送信される総トラフィックを増大させることが目標である。この場合も、欠点の１つは、障害に対してフォーカル・ポイント(focal point)を申し出る中央コントローラである。
【００１２】
移動体ネットワークにおいてパケットを導く方法が、２００７年に公開された米国特許第７２４２６７８号において提案された。この特許は、「エッジ・モビリティ・アーキテクチャ（ＥＭＡ）」と呼ばれることもあり、移動体ネットワークにおいて転送するパケットに対して「移動体改良ルーティング（ＭＥＲ）」を実証した。移動体デバイスのＩＰアドレス変更の結果生ずるシグナリング・オーバーヘッドが抑えられる。これは、古いおよび新しいアクセス・ルータ間における移動体デバイスのステータスを更新するために、ユニキャスト・パッケージを生成することによって可能にされる。
【００１３】
１つのドメインにおいて多数のプロトコルを使用するＩＰネットワークにおけるパケット・ルーティング方法が、米国特許第７１７７６４６号に紹介され、２００７年に公開された。この発明は、１つのドメインにおいて様々なタイプのルーティング更新を使用する方法を紹介する。
【００１４】
選択された送信パス上におけるトラフィック特性の収集および分析に基づいたＩＰパケットの均衡化ルーティング方法が、米国特許第７１３６３５７号において紹介された。収集された情報は、次にネットワークにおける他のルータに配布され、次いで、ルータは、それらのルーティング・テーブルにパスを追加すべきか否か判断する。ルーティング・テーブルにおける同じノード間にいくつかのパスがある場合、トラフィックはこれらの間で均等に分散される（各パスは同じ重みを有する）。
【００１５】
多数のトポロジを有するネットワークにおけるデータ・ストリームのルーティング方法およびシステムが、米国特許第８３２０２７７号において提案された。この提案された解決策では、データ・ストリームに関する重みにしたがって、リソースが比例的に割り当てられる。更に、特定のトポロジのリンク・メトリックも考慮される。トポロジ毎に、別のルーティング・テーブルが維持される。
【００１６】
フロー認識ネットワークにおけるパケットのインテリジェント・ルーティング方法が、ポーランド特許出願第Ｐ．３９８７６１号において提案された。これは、保護フロー・リストの内容に基づいて、選択された発信インターフェースにパケットをどのように送るかについて記載する。フローの最初のパケットがルータに到達するときに、発信インターフェースの識別子が、保護フロー・リストに書き込まれる。次いで、ルーティング・テーブルに基づいて、発信インターフェースが選択される。
【００１７】
ＥＩＧＲＰプロトコルは、"Enhanced Interior Gateway Routing Protocol", ID=16406と称するCisco社の文書に詳細に記載されており、この中で、リンク・コストを判定するために様々なパラメータが使用される。最も重要なのは、リンク帯域幅および遅延である。リンクにおける現在の負荷も観察することができる。しかしながら、このような場合、リンクのコストは頻繁に変化する可能性があり、その結果、ルーティング・テーブルは一層頻繁に更新される。また、ネットワークにおいて作成するループ数の増大を許すことも望ましくない。しかしながら、本発明は、ネットワークをループから保護するメカニズムに基づく。
【００１８】
フロー情報のテーブルは、これらをどのように扱うかについての命令も備えており、OpenFlowスイッチ（このスイッチについての文書の１．４バージョンが、www.opennetworking.orgにおいて入手可能である）において実装された。この文書において紹介されたデバイスは、同様のテーブルを使用するが、異なる方法で動作する。OpenFlowスイッチでは、フロー命令は中央コントローラによって生成され、中央コントローラは、ネットワークにおける全てのデバイスの管理を担当する。本明細書において紹介するデバイスは、独立して動作し、それ自体の新たな登録をフロー・テーブルに作成する。このように、本発明は、OpenFlowスイッチと同様に動作するが、中央コントローラは不要である。その結果、分散制御(decentralised control)が可能となり、価格が抑えられ、消費するネットワーク・リソースが少なくて済み、単一障害点(single failure point)を特徴とせず(feature)、適正にスケーラブルである。
【発明の概要】
【発明が解決しようとする課題】
【００１９】
本発明の目的は、フロー転送テーブル（ＦＦＴ：flow forwarding table）をルータに追加することであり、こうすることによって、ルータは、ＦＦＴの内容に基づいてパケットを扱い、方向制御する(steer)。ＦＦＴの内容自体は、ルーティング・テーブルに基づいて更新される。
【課題を解決するための手段】
【００２０】
本明細書において紹介する発明は、IPネットワーク用に設計された新たなルーティング方法、ＦＡＭＴＡＲ(Flow-Aware Multi-Topology Adaptive Routing)（フロー認識多重技術適応ルーティング）を使用する。フローを表す着信パケットが、ルータによって分析される。次に、これらは、フロー転送テーブル（ＦＦＴ）にしたがって、発信インターフェースに転送される。フロー転送テーブルは、提出する発明に独特な新たなエレメントである。着信パケットによって表されるフローに対応するエントリがない場合、ルータはそのフローのＩＤをＦＦＴに追加するが、このフローのための発信インターフェースは、現在のルーティング・テーブルから選出される(take)。
【００２１】
ＦＡＭＴＡＲは、フローの概念によってネットワーク・トラフィックを識別するという、現在普及している観念を使用する。「フロー」という用語は既に文献から公知であるが、これはむしろ曖昧に解釈される。しかしながら、これは常に２人のエンド・ユーザまたは２つのアプリケーション間において１つの接続に属する情報のストリームである。フローＩＤは、定着した方法の１つにしたがって、本発明に影響を及ぼすことなく、確定することができる。
【００２２】
例えば、フロー認識ネットワーキング（ＦＡＮ）アーキテクチャでは、「フロー」は、時間および空間が特定可能であり同じ一意の識別子を有する、パケットのフライト(flight)と定義する。識別子は、５つのヘッダ・フィールド、即ち、ＩＰアドレス、トランスポート・レイヤ・ポート番号、および使用されるトランスポート・レイヤ・プロトコル（例えば、ＴＣＰまたはＵＤＰ）のＩＤ、のハッシュとして計算される。
【００２３】
本発明の新規性は、ネットワークにおいてフローを制御するために使用される方法にある。パケット毎に、発信インターフェースがＦＦＴから（ルーティング・テーブルからではなく）選出され、新たなフローのパケットが出現すると直ぐにＦＦＴエントリが追加され、ルーティング・テーブルが変化しても不変のままである。
【００２４】
ルータとは、ＯＳＩモデルの第３レイヤにおいて動作し、コンピュータ・ネットワークを接続するために使用されるネットワーク・デバイスである。これは、スイッチング・ノードの役割を果たす。
【図面の簡単な説明】
【００２５】
【図１】図１は、 ＦＡＭＴＡＲルータのレイアウトである。
【図２】図２は、フロー転送テーブル（ＦＦＴ）の構造を示す。
【図３】図３は、出力インターフェース・セレクタのブロック図である。
【発明を実施するための形態】
【００２６】
提出する発明を図１に示す。これは使用例も表す。
【００２７】
ルータは、入力インターフェース、出力インターフェース・セレクタ、スイッチング・マトリクス、ルーティング・テーブル、ＣＰＵ、および出力インターフェースで構成される。各着信パケットが分析される。出力インターフェース・セレクタは、ルーティング・テーブルからの情報に基づいて適正な出力インターフェースを決定し、この情報をスイッチング・マトリクスに渡す。スイッチング・マトリクスは、物理的にパケットを適正な発信インターフェースに転送することを担当する。発信ポート・セレクタおよびスイッチング・マトリクスの動作は、ＣＰＵによって制御される。
【００２８】
各ルータの１つのエレメントは、そのルーティング・テーブルであり、パケット・ヘッダにおいて発見される宛先ＩＰアドレスに基づいて、各パケットを転送すべきインターフェースについての情報を収容する。したがって、ルーティング・テーブルは、着信パケット毎に参照される。ネットワークにおいて変化が発生したとき（例えば、障害後、新たなネットワーク、リンク、デバイス、ルーティング方針変更の後等）、ネットワークにおける全てのルータのルーティング・テーブルが更新される。ルーティング・テーブルの更新は、この更新後に到達する全てのパケットに影響を及ぼす。
【００２９】
本発明において提案し図１に示したルータ・アーキテクチャにおける新たなエレメントは、前述したフロー転送テーブル（ＦＦＴ）である。ＦＦＴは、所与のフローに属するパケットが転送される発信インターフェースの識別子を収容し、発信ポート・セレクタによって参照される。フロー識別子に基づいて、発信インターフェース識別子が得られる。ＦＦＴがフローについての情報を収容する場合、ルーティング・テーブルは発信インターフェース・セレクタによって参照されない。これは、技術的現状に対する著しい新規性である。何故なら、現行のルータでは、パケット毎にルーティング・テーブルが参照されるからである。本発明では、あるフローがＦＦＴに存在しない場合、新たなエントリがＦＦＴにおいて作成され、発信インターフェースは現行のルーティング・テーブルから選出される。
【００３０】
ルーティング・テーブルとは異なり、ＦＦＴは静的である。一旦作成されると、エントリは、１つの例外であるタイムスタンプを除いて、変化しない。タイムスタンプは、フローの最後のパケットが出現した時刻であり、パケット毎に更新される。タイムスタンプに基づいて、各フローの最後のパケットの出現からの経過時間を判定することが可能になる。
【００３１】
本発明では、リンク上で輻輳が発生すると、ルーティング・プロトコルにおいてリンク・コストが上昇し、輻輳を示す最大コスト値または特殊値を取る。この結果、適用されるルーティング・プロトコルがコスト変化情報を伝搬し、新たなコストを用いて、ルートを再計算する。ルータにおけるルーティング・テーブルは変化し得るが、本発明では、ＦＦＴは不変のままである。これが意味するのは、更新の間ＦＦＴに存在しない識別子を有する新たなフローだけが、ルーティング・テーブル変更の影響を受けるということである。更新の間ＦＦＴリスト上に存在するアクティブなフローは、変更による影響を受けない。この挙動のために、輻輳の時間中、新たなフローは代わりのパスに沿って導かれ、一方既存のトラフィックは全て、変更なく、既存のパスを通って移動する。
【００３２】
図２は、ＦＦＴの構造を示す。ＦＦＴは、ルータの物理メモリに格納され、少なくとも以下のフィールドを含む。
【００３３】
・フロー識別子
・ルータ発信インターフェースの識別子。それぞれのフローに属するパケットは、このインターフェースを通って送られる。
【００３４】
・あるフローに属し最後に配給されたパケットの到達と、このフローに属する到達パケットとの間における正確な時間間隔の指示を可能にするテーブルのエントリ。既定の時間期間ｔの間、このフローに属する新たなパケットが出現しない場合、そのＦＦＴエントリは除去される。時間ｔが経過した後に、除去されたフローに属するパケットが現れた場合、これは新たなフローとして扱われる。
【００３５】
ルータが使用する発信インターフェース・セレクタについての動作方式(operating schema)を図３に示す。ＩＰパケット・ヘッダのそれぞれのフィールドに基づいて、フロー識別子を確定する。次いで、この識別子がＦＦＴ内に存在するか否か判断する（Ａ）。フロー識別子がＦＦＴ内に存在する場合、ルータにおける発信インターフェース番号を読み取り（Ｂ）、パケットをそれに導く。次に、「最後のパケットの到達時刻」値を更新する（Ｅ）（現在時刻で表すことができる）。ルータのスイッチング・マトリクスを使用して、ＦＦＴによって示されるインターフェースにパケットを送る（Ｆ）。フローがＦＦＴにおいて発見されない場合、ルータのルーティング・テーブルからそれぞれの発信インターフェースを読み出す（Ｃ）。このフローの識別子を、このフローに属するパケットを導くべき発信インターフェースの番号と共に、ＦＦＴに追加する（Ｄ）。本手順の残りは、以前と同様である。即ち、「最後のパケットの到達時刻」値を更新し（Ｅ）（現在時刻を登録してもよい）、ルータのスイッチング・マトリクスを使用してＦＦＴによって示されるインターフェースにパケットを送る（Ｆ）。
【００３６】
提案した発明の本質は、ネットワークにおけるネットワーク動作および情報転送については、ＦＦＴにエントリを最初に配し次いでパケットを発信インターフェースに送るのか、または最初にパケットを発信インターフェースに送り次に関係するエントリをＦＦＴに書き込むのかは関係ないという事実にある。
【００３７】
情報転送およびＦＦＴにおけるエントリの配置(placement)順序は一般には無関係であるが、最初にパケットを送り次いでＦＦＴにエントリを追加する方が良く、こうすると、パケット転送遅延が最少になる。
【００３８】
ＩＰｖ４プロトコルでは、生存時間（ＴＴＬ）フィールドは、パケットがそのパスにおいて行うことができるホップの最大数の数値を収容する。このパスに沿った後続のルータは、先行する各パケットのＴＴＬフィールドの値を１だけ減算する。ルータが、ＴＴＬが０に等しいパケットを得た場合、このパケットは欠落させられ、ネットワークから除去される。この手順は、ルーティング・パスが構成し損ねたルータを含むとき、または他の障害が発生したときに輻輳を回避するのに役立つ。ＩＰｖ６では、ホップ限度というフィールドが同じ役割を果たす。
【００３９】
新たなフローをＦＦＴに追加するとき、ＩＰｖ４パケット・ヘッダからのＴＴＬ値またはＩＰｖ６パケット・ヘッダからのホップ限度を格納することが有益である（どのプロトコルを使用するかによって異なる）。次に、着信パケット毎に、パケット・ヘッダにおけるＴＴＬ（またはホップ限度）が、対応するフローに対してＦＦＴに格納された値と一致するか否か、ルータがチェックする。双方の値が同じ場合、先に紹介した手順にしたがって、パケットを転送する。値が一致しない場合、パケットによって表されるフローをＦＦＴから消去し、パケット処理手順を再開する。このように、ＴＴＬ（またはホップ限度）の不一致を観察した後、所与のフローに対するパスを変更するとよい。何故なら、このフローの記録はＦＦＴから消去され（記録されたパケット転送インターフェースと共に）、次いで作成し直されるが、発信インターフェースは現在のルーティング・テーブルから選出したものであるからである。
【００４０】
これは、ＦＡＭＴＡＲの別の利点を表す。何故なら、これはループの出現を排除するからである。障害の発生時、またはいずれかのリンク・コストが変化した後、ルーティング・プロトコルは、それぞれのルーティング・テーブルを更新するためにある程度の時間を要するので、ＦＡＭＴＡＲにおけるループは、標準的なネットワークにおけるよりも頻繁に出現する可能性がある。変更が生ずる前にネットワークに出現したフローは、適正なインターフェースに結び付けられ、ＴＴＬ（またはホップ限度）フィールドをチェックすることなく、これらのインターフェースは決して変更されない。このように、ルーティング・テーブルにおける単純な変更では解決されないループが発生する可能性がある。
【図１】
2015057879.tif 000003
【図２】
2015057879.tif 000004
【図３】
2015057879.tif 000005
【外国語明細書】
2015057879000001.pdf