JP3676989B2 - 新たに規定されたカスタマーネットワークルートの通知を検証する方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、カスタマーが行ったルート通知が、通知されたルート上でカスタマーへ到来する（inbound）パケットが確実に受信されるために正確であることを保証するための技術に関する。
【０００２】
【従来の技術】
インターネットの極めて高い人気のために、インターネット自体、及びそれに接続されるネットワーク上の両方でデータ通信トラフィックの急増がもたらされている。その結果、エイ・ティ・アンド・ティ・ワールドネット（商号）などのインターネットへのアクセスを提供するインターネットサービスプロバイダ（ＩＳＰ）は、自身がより大きくなり、より多くの利用可能なルートを提供してきた。ＩＳＰを経由して特定のカスタマーへの、利用可能なより多くのルートを備えるために、通信を阻害するようなブロックされたルート（blocked route）の発生確率が減らされる。
【０００３】
【発明が解決しようとする課題】
多くの場合、特定のＩＳＰを利用するカスタマーは、カスタマーサービスＩＳＰを通る利用可能なルートをデータの送り手に知らせる（すなわち、通知する）ので、送り手から到来する（inbound）データはカスタマーに届く。一度カスタマーが特定のルートを知らせると、そのルートは、カスタマーサービスＩＳＰ及びそこへのトラフィックのルートを定める別のＩＳＰによる変更なしに、利用できる状態が保たれる。通知されたルートに対して変更が行われると、そのルートを通ってカスタマーに向けられた到来パケットが意図した宛先に届かなくなる可能性がある。
【０００４】
このため、カスタマーによるルートの通知が、変更されずに正確にカスタマーサービスＩＳＰから別のＩＳＰに確実に送られるようにするための技術に対する要求がある。
【０００５】
【課題を解決するための手段】
簡単に言えば、本発明の好ましい実施形態によると、新たに規定されたカスタマールートの追加、及び前に規定したルートの取消を検証する方法が提供される。カスタマーからの新ルートの情報がルート規定システムにおいて受信されたとき、又は現在ルートの取消の通知についての要求が行われたときに、この方法による動作を開始する。新ルート通知の要求が受理されると、この新ルートは検証され、検証できない場合は拒絶される。（一般に、取消を求めるカスタマーの有効性検証を行うことは好適ではあるが、現在ルートの取消を検証することは必ずしも必要でない。）この後、新ルート（又は、現在ルートの取消）は公式のルーティング用データベースに入力され、この情報はこの後、カスタマーサービスＩＳＰ及び外部のＩＳＰの両方に対して利用可能にされる。最後に、新ルートのアドレス（又は、古いアドレスの削除）が有効であることのチェックが全てのＩＳＰについて行われる。
【０００６】
【発明の実施の形態】
図１は、１つ以上のネットワークアクセスプロバイダに対してカスタマー１２が行った、新ルートの通知又は現在ルートの取消の通知を検証する能力を有する通信ネットワーク１０を開示している。これらの１つ以上のネットワークアクセスのプロバイダは、それぞれがインターネットへのアクセスを提供するインターネットサービスプロバイダ１４，１６，及び１８の形態をとっている。一般的に、カスタマー１２は、データの送り手から到来するデータを受信するための、利用可能なルートを通知する。もし、カスタマーへのサービスを行っているＩＳＰ（例えば、ＩＳＰ１４）又は他のいずれかのＩＳＰ（例えば、ＩＳＰ１６及びＩＳＰ１８）が、そのルートに対して変更を加えて、その変更の他の部分を変更しない場合には、通知されたルートは間違ったものになることがあり、通知されたルート上にルート制御された入力データはカスタマー１２に届かない可能性がある。
【０００７】
本発明の実施の形態に係る方法は、図１に番号で示されている以下のステップによって、新ルートの通知（又は、現在ルートの取消の通知）を都合良く検証する。
【０００８】
［ステップ１］
カスタマー１２は、ＩＳＰ１４，１６及び１８を介してインターネットに通知するために、新ルート（又は現在ルートの取消）の情報をルート規定システム２０に入力する。カスタマーは、そのような新ルート又はルートの取消を静的に又はボーダーゲートウェイプロトコル（ＢＧＰ）を経由して通知することができる。一般に、カスタマー１２は、ルート通知又はルートの取消をルート規定システム２０に、ウェブインターフェースを介して入力するが、カスタマーはそのような情報を別の方法で入力することもできる。
【０００９】
［ステップ２］
ルート規定システム２０は、カスタマー１２が入力した新ルートについての認証チェックを実施する。この検証には、以下のチェックが含まれる。
【００１０】
・発信カスタマー１２は、公式にネットワークアドレスを所有していること（このために、ルート規定システム２０は、現在存在している「ＷＨＯＩＳ」データベースなどの、インターネットのネットワークアドレスレジストリー用データベース２２に問い合わせを行う）のチェック。
【００１１】
・新しいネットワークアドレスと、既に規定済みになっているすべてのネットワークアドレスとの間に、衝突がない（このために、ルート規定システム２０は、内部カスタマー規定用データベース２４及び公式のルーティング用データベース２６に問い合わせを行う）ことのチェック。
【００１２】
・新しいネットワークアドレス（すなわち、AS＿ORIGIN）についての代替ルートの通知がある（このAS＿ORIGINは、そのネットワークアドレス通知についてカスタマーが入力したＡＳＮ（自律システム番号；Autonomous Systems Number）に相当するそのルート通知のカスタマーのネットワークについての発信自律システム番号（originating Autonomous System Number）である）ことのチェック。尚、この判断を行うために、ルート規定システム２０は、ＩＳＰ１４，１６及び１８からインターネットルーティング用テーブルを集めるピアモニタリング（PEERMON）サーバ２８に問合せを行う。
【００１３】
・他のローカルポリシーが満足されることのチェック。例えば、ＩＳＰによっては、カスタマーが通知したルートのサイズを、ルートは２４ビット以下（/24）というように限定するものがある。
【００１４】
カスタマー１２がルート規定システム２０に入力したルートが、前述した有効性確認ステップのいずれかに適合しない場合は、ルート規定システムはこのルート通知を拒絶する。
【００１５】
現在ルートの取消の通知は、一般に、検証を必要としない。従って、ステップ２はそのような環境のもとでは不要になる。しかしながら、ルート規定システム２０は、そのような取消を求めるカスタマーがそうすることを確実に認定されるために、通知したルートの取消を要求するカスタマーを有効性確認するようにしてもよい。
【００１６】
［ステップ３］
カスタマーが入力した新しいルート通知を有効性確認した後、ルート規定システム２０は、有効性が確認された新しいネットワークのアドレスをＩＳＰに対する公式のルーティング用データベース２６に入力する。現在ルートの取消通知は、同様に、ＩＳＰに対するルーティング用データベース２６に入力される。
【００１７】
［ステップ４］
有効性が確認された、カスタマーが入力したルート情報（新ルート又は現在ルートの取消）を受信した後、公式のルーティング用データベースは、ＰＥＥＲＭＯＮサーバ２８の他に、ルータ３０，３２及び３４などの１つ以上の内部（internal）ＩＳＰ用ルータに、新たに規定されたルート通知（又は現在ルートの取消の通知）を送る。これらのルータは、ＩＳＰ１４，１６及び１８に対する外部からの通知に責任がある。
【００１８】
［ステップ５］
内部ＩＳＰ用ルータ３０，３２及び３４は、ＩＳＰ１４，１６及び１８に対して確立されたピア接続を介して、これらのＩＳＰに対して使用できる新ルートの通知（又は現在ルートの取消の通知）を作る。公式のルーティング用データベース２６内でＩＳＰ１４，１６及び１８に対して、新しいネットワークアドレス又は現在アドレスの取消を実際に通知するのはこのステップである。
【００１９】
［ステップ６］
所定の間隔で、ＰＥＥＲＭＯＮサーバ２８は、外部（External）ＩＳＰ（ＩＳＰ１４，１６及び１８）の少なくとも１つ、また好ましくは全てからのルーティングテーブルを自動的に検査して、新しいネットワークアドレス又は現在ルートの取消の通知が発信ＩＳＰによって通知されものとして現れることを検証する。一般に、ＰＥＥＲＭＯＮサーバ２８は、Kevin L. D'Souzaの名前で２０００年２月１日に出願され、エイ・ティ・アンド・ティ（商号）に譲渡された、「Method for Detecting Route Advertisement Violations in a Network Of Interconnected Peers」という名称の、米国特許出願第０９／４９５，１１２号の中に記載された方法で、そのような検査を実行する。この特許出願は、参照することによって本願に組み込まれる。
【００２０】
［ステップ７］
ＰＥＥＲＭＯＮサーバ２８が、特定のＩＳＰのルーティングテーブルの中に新ルート（又は現在ルートの取消）が存在していることを確かめるたびに、サーバはそのＩＳＰ及びカスタマー１２に通知する。前述したように、ＰＥＥＲＭＯＮサーバ２８は、ルート通知（新ルート及び現在ルートの取消の両方）内のエラーを連続的かつ自動的に進行ベース（on-going basis）でモニタして、カスタマー及び発信ＩＳＰにしかるべき注意をうながすために通知する。
【００２１】
前述したことは、ルート通知の変更を検証するための技術を説明している。
【００２２】
前述した実施形態は、単に、本発明の原理を説明しているに過ぎない。当業者は、本発明の原理を具体化すると共に、本発明の精神と範囲に入る種々の修正及び変更を行うことができる。
【００２３】
本発明のある実施態様では、相互に接続されたＩＳＰ同士が各ＩＳＰがサービス提供しているカスタマーへの通信経路（ルート）を変更する情報（経路変更情報）を広く知られたＢＧＰ４プロトコルなどを用いて交換する際に、当該情報の有効性を確認するべく、以下の確認を行う。すなわち、対象となっているカスタマーが当該情報通りのアドレスを有しているか否かをＷＨＯＩＳデータベースを用いて確認し、さらに現在設定されている経路情報との間に矛盾がないか（同一の経路で別のカスタマーが特定されていないか等）を確認する。さらに、代替経路情報があるか否か（ピアモニタリングサーバ２８が集積する経路情報を用いて確認可能である）、ＩＳＰごとの管理ポリシーが満足されることなどについても確認が行われる。そして、これらの確認により有効でないと判断されるときには、その経路変更情報のデータベース（ＩＲＲ；Internet Route Registry等）への登録を拒絶するのである。
【００２４】
一方、有効であれば、当該経路変更情報をデータベースへ登録し、ＢＧＰ４プロトコルを用いて他のＩＳＰへ通知する。ここで変更前の古い経路の削除要求については、一般に有効性確認は不要であるが、上記と同様にして行っても構わない。
【００２５】
ピアモニタリングサーバ２８は通知先のＩＳＰのルーティングテーブルを検査して通知元からの通知内容通りに設定されているか否かを検証する。ここで、エラーがあるときには、カスタマーと通知元（発信側）ＩＳＰに所定の注意を送信する。
【図面の簡単な説明】
【図１】 本発明の方法を実行するシステムの概略ブロック図を開示する図である。
【符号の説明】
１０ 通信ネットワーク、１２ カスタマー、１４，１６，１８ ＩＳＰ、２０ ルーティング規定システム、２４ カスタマー規定用データベース、２６ 公式のルーティング用データベース、２８ ＰＥＥＲＭＯＮサーバ、３０，３２，３４ ルータ。

Claims (14)

1. データ通信ネットワークにおいて、通知されたルートに対して要求された変更を検証および実行する方法であって、
   ネットワーク規定システムにおいて、（ａ）新ルートの通知又は（ｂ）現在ルートの取消の通知のいずれか一方を行うために、カスタマーが発信したルートの通知を受信するステップと、
   前記カスタマーが発信したルートの通知が前記新ルートの通知の場合、前記新ルートについて認証を行い、認証された場合は前記ルートの通知を有効にし、前記新ルートについて認証されない場合は前記ルートの通知を拒絶するステップと、
   前記カスタマーが発信したルートの通知を公式のルーティング用データベースに入力して、前記ルートの通知をネットワークアクセスのプロバイダに利用可能にするステップと、
   前記ネットワークアクセスのプロバイダの少なくとも１つを定期的にチェックして、前記ルートの通知が有効な状態にあるかどうかを検証するステップと、
   を備えることを特徴とする方法。
2. 請求項１に記載の方法であって、前記新ルートについて認証するステップが、
   （ａ）前記カスタマーが前記新ルートの通知に関連するネットワークアドレスを所有しているかどうかをチェックするステップと、
   （ｂ）全ての現在ルートの通知と前記新ルートの通知との間に、衝突が存在するかどうかをチェックするステップと、
   （ｃ）代替ルートの通知が前記新ルートの通知に対応するかどうかをチェックするステップと、
   （ｄ）前記新ルートの通知がローカルルーティングのポリシーに違反するかどうかをチェックするステップと、
   を備えることを特徴とする方法。
3. 請求項２に記載の方法であって、前記カスタマーが前記新ルートに関連するネットワークアドレスを所有しているかどうかをチェックするステップが、ネットワークアドレスのレジストリーを含むデータベースに問い合わせを行うステップを含むことを特徴とする方法。
4. 請求項２に記載の方法であって、全ての現在ルートの通知と前記新ルートの通知との間に、衝突が存在するかどうかをチェックするステップが、公式ルーティング用データベース及びカスタマー規定データベースに問い合わせを行うステップを含むことを特徴とする方法。
5. 請求項１に記載の方法であって、前記カスタマーが前記ルートの通知をウェブインターフェースを介して入力することを特徴とする方法。
6. 請求項１に記載の方法であって、前記カスタマーが前記ルートの通知をボーダーゲートウェイプロトコルを用いて入力することを特徴とする方法。
7. データ通信ネットワークにおいて、新たに規定されたルートを通知する要求を検証および実行する方法であって、
   ネットワーク規定システムにおいて、新たに規定されたルートを通知するためのカスタマー発信の要求を受信するステップと、
   前記新たに規定されたルートについて認証を行い、認証された場合前記新たに規定されたルートについての通知を有効にし、認証されない場合前記ルートについての通知を拒絶するステップと、
   前記カスタマー発信のルートの通知を公式のルーティング用データベースに入力して、前記ルートの通知をネットワークアクセスのプロバイダに対して利用可能にするステップと、
   前記ネットワークアクセスのプロバイダの少なくとも１つを定期的にチェックして、前記ルート通知が有効な状態にあるかどうかを検証するステップと、
   を備えることを特徴とする方法。
8. 請求項７に記載の方法であって、前記新ルートの通知を有効にするステップが、
   （ａ）前記カスタマーが前記新ルートの通知に関連するネットワークアドレスを所有しているかどうかをチェックするステップと、
   （ｂ）全ての現在ルートの通知と前記新ルートの通知との間に、衝突が存在するかどうかをチェックするステップと、
   （ｃ）代替えルートの通知が前記新ルートの通知に対応するかどうかをチェックするステップと、
   （ｄ）前記新ルートの通知がローカルルーティングのポリシーに違反するかどうかをチェックするステップと、
   を備えることを特徴とする方法。
9. 請求項８に記載の方法であって、前記カスタマーが前記新ルートの通知に関連するネットワークアドレスを所有しているかどうかをチェックするステップが、ネットワークアドレスのレジストリーを含むデータベースに問い合わせを行うステップを含むことを特徴とする方法。
10. 請求項８に記載の方法であって、全ての現在ルートの通知と前記新ルートの通知との間に、衝突が存在するかどうかをチェックするステップが、公式ルーティング用データベース及びカスタマー規定データベースに問い合わせを行うステップを含むことを特徴とする方法。
11. 請求項７に記載の方法であって、前記カスタマーが前記ルート通知の変更をウェブインターフェースを介して入力することを特徴とする方法。
12. 請求項７に記載の方法であって、前記カスタマーが前記ルート通知の変更をボーダーゲートウェイプロトコルを用いて入力することを特徴とする方法。
13. データ通信ネットワークにおいて、通知されたルートの要求された取消を検証および実行する方法であって、
    ネットワーク規定システムにおいて、現在ルートの通知を取消ためのカスタマー発信の要求を受信するステップと、
    前記カスタマー発信のルート取消要求を公式のルーティング用データベースに入力して、前記ルートの取消要求をネットワークアクセスのプロバイダに対して行うステップと、
    前記ネットワークアクセスのプロバイダの少なくとも１つを定期的にチェックして、前記ルート取消要求が有効な状態にあるかどうかを検証するステップと、
    を備えることを特徴とする方法。
14. 請求項１３に記載の方法が、前記ルート取消要求を行う前記カスタマーが当該要求権限を有するか否かを検証するステップをさらに備えることを特徴とする方法。

Images