JP2003516035A - キャラクタリスティックルーティング - Google Patents

キャラクタリスティックルーティング

Info

Publication number
JP2003516035A
JP2003516035A JP2001541194A JP2001541194A JP2003516035A JP 2003516035 A JP2003516035 A JP 2003516035A JP 2001541194 A JP2001541194 A JP 2001541194A JP 2001541194 A JP2001541194 A JP 2001541194A JP 2003516035 A JP2003516035 A JP 2003516035A
Authority
JP
Japan
Prior art keywords
packet
node
routing
index
bit vector
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.)
Pending
Application number
JP2001541194A
Other languages
English (en)
Inventor
シー ネイヴァス ジュリオ
Original Assignee
シーメンス テクノロジー−トゥー−ビジネス センター、リミテッド ライアビリティ カンパニー
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 シーメンス テクノロジー−トゥー−ビジネス センター、リミテッド ライアビリティ カンパニー filed Critical シーメンス テクノロジー−トゥー−ビジネス センター、リミテッド ライアビリティ カンパニー
Publication of JP2003516035A publication Critical patent/JP2003516035A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/26—Route discovery packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/365—Application layer names, e.g. buddy names, unstructured names chosen by a user or home appliance name

Landscapes

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

Abstract

(57)【要約】 キャラクタリスティックルーティングと呼ばれるルーティングプロトコルによれば、（指標と称する）多数の任意の記述的識別名のかたちをとる受信側ノードの記述を利用して、送信側から一群の受信側ノードへ向けてインターネットワークを介してマルチホップでデータを伝送できるようになる。ホストノードは、マルチプルかつダイナミックな指標をもつことができる。キャラクタリスティックルーティングは、マルチプルネームをもつ状況でオペレーションを高速にするよう最適化されている。たとえばキャラクタリスティックルーティングにより、ビットベクトルおよび圧縮技術を利用して効率的なルーティングテーブルインデックスが生成される。キャラクタリスティックルーティングの利用にあたり、受信側ノードがキャラクタリスティックルーティングアドレスまたはルーティングアドレスにおける所定の指標と正確にマッチしていなければならないのか、受信側ノードがキャラクタリスティックルーティングアドレスと似ているだけでよいのか、あるいは受信側ノードが指標の所望の範囲をもつのかを、送信側が選択できる。

Description

【発明の詳細な説明】
【０００１】 関連する出願に対する相互参照 本特許出願（non-povisional）は本出願人のＵＳ特許出願番号６０／１６８４
２６（１９９９年１１月３０日付け）（povisional）および本出願人のＵＳ特許
出願番号６０／２１３６６６（２０００年６月２３日付け）（povisional）（両
方とも名称「キャラクタリスティックルーティング（Charasteirc Routing）」
であり、発明者は Julio Cesar Navas らがいる）に基づく優先権を主張するも
のである。
【０００２】 本発明の背景 本発明はネットワークデータトランスポートに関する。もっと特定すれば、本
発明は、マルチプル識別記述名または「指標（characteristics）」の形の宛先
ノードの集合の記述を使用した、送信機ノードからインターネットワークを介す
る複数の宛先ノードセット（集合）へのデータの実際に高速なマルチ・ホップ・
ルーティングを可能にするネットワーク・ルーティング・プロトコルに関する。
【０００３】 従来のネットワークデータトランスポートアプローチは、特定の指標の組み合
わせに基づいている、送信機からインターネットワークを介する複数の宛先ノー
ドへのデータの高速にマルチ・ホップ・ルーティングを提供するにはその能力が
制限されていることが多い。この場合この組み合わせは送信されるデータの形式
に依存して送信機によってダイナミックに変更することができる。次にこれらの
従来のアプローチについて説明する。
【０００４】 従来のネットワークデータトランスポートの最も普通の形式は殊にインターネ
ットにおいては「ユニキャスティング」である。ユニキャスティングでは、イン
ターネットワークにおける複数のコンピュータホストが単一の独自の識別子また
は「名前」を有していることおよびデータが単一の送信機ノードから単一の受信
機ノードに送信されるものであるであることが仮定されている。しかし、このユ
ニキャスト名は純然と機能的であって、記述的ではない。インプリメンテーショ
ン（具体化実現）効率は固定されたアドレスストラクチャおよびインターネット
アドレス分配パターンに依存している。インターネットアドレス分配パターンは
、あるネットワークまたは関連のネットワーク上のホストのすべてが同じアドレ
スプレフィックスを共有する仕方で同じネットワーク上のホストに名前を割り当
てるものである。特に、従来のルータは単一のホスト名に対して最適化されてい
る。というのは、これらは、正確には３２ビットを有しているホストの単一のイ
ンターネットプロトコル（ＩＰ）に依拠しているパトリシア・ツリーズ（patric
ia trees）と称されるデータストラクチャを使用することが多いからである。機
能に正確にユニキャスティングするために、ルータのすべては、データを伝送す
ることができるようにする前にネットワークのトポロジーを発見するいくつかの
ルーティングプロトコルを使用できる状態でなければならない。これは、データ
の特定のパケットが引き渡し可能であるか否かを直接分かっていることができる
という利点を有している。それは、各ルータが可能な宛先の独自のリストを自ら
のルーティングテーブルに有しているからである。
【０００５】 インターネットワークを介するメッセージをルーティングするための最も普通
のユニキャスティングプロトコル、または「リンク・ステートルーティング」（
リンク・ステートルーティングの最も普通の実例は、“OSPF Version 2”（１９
９８年４月）というタイトルで RFC 2328 において J. Moy により記載されてい
るような“OSPF Version 2”（１９９８年４月）およびリンク・ステートルーテ
ィングの別のバージョンもＵＳ特許明細書第５１２８９２６号（Perlmann et al
.）に開示されている）を使用して、各ルータはネットワークのトポロジーにつ
いての情報を予め収集し、それからその情報からユニキャストルーティングテー
ブルを抽出する（distill）。それからルータはこの情報を使用して、送信機か
ら受信機への最良の経路を決定することができ、かつ最初（オリジナル）のネッ
トワークのトポロジー情報はこれらルータによって保持される。ネットワークに
ついて収集された情報は有利なルートまたはマルチキャストメンバシップを含ん
でいることができる（それは“MOSPF：Analysis and Experience”というタイト
ルで RFC 1585 に J. Moy により記載されているようなものである（１９９４年
３月））。すべてのホストおよびネットワークは単一の１次アドレスだけを有し
ているものと仮定されている。従って、ユニキャスティングは、送信機からイン
ターネットワークを介して、ノードの独自のアドレスに基づいている１つの宛先
ノードへのデータをルーティングするのに限られている。宛先のような単一の１
次アドレスは一般的なケースであるものと仮定され、かつルーティング・プロト
コルはこの単一のアドレス宛先ケースが最良に動作するように最適化されている
。今日使用されているリンク・ステートルーティングは、ホストが一般的なケー
スとして複数の１次アドレス（または指標）を有していることができるようにす
るためには著しく改良されなければならないものである。
【０００６】 ユニキャスティングに加えて、別の共通の形式の従来のネットワークデータト
ランスポートは「マルチキャスティング」である。これにより、１つの送信機か
ら受信機グループへ、グループに対して単一のアドレスを使用してインターネッ
トワークを介してデータを送信することが可能である。マルチキャスティングに
よれば、すべてのホストおよびネットワークは、ユニキャスティングに対する単
一の１次アドレスを有することに加えて、複数のマルチキャスティングアドレス
を有することも許容されている。マルチキャストプロトコルは、S. Deering 著
の“Multicast Routing in a Datagram Internetwaork”掲載の Ph. D. thesis
に記載されている（Stanford Technical Report STAN-CS-92-1415, Dept. of Co
mputer Science, Stanford University, December 1991）。マルチキャストグル
ープは「オープンである」と考えられる。というのは、誰でも、彼らが該グルー
プのメンバーであるか否かに拘わらず、データをマルチキャストグループに送信
することができるからである。このグループはシングルアドレス（単一のアドレ
ス）によって定義されており、かつコンピュータホストは、マルチキャスト伝送
の受信を開始するまたは終了するためにマルチキャストグループにジョイントす
るかまたはそこを離れるかをダイナミックに選択することができる。しかしグル
ープメンバーは匿名にとどまり、かつ送信機がグループの規模を知らないことす
らしばしばである。それ故に送信機は、誰かが実際に、伝送されたデータを受信
しているかどうかを分かっていない（マルチキャスティングは、ラジオプログラ
ムを特定のチャネルでブロードキャストしかつブロードキャストを受信したいと
望む人がこの特定のチャネルに同調することができるというラジオ局に類似して
いる）。各ホストは沢山あるマルチキャストグループのメンバーであるわけであ
り、それ故に複数の「名前」を持っていることができる。しかし、ホストは同時
には１つのグループかまたは名前によってしかアドレス指定されることはできな
い。というのは、グループアドレスはいずれか効果的な方法で組み合わせること
はできないからである。それ故に、受信機の匿名性故に、ルータがデータをどこ
へ引き渡すかを知っていないという理由でマルチキャスティングは十分なものと
は言えない。
【０００７】 マルチキャスティングの不十分性を解決するための２つの従来のアプローチは
「デンス・モード・マルチキャスト（dense-mode multicast）」および「スパー
ス・モード・マルチキャスト（sparse-mode multicast）」である。次にこれら
について説明する。デンス・モード・マルチキャストは、Deering の Ph. D. th
esis に最初に取り上げられかつ RFC 1585（両方とも上に掲げている）に論述さ
れているアプローチによって形式化されている。スパース・モード・マルチキャ
スティングは、“Protocol Independent Multicast-Sparse Mode（PIM-SM）：Pr
otocol Specification”（１９９８年６月）というタイトルで RFC 2362 に D.
Estrin によって述べられている。
【０００８】 デンス・モード・マルチキャストプロトコルはマルチキャスト受信機匿名性問
題を、インターネットワークを介して第１のパケットをブロードキャストして誰
もに届くようにすることによって解決している。このデータ流を受信したくない
ホストの面々はプルーンメッセージ（prune message）を送信機に返送すること
によって抜け出なければならない（opt out）。最終的な結果は、ルータが送信
機から受信機への最短のパス・ツリーを持っていることである。しかしこのツリ
ーを決定するためには最初のブロードキャストが使用されなければならないので
、デンス・モード・マルチキャストはネットワークにやさしいプロトコルとは考
えられない。ＵＳ特許第４７４０９５４号（Cotton et al.）では、最初のブロ
ードキャストが通過しなければならなかったネットワーク規模のスキャニングツ
リーを示すことによってオリジナルの構想（デザイン）を改善しようとした。し
かしこのアプローチではまだ、最初のブロードキャストを使用する必要がある。
【０００９】 他方において、スパース・モード・マルチキャスト・プロトコルでは、マルチ
キャストグループ「コーディネーター」が使用されて、マルチプル受信機匿名性
問題を解決しようとしている。１つのマルチキャストグループに対して第１の送
信機または受信機が出現するとき、最も近いルータがこのマルチキャストグルー
プに対するコーディネーターになりかつただちにすべての他のルータに、このグ
ループに対するコーディネーターであることを知らせ始める。このマルチキャス
トグループに対するデータ流を受信する希望があるホストはそこで、コーディネ
ーターに彼らが受信機になりたいことを特別に表明することによって参加しなけ
ればならない（opt in）。最終的に、コーディネーターは、根っこ（ルート）が
該コーディネーターであるコア・ベースド・ツリーと称される、このマルチキャ
ストグループに対するシングルツリーを生成する。シングルツリーを使用するこ
とで、スパース・モード・マルチキャストプロトコルでは極めて崩壊（disrupti
on）されにくいワイドエリアのインターネットワーク上での使用が可能になる。
しかし、送信機から複数の受信機から成るセットへデータを運ぶ経路、すなわち
パスは最適な最短経路ではない。ＵＳ特許第５３５５３７１号明細書（Auerbach
et al.）ではスパース・モードプロトコルを次のようにして洗練化した。すな
わちツリー・リーダーまたはコーディネーターが新しいマルチキャストグループ
に対してグループアドレスをダイナミックに指定するのである。このことは、グ
ループアドレスの独自性を保証するためにすべての受信機とのネゴシエーション
によって行われる。
【００１０】 マルチキャスティングの他に、他の従来のデータ伝送システムはコンピュータ
ホストがマルチプルネーム（複数の名前または多重名とも考えられる）を持つこ
とを許可するかまたは受信機の指標を使用して、特定のユーザがブロードキャス
トデータ伝送を受信すべきであるかどうかを決定している。しかし、このような
システムには、次に説明するように、種々様々な問題がある。
【００１１】 特定のユーザがブロードキャストデータ伝送を受信すべきであるかどうかを決
定するために受信機の指標を使用している従来のシステムが、米国特許第５６３
６６２４５号明細書（Ernst et. al）に記載されている。このシステムは、一般
の送信機による情報ブロードキャストがユーザのロケーション、速度、および／
または時間に基づいている特定のユーザにとって重要であるかどうかを決定する
情報無線ブロードキャスティングシステムである。１つまたは複数の次のものが
それぞれのメッセージを記述することになる：特徴的な地域、速度、イベントに
相応する時間、イベント固有のタグを含んでいるセグメント。選択判断基準も任
意選択的なイベント固有のタグを含んでいてよい。遠隔の端末の受信機は、送信
機からのメッセージを一般的なブロードキャスティングユニットにおいて受信す
る。コンピュータホストはメッセージ中のセグメントを評価しかつこのセグメン
トが記憶されている選択判断基準と整合しているかどうかを決定する。整合が見
つけられると、ホストコンピュータはメッセージを受信する。不都合なことに、
このシステムは、すべての受信機が単一の送信機の範囲内にあることを仮定して
いるので、マルチホップ・ケイパビリティを提供していない。
【００１２】 受信機の指標を使用して、特定のユーザがブロードキャストデータ伝送を受信
すべきであるかどうかを決定するという別の従来のシステムは、米国特許第５０
９５５３２号明細書（Mardus）に記載されている。Mardus のシステムには、送
信機によって車両受信機に対してブローとキャストされたデジタル符号化された
トラヒックアナウンスメントのルート選択的な再生を行うシステムが記載されて
いる。ブロードキャストアナウンスメントにおけるルート固有の指標の比較は受
信機のトリップルートの指標に対して行われる。指標が整合しているならば（あ
る程度のしきい値まで）、ドライバーに対して、該ドライバーに適しているトラ
ヒックアナウンスメントを与えられることになるので、当該ドライバーとって重
要でない多数のトラヒックアドバイサリーによってドライバーが注意をそらされ
ることはない。しかし単一の送信機しか使用しない Mardus のシステムではマル
チ・ホップ・ルーティング・ケイパビリティを提供しないまたはネットワーク帯
域幅の効率的な使用を行えず、かつ Ernst et al によって記載されたシステム
と同じボトルネックおよび故障点発生という不都合がある。Mardus システムは
単純に、情報のすべてを送信しかつ受信機が該受信機に属する情報を取り出すこ
とができるようにするものである。
【００１３】 コンピュータホストが受信機の地理上の指標を使用して、特定のユーザがブロ
ードキャストデータ伝送を受信すべきかどうかを決定するようにする更に別のシ
ステムは“Geographic Addressing and Routing”（Proceedings of the Trird ACM/IEEE International Conference on Mobile Computing and Networking （Mo
biCom'97）, Budapest, Hungary, １９９７年９月２６日〜３０日）において J.
C. Navas および T. Imielinsi によって記載されている。このシステムでは、
地理上の判断基準だけを使用してインターネットワークを介するパケットのルー
ティングが実施される。このシステムにおいては送信側のホストが、ポイント（
地点）が経度および緯度を使用して定義されている境界を持った多角形（boundi
ng polygon）としての宛先を特定することによって、隣接する地理上の地域に対
してパケットをアドレス指定するのである。この地理上の地域内のホストだけが
送信されたメッセージを受信することになる。このシステムもルーティングアプ
ローチを使用して受信機のセットにメッセージを伝送しているが、このシステム
では殊に地理上の判断基準に基づいてしかルーティングされていない。
【００１４】 上に説明してきたシステムとはアプローチの仕方が異なっている、１つの従来
のシステムでは、アドレスのマッピングが行われて、コンピュータホストがマル
チプルネームを持つことができるようにしている。このシステムはドメイン・ネ
ーム・システム（Domain Name System＝ＤＮＳ）で、このシステムでは、複数の
プライベートネットワークにおいてホストがお互い同士交信できるようにし向け
られている。ＤＮＳはＵＳ特許第５７７７９８９号明細書（McGarvery）および
“Domain Names-Implementation and Specification”（１９８７年１１月）と
いうタイトルで P. Mockapetris によって記載されている。別個のＤＮＳシステ
ムはホストネームのそれぞれの「ドメイン」に対して使用されるものでありかつ
それぞれのコンピュータホストはマルチプル「ネーム」を有することが許可され
るということである。このＤＮＳシステムはコンピュータホストがマルチプルネ
ームを持つことを許容しているけれども、それはフレキシブルでない、暴力的な
手法で行われるので、このために多数のオーバヘッドが必要である。特に、第１
のコンピュータホストが特定の名前を有する第２のコンピュータホストと会話し
ようとするとき、第１のホストは、ＤＮＳドメインのすべてとコンタクトして、
これらの１つが所望のホストネームに対するネットワークアドレスを返送してく
るのを待たなければならない。更に、ＤＮＳシステムは宛先ホストのマルチプル
な指標に基づいているルーティングを行ってはいない。
【００１５】 上に述べたことから、インターネットワークにおけるホストがマルチプルな、
識別記述名／指標を持ち、更に、これら名前／指標の任意の組み合わせを使用し
てデータ／メッセージをマルチプルホップを介してマルチプルなレシピエント（
受取人）に効率よく伝送できることが許容されるようにするシステムが要求され
ている。更に、このようなシステムにおいて、データは、データの宛先アドレス
として特定されている名前の任意の組み合わせに正確に整合しているかまたは宛
先アドレスに類似しているだけのホストに配られるべきである。
【００１６】 発明の概要 本発明によれば以下のようなシステムならびに方法が提供される。すなわちそ
れらによってインターネットワーク内のホストはマルチプルな記述的識別名／指
標をもつことができるようになり、しかも多数のホップを介して多数の受け手に
それらの名前／指標の任意の組み合わせを用いて効率的にデータ／メッセージを
伝送することができる。さらに本発明によれば、データをそのデータの宛先に対
して指定された任意の名前の組み合わせと正確にマッチしたホストへ配送するこ
ともできるし、あるいは指定された任意の名前と似ているだけのホストへも配送
できるようになる。
【００１７】 １つの実施形態によれば、多数のノードを含むネットワークを介してパケット
をルーティングする方法が本発明によって提供される。この方法にはネットワー
クを介して送信側ノードからパケットを受け取るステップが含まれており、その
パケットは、送信側ノードによって決定可能な定義された複数の指標をもつ少な
くとも１つのノード宛のものである。定義された複数の指標に関する情報をもつ
パケットは、定義された複数の指標をもつ少なくとも１つの宛先ノードによって
受け取られる。定義された複数の指標は、ネットワーク内の多数のノードのアス
ペクトを表す多数の任意の指標の全体集合である。
【００１８】 別の実施形態によれば、多数の任意の指標の全体集合のうち定義された部分集
合をもつ少なくとも１つの宛先ノードへネットワークを介してパケットをルーテ
ィングするシステムが本発明によって提供される。このシステムにはネットワー
クと結合された多数のノードが含まれている。各ホストノードは多数の任意の指
標から成る全体集合のうち定義された部分集合を選択することができ、その場合
、定義された部分集合をもつすべてのホストノード宛にパケットを送信すること
ができる。パケットは定義された部分集合を有している。各ルーティングノード
は、発見されたネットワークの局所的トポロジーに関して記憶されたローカルキ
ャラクタリスティックルーティングテーブルに基づき、パケットのコピーをフォ
ワーディングすることができる。ルーティングテーブルには、ルーティングノー
ドとローカルに結合された各ノードの固有の指標に基づくエントリが含まれてい
る。
【００１９】 次に、図面を参照しながら上述の実施形態およびその他の実施形態についてさ
らに詳しく説明する。
【００２０】 図面の簡単な説明 図１には、マルチキャストを使用して、名前Ａ，ＢおよびＣの組み合わせを有
しているネットワークノードにメッセージを送信する様子が略示されており、こ
こでそれぞれの名前は、従来のマルチキャストアプローチに従った１つのマルチ
キャストグループを表しており、 図２には、本発明の実施形態に従った、キャラクタリスティックルーティング
を使用して、指標Ａ，ＢおよびＣの組み合わせを有しているネットワークノード
にメッセージを送信する様子が略示されており、 図３には、本発明の有利な実施例に従った、キャラクタリスティックルーティ
ングシステムが略示されており、 図４には、本発明の実施形態に従った、キャラクタリスティックルーティング
ノードの一般化された機能ダイヤグラムが略示されており、 図５には、本発明の実施形態に従った、近似的なキャラクタリスティックルー
ティングを使用して、指標Ａ，ＢおよびＣの組み合わせを有しているネットワー
クノードにメッセージを送信し、かつ余分なルーティングツリーブランチをプル
ーニングする様子が略示されており、ここでは指標の全体集合の近似が使用され
るようになっており、 図６には、従来技術に従った、種々様々なインターネットワークプロトコルの
ネットワーク・スタック・ロケーションが略示されており、 図７には、実施形態に従った、キャラクタリスティックパケットの地球規模で
ユニークな識別子のフォーマットが略示されており、 図８には、実施形態に従った、キャルキャスト・パケットのキャラクタリステ
ィックデスティネーションを作っている２つの要素（指標）を含んでいるキャラ
クタリスティックデスティネーション（または指標のリスト）のフォーマットが
略示されており、 図９には、実施形態に従った、キャラクタリスティックＯＰオプションに対す
るオプション・タイプ・フィールド集合が略示されており、 図１０には、実施形態に従った、キャラクタリスティックルーティングオプシ
ョン拡張を備えたＩＰヘッダが略示されており、 図１１には、別の実施形態に従った、ＩＰヘッダ後すぐにキャラクタリスティ
ックヘッダを使用するキャラクタリスティックルーティングパケットの例が略示
されており、 図１２には、本発明の種々の実施形態に従った、既存のネットワーク・トポロ
ジー・コンフィギュレーション・プロトコルに対するキャラクタリスティック拡
張ＣｈａｒＯＳＰＦ，ＣｈａｒＲＩＰおよびＣｈａｒＢＰのネットワーク・スタ
ック・ロケーションが略示されており、 図１３には、実施形態に従った、ＣｈａｒＯＳＰＦオプションフィールドが略
示されており、 図１４には、実施形態に従った、ＣｈａｒＯＳＰＦに使用されるキャラクタリ
スティック・エリア・ＬＳＡパケットの例が略示されており、 図１５には、別の実施形態に従った、ＣｈａｒＲＩＰパケットが例として略示
されており、 図１６には、別の実施形態に従った、ＣｈａｒＢＰパケットが例として略示さ
れており、 図１７には、実施形態に従った、キャラクタリスティック・ルータのキャッシ
ュにおけるキャッシュ・エントリとキャラクタリスティック・ルータのルーティ
ングテーブルエントリとの間のポインタリンクを示している例が概略的に示され
ており、 図１８には、キャラクタリスティック・ルータのキャッシュが意図せず満杯に
なった場合に、ルーティングツリーの残りからダウンストリームツリーをどのよ
うに効率よく再リンクすることができるかを説明している実施例が略示されてお
り、 図１９および図２０には、実施形態に従った、キャラクタリスティック・ルー
タのキャッシュが意図せず満杯になった場合に生じる潜在的な問題を本発明がど
のように処理するかを説明している実施例が略示されており、 図２１には、ハイアラーキ式のキャラクタリスティックルーティングのための
実施形態に従った、指標が４つのハッシュ関数結果によって表されているように
ｋ＝４を有しているＢｌｏｏｍフィルタとして記憶されているネットワークキャ
ラクタリスティックデスティネーションが略示されており、 図２２には、ハイアラーキ式のキャラクタリスティックルーティングのための
実施形態に従った、キャラクタリスティックリスト７０１（この例は２つのリス
ト要素を有しているＡＮＤリストを示している）の符号化が略示されている。
【００２１】 実施形態の詳細な説明 Ｉ． 一般 II． キャラクタリスティックルーティングシステム Ａ． キャラクタリスティックノードコンポーネント Ｂ． キャラクタリスティックベクトル １． キャラクタリスティックベクトル：指標の閉集合対開集合 ２． 指標の集合の近似 Ｃ． キャラクタリスティックパケット １． ＩＰより下部のインプリメンテーション ２． ネットワーク・レイヤにおけるインプリメンテーション ３． トランスポート・レイヤにおけるＩＰより上部のインプリメ ンテーション ａ． ＣｈａｒＯＳＰＦ ｂ． ＣｈａｒＲＩＰ ｃ． ＣｈａｒＢＰ Ｄ． キャラクタリスティックルーティングフォワーディングキャッシュ およびルーティングツリー III． ハイアラーキ式キャラクタリスティックルーティング実施例 Ａ． 一般 Ｂ． ブルームフィルタを用いた指標の符号化 Ｃ． ネットワークセグメントに関する指標の収集 Ｄ． ルーティングテーブル情報の交換 IV． 結論 Ｉ． 一般 キャラクタリスティックルーティングは新しいルーティング・プロトコルであ
り、これによればデータは、マルチプルな、任意の識別記述名の形の受信機の記
述を使用して１つの送信機からインターネットワークを介して受信機のセット（
一群の受信機）にマルチ・ホップで伝送できるのである。この識別する記述名は
「指標（キャラクタリスティック）」と呼ばれかつ何らかの記述信号語であって
よい。例えば、工場の温度センサは指標「温度（temperature）」および「セン
サ（sensor）」を有していることができる。受信機はマルチプルな指標を有する
ことができること、およびこれらの指標はホストによって獲得されることができ
るが、ダイナミックな仕方で除去されることもできることを指摘しておく。
【００２２】 キャラクタリスティックルーティングを使用することができる適用例は分布さ
れたセンサネットワークの情報管理、工場のオートメーションネットワークの制
御、物体のロオジスティクスまたはロケーションに関するコミュニケーション、
およびメッセージが、送信側のノードによって決められる所定の指標を有してい
るノード／オブジェクトに送信されるのが相応しい環境である。
【００２３】 キャラクタリスティックルーティングは、シングルアドレスルーティングケー
スを高速にするように最適化されているユニキャスティングとは異なって、ネッ
トワーク上のコンピュータホスト当たりにマルチプルネーム、すなわち複数の名
前を許容しておりかつマルチプルアドレスルーティングケースを高速にするよう
に最適化されている。キャラクタリスティックルーティングシステムは効率のよ
いルーティング・テーブル・インデクスを作成しかつパトリシア・ツリー（patr
icia tree）とは異なって、それぞれの宛先がマルチプルな、任意の、構造化さ
れていない名前を有しているものと仮定している。データが１つの送信機から１
つの受信機へと送信されることしか許容されないユニキャスティングとは異なっ
て、キャラクタリスティックルーティングでは、送信機はデータを同時に複数の
受信機に伝送することができる。データを送信するとき、送信機は名前／指標の
任意の組み合わせを使用して、受信機のセットをアドレス指定することができる
。キャラクタリスティックルーティングを使用して、受信機がキャラクタリステ
ィックアドレスと正確に整合することを必要としている（ユニキャスティングと
類似）のかまたは受信機が簡単にキャラクタリスティックアドレスに対して類似
していればいいのかどうかを送信機は選択することができる。
【００２４】 本発明のキャラクタリスティックルーティングはマルチキャストとはいくつか
の観点において相異している。第１に、実施形態において、キャラクタリスティ
ックルーティングは匿名性問題を、修正されたリンク・ステート・ルーティング
・プロトコルを使用して、それに関連したホストのネットワークトポロジーおよ
び名前（または指標）についての情報を先制的に集めることで解決している。パ
ケットが伝送されるとき、この情報はどこにパケットが行くべきであるかを決定
するために使用される。また、送信機は、該送信機が送信するデータが実際に受
信機に到達するかどうかを直接分かっている。というのは、ルータは、当該送信
機のデータが引き渡し可能であるかどうかを当該送信機に知らせるための情報を
十分に有しているからである。第２に、送信機は、当該メッセージに対して向け
られている受信機を定めるために任意の組み合わせの指標を使用することができ
る。しかしマルチキャストではグループ当たり１つのアドレスしか許容されず、
複数のアドレスを効果的な方法で組み合わせて、マルチキャストグループのいく
つかの組み合わせを実現するようにすることはできない。第３に、キャラクタリ
スティックルーティングはデンスモードマルチキャストより一層ネットワークに
やさしい。というのは、送信機から受信機セットへの最短距離にあるルータだけ
がキャラクタリスティックルーティングの作用を受けるからである。第４に、キ
ャラクタリスティックルーティングはスパース・モード・マルチキャストより一
層最適である。というのは、それぞれのルーティング・ツリーはある任意の「コ
ーディネーター」ではなくて当該送信機に根っこを持つ最短のパスルーティング
ツリーだからである。
【００２５】 後で詳しく説明する「キャルキャスト・メッセージ（charcast message）の向
けられた受信機を定めるとき任意の組み合わせの名前（または指標）を使用する
能力は、キャラクタリスティックルーティングがマルチキャストまたはユニキャ
ストのようなその他のルーティング技術に対して有している利点の１つである。
【００２６】 図１および図２において、送信機ノードがメッセージを、特定の指標（例えば
指標Ａ，ＢおよびＣ）を有しているすべてのノードに送信しようとする実施形態
を使用して、マルチキャストルーティングを凌駕するキャラクタリスティックル
ーティングの利点について説明する。特に、図１には、名前Ａ，ＢおよびＣの組
み合わせを有しているネットワーク・ノードにマルチキャストを使用してメッセ
ージを送信する仕方が示されており、ここではそれぞれの名前は、従来技術のマ
ルチキャスト・アプローチに従って１つのマルチキャスト・グループを表してい
る。後で説明するように、図２には、名前Ａ，ＢおよびＣの組み合わせを有して
いるネットワーク・ノードにキャラクタリスティックルーティングを使用してメ
ッセージを送信する仕方が示されており、ここではそれぞれの名前は、本発明の
実施形態に従って１つの指標（characteristic）を表している。図１および図２
では簡単にするために、図示のネットワークノードは名前Ａ，ＢおよびＣ、また
はその組み合わせを有することができるホスト・ノード（図示されていない）が
接続されているルーティング・ノードであり、かつ送信機ノードは、メッセージ
を送信する送信機ホストノードを有しているルーティング・ノードである。
【００２７】 この例において、図１および図２に示されているように、Ａ，ＢおよびＣの名
前を有しているノードが複数存在し、かつ送信機ノードがこれらの名前すべてを
有しているところのノード（換言すれば、名前Ａ，ＢおよびＣを有しているノー
ド）にメッセージを送信しようとしている任意のネットワークを考察する。所望
の３つの名前というこの例において、ノード１０および１５だけが名前Ａ，Ｂお
よびＣすべてを有している。ノード２５，３０，３５，４０，４５，５０，５５
および６０は名前Ａ，ＢまたはＣのいずれも有していない。ノード７０よび７５
は名前Ａだけを有している。ノード８０よび８５は名前Ｃだけを有している。ノ
ード９０は名前ＡおよびＢだけを有している。そしてノード９５は名前Ｂおよび
Ｃだけを有している。
【００２８】 送信機がマルチキャストを使用している図１について、それぞれの名前はマル
チキャスト・グループ・アドレスということになる。マルチキャストそれ自体は
グループの組み合わせに基づいているルーティングを許容していないので、送信
機ノード１０はメッセージを３つの部分に分割しかつそれぞれの部分を種々のマ
ルチキャストグループにマルチキャストすることになる。更に説明するように、
マルチキャストを使用する結果はネットワーク崩壊が比較的大きくなることおよ
び向けられていない受信機が多くなることである。
【００２９】 特に、ノード間をフォワーディングするメッセージを指示している種々の矢印
からわかるように、送信機ノード１０は第１のマルチキャストを第１のマルチキ
ャストグループＡに属するすべてのメンバーに送信し、第２のマルチキャストを
第２のマルチキャストグループＢに属するすべてのメンバーに送信しかつ第３の
マルチキャストを第３のマルチキャストグループＣに属するすべてのメンバーに
送信する。第１のマルチキャストを（破線の矢印が示しているように）グループ
Ａに送信する際に、送信機ノード１０は第１のネットワークメッセージをノード
３５に送信する。ノード３５は第１のネットワークメッセージのコピーをノード
３０に送る。ノード３０はそれから第１のネットワークメッセージのコピーをノ
ード７０および２５に送る。それからノード２５は第１のネットワークメッセー
ジのコピーをノード７０および２０に送り、かつノード２０は第１のネットワー
クメッセージのコピーをノード９０に送り、ノード９０はコピーをノード１５に
送る。第２のマルチキャストを（実線の矢印が示しているように）グループＢに
送信する際に、送信機ノード１０は第２のネットワークメッセージをノード６５
に送信する。ノード６５は第２のネットワークメッセージのコピーをノード４０
に送る。ノード４０はそれから第２のネットワークメッセージのコピーをノード
２０に送る。それからノード２０は第１のネットワークメッセージのコピーをノ
ード７０および２０に送り、かつノード２０は第２のネットワークメッセージの
コピーをノード９０および９５に送る。それからノード９５は第２のネットワー
クメッセージのコピーをノード１５に送る。第３のマルチキャストを（一点鎖線
の矢印が示しているように）グループＣに送信する際に、送信機ノード１０は第
３のネットワークメッセージをノード６５に送信する。ノード６５は第３のネッ
トワークメッセージのコピーをノード４０に送る。ノード４０はそれから第２の
ネットワークメッセージのコピーをノード４０および６０に送る。ノード４０お
よび６０はそれぞれ、第３のネットワークメッセージのコピーをノード４５ない
し５０に送る。それから、ノード５０は第３のネットワークメッセージのコピー
をノード８０に送りかつノード４５は第３のネットワークメッセージのコピーを
ノード２０および８５に送る。ノード８５は更に第３のネットワークメッセージ
のコピーをノード９５に送る。ノード９５はコピーをノード１５に送る。この実
施形態に対して説明したように、第１のネットワークメッセージをグループＡの
メンバーに送信する際に８つのホップが含まれており、第２のネットワークメッ
セージをグループＢのメンバーに送信する際に７つのホップが含まれておりかつ
第３のネットワークメッセージをグループＣのメンバーに送信する際に１０個の
ホップが含まれている。それ故に、送信機が全部のメッセージ（第１、第２およ
び第３のネットワークメッセージから構成されている）を、名前Ａ，ＢおよびＣ
を有しているこれらに対するマルチキャストを使用して送信しようとするとき、
数多くの別のノード（エンドポント・ノード７０，７５，８０，８５，９０およ
び９５のような、および残りのルーティング・ノード）は、名前Ａ，ＢおよびＣ
を有しているノード１０および１５に向けられているメッセージ全体の少なくと
も一部を不必要にも受信する。この結果は、ネットワークを移動する種々のネッ
トワークメッセージが原因で生じる不必要なネットワークトラヒック輻輳である
。
【００３０】 これに反して、本発明のキャラクタリスティックルーティング・システムを使
用すると、送信機ノード１０は単純に、メッセージを受信するためには受信機ノ
ードが３つの名前Ａ，ＢおよびＣすべてを有していなければならないことを特定
する（本発明によるキャラクタリスティックルーティングを使用して送信される
メッセージは「キャラクタリスティック・メッセージ」と称される）。その場合
キャラクタリスティックルーティングではキャラクタリスティック・メッセージ
は送信機から受信機に最短経路で伝送される。それぞれのルータで次のホップを
決定するために名前の最初の正確な集合が使用されたので、送信機から受信機へ
の最適なルーティングツリーが形成される。特に、図２に示されているように、
送信機ノード１０はキャラクタリスティック・メッセージをノード６５に送信し
（実線の矢印で示されている）、ノード６５はキャラクタリスティック・メッセ
ージのコピーをノード４０に送る。ノード４０はコピーをノード４５に送る。そ
れからノード４５はキャラクタリスティック・メッセージのコピーをノード２０
に送る。ノード２０はキャラクタリスティック・メッセージのコピーをノード９
０に送る。それからノード９０はコピーをノード１５に送る。図２の矢印はキャ
ラクタリスティックルーティングを使用して形成されるルーティングを示してい
る。それ故に、送信機が本発明を使用してキャラクタリスティック・メッセージ
を名前Ａ，ＢおよびＣを有しているノードだけに送信するとき、所望のノードに
対するメッセージのルーティングにとって必要である最小数のノードだけ（ルー
ティング・ノード６５，４０，４５および９０）が名前Ａ，ＢおよびＣを有して
いるノード１０および１５に向けられているキャラクタリスティック・メッセー
ジのコピーを受信する。図１および図２に示されているように、この例では、本
発明によるキャラクタリスティックルーティングが、マルチキャスト・ルーティ
ングに比べて、不当に扱われるエンドポント受信機ノードの数およびネットワー
クトラヒック輻輳を大幅に低減するのである。
【００３１】 キャラクタリスティックルーティングにおいて、システムはコンピュータホス
トがマルチプルネーム（指標）を有することを可能にするように設計されている
。キャラクタリスティックルーティングはメッセージを任意の指標に基づいてル
ーティングすることができるので、広範かつフレキシブルに使用することができ
る。ここで沢山ある指標のうちの１つは受信機のロケーション、受信機の形式、
または受信機の品質の番号である。更に、これらの名前または指標は、僅かな数
のオーバヘッドを用いてダイナミックな仕方でホストによって獲得または除去す
ることができる。キャラクタリスティックルーティングを用いて、受信機がいず
れかの送信機のレンジ内にある限り、キャラクタリスティック・メッセージは送
信機から受信機に場合によりいくつかの中間的なルータを介して、これらがその
宛先に到達するまで送ることができるのである。
【００３２】 キャラクタリスティックルーティングはそれぞれの送信機から受信機のすべて
に対して最短経路のルーティングを構築することによって利用可能なネットワー
ク帯域幅を使用する。この手法において、情報は最も直接的なルートを介してし
かおよび向けられている受信機に対してしか移動しない。本発明のキャラクタリ
スティックルーティングを使用するルータはキャラクタリスティック・ルータと
称される。キャラクタリスティック・ルータはそのルーティングテーブルに、こ
れらがデータを伝送する前に特定のアドレスを有するデータが引き渡し可能であ
るかどうかを知るための十分な情報を有している。更に、用語「キャラクタリス
ティック・ルータ」は一般的な意味において使用され、伝統的なルータ、ネット
ワークスイッチ、ゲートウェイ、ブリッジ、またはキャラクタリスティックルー
ティング・ケイパビリティがそれに搭載されている場合には、別個のネットワー
クを橋絡するコントローラを含んでいるものであることを述べている。更に、キ
ャラクタリスティックルーティングは有線ネットワーク、無線ネットワークまた
は有線−無線が組み合わされたネットワークに使用することができる。
【００３３】 ネットワークトポロジーを発見しかつルーティングテーブルを自動的にコンフ
ィギュレーションするための拡大プロトコルを使用して（種々の実施形態につい
ては後に詳述する）、キャラクタリスティック・ルータはネットワークにおける
それぞれの宛先に対する指標に基づいてルーティングテーブルエントリを有する
ことになる。その場合それぞれのエントリは、宛先の指標、ＩＰアドレス、カレ
ントルータと宛先との間の中間ルータの最小数、および宛先までの経路上の次の
ステップとして使用するのに有利な隣接ルータに関する情報を含むことになる。
【００３４】 入って来るパケットを先送り（フォワーディング）するとき、キャラクタリス
ティック・ルータはルーティングテーブル情報を使用して、キャラクタリスティ
ック・メッセージに対する最終的な宛先がどこにありかつどの隣接ルータにパケ
ットのコピーを送るべきであるのかを決定する。まず、ルーティングテーブルお
よびメッセージヘッダに含まれているキャラクタリスティックな情報を使用して
、パケットに対する最終的な宛先のすべてが発見される。それから宛先までの直
接的な最短経路に基づいて隣接ルータのリストが作成されかつメッセージのコピ
ーがリスト上のそれぞれの隣接ルータに送られる。キャラクタリスティック・メ
ッセージが送信機から受信機のすべてまで道のすべてを踏破したとき、当該送信
機に「根」を持ちかつ受信機のすべてに「葉」を持つ最短経路のルーティングツ
リーを形成することになる。宛先指標の正確なセットが使用されるのであれば、
ルーティングツリーは最適なものになる（図２の例に示されているように）。最
短経路のルーティングツリーが形成されることを保証するために、キャラクタリ
スティック・ルータは、送信機から最短経路を通って到来するパケットだけを先
送り（フォワーディング）することになる。そうでない場合には、ルータは単純
に、パケットのその前のホップに対して「プルーン」メッセージで応答しかつ当
該パケットを落とす。
【００３５】 フォワーディングコストを低減するために、キャラクタリスティック・ルータ
は最も最新のキャラクタリスティック・メッセージ・パケットの次のホップ宛先
のキャッシュを維持する。ルータがキャラクタリスティック・メッセージ・パケ
ットを受信するとき、それはキャッシュへのキーと一緒に到来するパケットの送
信機ＩＰアドレスおよび宛先指標の集合を使用することになる。これがこの宛先
に到来する第１のパケットではなくかつキャッシュにおけるタイマーがまだ経過
終了していなければ、キャッシュは隣接ルータのすべてのリストをパケットのコ
ピーが送信されなければならないルータに戻すことになる。
【００３６】 次に、一般的に説明した本発明の実施形態の種々様々な様相を一層詳細に説明
する。
【００３７】 II． キャラクタリスティックルーティングシステム 図３には、有利な実施形態によるキャラクタリスティックルーティングシステ
ムについて概略的に示されている。この実施形態によれば、キャラクタリスティ
ックルーティングシステム１００は３つの主要コンポーネントを有しており、す
なわちキャラクタリスティックルーティングホストソフトウェア（"Charホスト
ソフトウェア"）と、キャラクタリスティックアプリケーションプログラミング
インタフェース（"CharAPI"）とキャラクタリスティックルータ（"Charルータ"
）を有している。図２（およびあとで述べる図５）中のノードの各々は、キャラ
クタリスティックルータノードとしてもよいし、あるいはここで述べるようにキ
ャラクタリスティックホストノードとしてもよい。
【００３８】 ホストが最初にブートするとき、そのホストは自身を表す指標をローカルキャ
ラクタリスティックルータに宣言する。このようにしてルータは、そのネットワ
ーク上のホストの様々な指標に関する情報をもち続けることができる。キャラク
タリスティックルータがそのネットワーク上のホストの指標を見つけ出す必要が
あるとき（たとえばルータがクラッシュから復帰したとき）、ルータはキャラク
タリスティック・アドレス・レゾリューション・プロトコル（CharARP）クエリ
ーをブロードキャストする。ホストすべてがこのブロードキャストを受け取り、
ついでそれらの指標で応答する。どのノードが複数の指標から成る固有の集合を
有しているのかを、キャラクタリスティックルータが発見する必要があるときに
は、ルータはＣｈａｒＡＲＰクエリーをブロードキャストし、これには対象とす
る特定の指標が含まれている。それらの指標をもつホストだけがそのクエリーに
応答することになる。
【００３９】 図３の概略図によれば、システム１００は第１のキャラクタリスティックホス
トノード１１０と結合された第１のＣｈａｒルータ１０５を有しており、これに
はＣｈａｒホストソフトウェア１２０とＣｈａｒＡＰＩ１２５が含まれている。
第２のＣｈａｒルータ１３５は、インターネットワーク１３０を介して第１のＣ
ｈａｒルータ１０５と結合されている。さらに第２のＣｈａｒルータ１３５は第
２のキャラクタリスティックホストノード１４０と結合されており、これにはＣ
ｈａｒホストソフトウェア１４５とＣｈａｒＡＰＩ１５０が含まれている。Ｃｈ
ａｒＡＰＩはソフトウェアライブラリルーチンセットであり、これによってプロ
グラマはキャラクタリスティックメッセージを送受信可能なアプリケーションを
生成できるようになる。Ｃｈａｒホストソフトウェアはすべてのコンピュータホ
スト上に配置されており、それらはキャラクタリスティックメッセージを送受信
することができる。Ｃｈａｒホストソフトウェアは、コンピュータのオペレーテ
ィングシステムにおけるインターネットプロトコルスタックのネットワークレイ
ヤに配置されている。その役割は、キャラクタリスティックメッセージのアベイ
ラビリティについてすべてのクライアントプロセスに通知すること、ならびにロ
ーカルのＣｈａｒルータとのインタフェースを行うことである。また、Ｃｈａｒ
ホストソフトウェアには、上述のクライアントサイドのＣｈａｒＡＲＰ機能も含
まれている。
【００４０】 これまで概略的に述べてきたように、キャラクタリスティックルータ（Ｃｈａ
ｒルータ）は、送信側から受信側へインターネットワークを介してキャラクタリ
スティックルーティングメッセージを伝送する役割を担っている。各キャラクタ
リスティックルータは、配属されているネットワークのためのキャラクタリステ
ィックルーティング機能の実行を任されている。Ｃｈａｒルータは、Ｃｈａｒル
ータに割り当てられたネットワークに配属されたコンピュータホストの指標の和
集合を生成することにより、ローカルな指標についての情報をもち続ける。Ｃｈ
ａｒルータは、それらのローカルネットワークの指標を交換することによりそれ
らのルーティングテーブルを形成する。Ｃｈａｒルータには、上述のようにサー
バサイドＣｈａｒＡＲＰ機能も含まれている。
【００４１】 Ａ． キャラクタリスティックノードコンポーネント ルーティングには２つの別個の機能が関与し、つまりそれらはコントロールメ
ッセージ交換とパケットフォワーディングである。コントロールメッセージ交換
にはルーティングテーブル情報をスワップするルータが関与し、その際、各ルー
タは蓄積されたネットワーク情報からルーティングテーブルを生成する。また、
パケットフォワーディングに関与するルータはそのルーティングテーブルを利用
してパケットを受け取るネクストホップを決定する。
【００４２】 本発明の１つの実施形態に従ってコントロールメッセージ交換を実行する目的
で、リンクステートルーティングプロトコルである Open Shortest Path First
(OSPF) プロトコルが拡張され（これによりあとで説明するように１つの有利な
実施形態によればＣｈａｒＯＳＰＦが作られる）、それによればキャラクタリス
ティックルータがそのルーティングテーブル情報を隣り合うキャラクタリスティ
ックルータへ送信したとき、それにはその交換情報に列挙された宛先すべての指
標が含まれることになる。あとで述べるように、その他の実施形態はＣｈａｒＯ
ＳＰＦに加えて拡張されたプロトコルを利用する。
【００４３】 図４には、本発明の１つの実施形態によるキャラクタリスティックルーティン
グノードの機能ダイアグラムが概略的に描かれている。キャラクタリスティック
ノードにはキャラクタリスティックルーティングファンクショナルコンポーネン
ト（"charcast" 機能）が含まれており、これによればそれを慣用のユニキャス
トおよびマルチキャストルータとして作動させることに加えて、キャラクタリス
ティックルータ（つまり "Ｃｈａｒルータ"）として作動させることができる。
図４に示されているように、図３中のＣｈａｒルータ１０５のようなキャラクタ
リスティックルーティングノードは機能的には、ユニキャストファンクショナル
コンポーネント２００、マルチキャストファンクショナルコンポーネント２０５
およびｃｈａｒキャストファンクショナルコンポーネント２１０を含むとみなす
ことができる。ルーティングノードがｃｈａｒキャスト機能だけというように制
限された機能しかもたないことが望まれるいくつかの実施形態では、ユニキャス
トおよび／またはマルチキャストファンクションを省くことができる。とはいえ
有利な実施形態によれば、キャラクタリスティックルータノードにはそれら３つ
の機能すべてが含まれている。さらに別の実施形態の場合、ｃｈａｒキャスト機
能を（ユニキャストやマルチキャストとは異なる）他のタイプのルーティング機
能に含めてもよい。
【００４４】 図４の有利な実施形態の場合、ユニキャストおよびマルチキャストファンクシ
ョンコンポーネント２００および２０５はそれぞれ、ノード１０５におけるｃｈ
ａｒキャストファンクショナルコンポーネント２１０に含まれている。詳細には
、ユニキャストコンポーネント２００はユニキャストクラシファイア２１５とポ
ートデマルチプレクサ２２０を有している。ユニキャストクラシファイア２１５
は、ユニキャストルーティングテーブルを利用してパケットをルーティングする
。また、パケットに対する宛先ポートを利用しするポートデマルチプレクサ２２
０は、個々の宛先ポート目下利用している個々のアプリケーションへパケットを
送る。マルチキャストコンポーネント２０５は、マルチキャストスイッチ２２５
とマルチキャストクラシファイア２３０と第１のレプリケータ２４０および第２
のレプリケータ２４５を有する。この実施例では２つのレプリケータしか示され
ていないが任意の個数のレプリケータを使用することができ、この場合、それぞ
れ異なるレプリケータが各々の送信側／マルチキャストルーティング部分集合ペ
アのために形成されるようにする。マルチキャストスイッチ２２５により、ユニ
キャストルーティングテーブルを利用してパケットをルーティングすべきである
のか、マルチキャストルーティングテーブルを利用してパケットをルーティング
すべきであるのかが決定される。マルチキャストクラシファイア２３０は、マル
チキャストルーティングテーブルを用いてパケットをルーティングする。マルチ
キャストレプリケータ（２４０または２４５）は実際にパケットを送出リンクへ
、あるいは（そのパケットがノード１０５におけるアプリケーション宛であれば
）内部ポートデマルチプレクサへ送信する。さらにノード１０５は上述のように
ｃｈａｒキャストファンクショナルコンポーネント２１０を有しており、これに
よってノード１０５に対しキャラクタリスティックルーティングを実行するケイ
パビリティが与えられる。様々なアプリケーションや通信リンクが、キャラクタ
リスティックルーティングノード１０５と論理的に結合されている。図４に示さ
れているようにノード１０５には論理入力ポート２５０が設けられており、そこ
においてノード１０５はパケットを受け取り、さらにｃｈａｒキャストスイッチ
２５５が設けられており、このスイッチによってパケットがキャラクタリスティ
ックメッセージパケットであるか否かが判定される。
【００４５】 ノード２５５におけるｃｈａｒキャストスイッチ２５５が、受信したパケット
がキャラクタリスティックメッセージパケットでないと判定したならば、そのパ
ケットは処理のためマルチキャストファンクショナルコンポーネント２０５へル
ーティングされる。さらに具体的に述べるとマルチキャストスイッチ２２５はパ
ケットヘッダからのアドレスのタイプに基づき、ユニキャストルーティングテー
ブルを用いてパケットをルーティングすべきであるのかマルチキャストルーティ
ングテーブルを用いてパケットをルーティングすべきであるのかを判定する。パ
ケットがマルチキャストアドレスをもっているのであれば、マルチキャストスイ
ッチ２２５はそのパケットをマルチキャストクラシファイア２３０へ送り、それ
によりマルチキャストルーティングテーブルを用いてパケットがルーティングさ
れる。ついでマルチキャストクラシファイア２３０はそのパケットを適切なマル
チキャストレプリケータ２４０または２４５へ向けてルーティングし、それによ
ってパケットは適切な送出リンクおよび／またはノード１０５のアプリケーショ
ンへ（アプリケーションへ向かわなければポートデマルチプレクサ２２０を介し
て）伝送される。しかしながらマルチキャストスイッチ２２５によりパケットが
ユニキャストアドレスをもつと判定されれば、マルチキャストスイッチ２２５は
パケットをユニキャストクラシファイア２１５へルーティングし、それによりユ
ニキャストルーティングテーブルを用いてパケットがルーティングされる。ユニ
キャストクラシファイア２１５はそのパケットを適切な送出リンクへ、あるいは
適切なアプリケーションのために内部ポートデマルチプレクサ２２０へルーティ
ングすることができる。
【００４６】 しかしノード１０５におけるｃｈａｒキャスト２５５が、受信したパケットが
ほんとうにキャラクタリスティックメッセージパケットであると判定したならば
、パケットは処理のためｃｈａｒファンクショナルコンポーネント２１０におけ
る他のコンポーネントへ向けてルーティングされる。詳細にはｃｈａｒキャスト
ファンクショナルコンポーネント２１０には、ファーストインファーストアウト
（ＦＩＦＯ）バッファ２６０とｃｈａｒキャストクラシファイア２６５とメモリ
２７０も設けられている。メモリ２７０は、キャラクタリスティックルーティン
グテーブル（ルーティングテーブルを成すデータおよびテーブル、キャッシュ、
インデックスをサーチおよび保守するファンクションの両方）を記憶しており、
さらにユニキャストとマルチキャストのファンクショナルコンポーネントがノー
ド１０５内に含まれているのであれば、たとえばパトリシアツリーなどによって
インデックス形成されたユニキャストルーティングテーブルおよびマルチキャス
トルーティングテーブル（ならびにもし存在するならば関連するインデックス）
を記憶している。メモリ２７０内のキャラクタリスティックルーティングテーブ
ルは、１つの実施形態によれば自身のインデックス２８０およびメモリキャッシ
ュ２７５と結合されている。ｃｈａｒキャストファンクショナルコンポーネント
２１０にはｃｈａｒレプリケータ２８５，２９５およびターゲットをドロップ（
すなわちパケットを廃棄）するファンクション２９０も含まれている。上述のレ
プリケータについてと同様、この例でも２つのｃｈａｒレプリケータしか示され
ていない。とはいえ任意の個数のｃｈａｒレプリケータを使用することができ、
この場合、送信側／キャラクタリスティックルーティング部分集合ペア各々ごと
に異なるｃｈａｒレプリケータが生成される。次に、Ｃｈａｒルータノード１０
５におけるｃｈａｒキャストファンクショナルコンポーネント２１０の様々なパ
ートの動作について詳しく説明する。
【００４７】 ｃｈａｒキャストスイッチ２５５がパケットヘッダを調べ、宛先指標の存在を
判定した後、ｃｈａｒキャストスイッチ２５５はパケットをｃｈａｒキャストク
ラシファイア２６５へ送って処理を継続させる（さもなければｃｈａｒキャスト
スイッチ２５５はすでに述べたようにパケットをマルチキャストファンクショナ
ルコンポーネント２０５へ送って処理する）。ｃｈａｒキャストクラシファイア
２６５は適切な宛先およびパケット経路を求める目的で（メモリ２７０内に格納
されている）キャラクタリスティックルーティングテーブルに問い合わせ、パケ
ットの実際の物理的なフォワーディングを実行するｃｈａｒレプリケータ２８５
，２９５のリストを管理する。ｃｈａｒキャストクラシファイア２６５が先行す
るパケットのフォワーディングのためにビジー状態である期間中に、ノード１０
５に他のキャラクタリスティックメッセージパケットが到着すると、その新たな
パケットはＦＩＦＯキュー２６０に置かれることになる。ｃｈａｒキャストクラ
シファイア２７５が先行のパケットのフォワーディングを完了すると、キューに
ある次のパケットを取り出すことになる。
【００４８】 ｃｈａｒキャストクラシファイア２６５がキャラクタリスティックメッセージ
パケットを受け取ると、それによってキャラクタリスティックルーティングテー
ブルにクエリーが出され、パケットの宛先指標をテーブルに送ることでパケット
のネクストホップについて問い合わせられる。キャラクタリスティックルーティ
ングテーブルはそのクエリーに対し、パケットのフォワーディングのためにｃｈ
ａｒキャストクラシファイア２６５が使う必要のある適切なｃｈａｒレプリケー
タ２８５または２９５の識別子を戻すことで応答するかまたは、パケットをフォ
ワーディングできないことをｃｈａｒキャストクラシファイア２６５へ通知する
ことによって応答する。
【００４９】 キャラクタリスティックルーティングテーブルはまず最初に、パケットが送信
側から最短経路でノード１０５に到着したことを確かめるためにユニキャストル
ーティングテーブルを調べる。これがあてはまらなければ、パケットはフォワー
ディングできず（ドロップターゲットファンクション２９０によって示されてい
るように）ドロップされることになる。ついでキャラクタリスティックルーティ
ングテーブルは、ルーティングテーブルキャッシュ２７５をサーチするためにパ
ケットの宛先指標集合を利用する。キャッシュ２７５は、パケットの送信側アド
レスと宛先指標とに基づきフォワーディング情報を記憶している。キャッシュ２
７５について成功したヒットを返すためには、これら両方がマッチしていなけれ
ばならない。この送信側からのものでありこの宛先に対するパケットが以前にあ
ったならば、キャッシュ２７５は使用に適したｃｈａｒレプリケータの識別子を
戻すことになる。ついでその適切なｃｈａｒレプリケータはパケットを適切な送
出リンクへ伝送し、あるいは好適であれば、常駐アプリケーションのためにポー
トデマルチプレクサ２２０へ伝送する。
【００５０】 キャッシュエントリがみつからなければ、キャラクタリスティックルーティン
グテーブルはパケット宛先指標を利用してルーティングテーブルインデックス２
８０をサーチする。そしてインデックス２８０によって、それらの指標をもって
おり可能性のある宛先候補リストを戻す。インデックス２８０によっていかなる
候補も見つけ出されなければ、キャラクタリスティックルーティングテーブルは
パケットがフォワーディング不可能であることをｃｈａｒキャストクラシファイ
ア２６５へ通知する。インデックス２８０によって候補が見つけ出されれば、キ
ャラクタリスティックルーティングテーブルはそのルーティングテーブルエント
リを利用して、パケットのためのネクストホップの集合を導出し、その情報をコ
ーディングして新たなｃｈａｒレプリケータオブジェクトを生成する。目下のノ
ード１０５が宛先とみなされた場合、ｃｈａｒレプリケータとしてコーディング
されたネクストホップのうちの１つが目下のノードのポートデマルチプレクサ２
２０へのリンクとなる。この場合、キャラクタリスティックルーティングテーブ
ルはｃｈａｒキャストクラシファイア２６５内に新たなｃｈａｒレプリケータオ
ブジェクトをインストールし、この新たなｃｈａｒレプリケータの識別子をｃｈ
ａｒキャストクラシファイア２６５へ戻す。
【００５１】 すでに述べたようにｃｈａｒレプリケータの主要な役割は、パケットのコピー
をネクストホップ集合各々に実際に伝送することである。とはいえｃｈａｒレプ
リケータの副次的な役割として挙げられるのは過度に大きなルーティングツリー
のプルーンメカニズムであり、実施形態によれば上述のようにキャラクタリステ
ィック集合が近似される。固有の＜sender address, destination characterist
ics＞ペアのためのネクストホップ情報のコーディングに加えて、各ｃｈａｒレ
プリケータにはプレビアスホップのアドレスも含まれている。ネクストホップ数
がゼロに近づいているのであれば、ｃｈａｒレプリケータオブジェクトはプルー
ンメッセージをプレビアスホップへ伝送する。プルーンメッセージが損失し固有
の＜sender address, destination characteristics＞ペアに対するキャラクタ
リスティックメッセージパケットが到着し続ける状況であるならば、ｃｈａｒレ
プリケータオブジェクトは最後の受信パケットが通り過ぎてしまうまでの期間に
わたり存続し続け、そのあとで消されることになる。新たにパケットが到着する
たびに相応のプルーンメッセージがトリガされてプレビアスホップへ伝送される
。
【００５２】 Ｂ． キャラクタリスティックベクトル（指標のベクトル） ルーティングテーブル内の特定の宛先ノードに対する指標は指標ベクトルとし
て保持される。指標ルータはそれぞれ独自の指標にビットベクトル上の所定の位
置を割り当てる。上述したように種々の指標は任意に定めることができ、実施例
に応じてダイナミックに付加または削除できる。任意の指標のベクトルの例を次
の表１に示す。
【００５３】 表１−−−指標のベクトル 指標 ビットベクトル位置 ＡＳＩＣ １ Ａｔｏｍｉｃ ２ Ｃｕｒｌｙ ３ Ｄｅｆｉａｎｔ ４ ＤＳＰ ５ ＦａｓｔＦｏｕｒｉｅｒ ６ Ｆｌａｓｈ ７ Ｈｅｌｉｕｍ ８ Ｈｙｄｒｏｇｅｎ ９ Ｌａｒｒｙ １０ ＲＡＭ １１ ＳｔａｒＴｒｅｃｋ １２ Ｓｔｏｏｇｅｓ １３ Ｓｕｂ‐ｂａｎｄ １４ Ｖｏｙａｇｅｒ １５ Ｗａｖｅｌｅｔ １６ 表１に示されているように、それぞれ独自の指標にビットベクトル上の１つの
位置が割り当てられている（例えば“ＤＳＰ”指標には第５のビットベクトル位
置が割り当てられている／この実施例においてビットベクトル位置の数は最重要
ビットから始まっている）。別の実施例ではビットベクトル位置の数が最も重要
度の低いビットから始まっていてもよい。この実施例によれば“ＡＳＩＣ”“Ａ
ｔｏｍｉｃ”“ＦａｓｔＦｏｕｒｉｅｒ”“Ｈｅｌｉｕｍ”“Ｈｙｄｒｏｇｅｎ
”“Ｗａｖｅｌｅｔ”の指標を有する宛先ノードのビットベクトルから“１１０
００１０１１００００００１”のビットベクトルが得られる。これらの指標のビ
ットベクトル内の各ビットの符号化の手法には後述するように種々のインプリメ
ンテーションが存在する。
【００５４】 ビットベクトルが使用されているので、ベクトル演算は各指標について行われ
る。例えば指標パケットの宛先指標が正確にルーティングテーブルエントリに適
合しているか否かを求めるために、論理ＡＮＤが行われる。得られたベクトルが
オリジナルのパケットの宛先指標のベクトルと等しい場合、正確なマッチングが
求められたことになる。宛先指標のうち幾つかのものだけ求めればよい場合には
、論理ＡＮＤを行って結果が単純に０より大きければ少なくとも幾つかの指標は
適合していることになる。メッセージを宛先指標の少なくとも１つの部分集合を
備えたノードへ到達させようとしている状況では、論理ＯＲを行って結果が単純
に０より大きければ少なくとも幾つかの指標は適合していることになる。ベクト
ルはｎ次空間（ここでｎは指標の個数）では直線となると考えられるから、ベク
トル間の角度を求めればよい。ベクトル間の角度の小さいベクトルは類似してい
ると見なすことができ、一方角度の大きいベクトルは類似していないと見なすこ
とができる。このようにすれば送信機ノードは指標メッセージが予め定められた
類似度を備えた特定の指標ビットベクトルを有するノードへ送信されるように指
定することができる。ここで類似度とは宛先ノードのベクトルと所望の指標の所
望のビットベクトルとのあいだの角度差に基づいて定められる。さらに初期指標
と終期指標とのあいだの指標の“ｒａｎｇｅ”も初期指標（特定の開始ベクトル
ビット）と終期指標（特定の終了ベクトルビット）とを定義することにより指定
することができる。これにより指標メッセージは定義された指標範囲内の全ての
指標に該当するノードへ送信される。
【００５５】 直接の指標マッチングまたは類似の指標のマッチングのために、指標ビットベ
クトルにより指標ルーティングを用いた迅速なプロセシングを行うことができる
。これにより高速かつ効率の良い演算が可能となる。
【００５６】 １． キャラクタリスティックベクトル（指標ベクトル）：指標の閉集合対開
集合 前述したように、本発明の実施例では、使用される指標をダイナミックに変更
（削除または付加）することができる。このことは刻々と変化する環境、すなわ
ち種々のノードがネットワークへ付加されたりネットワークから削除されたりす
るのにしたがってノードの指標も変化していくような環境でメッセージを送信す
るのに有効である。
【００５７】 指標の集合が“閉”であるかまたは静的である場合、この指標の集合はネット
ワーク全域にわたって変化せず、全てのルータは同じ指標集合および同じ指標ベ
クトルを有する。これにより指標ビットベクトルは送信機によって計算され、直
接にパケットヘッダ内へ配置される。
【００５８】 これに対して指標の集合が“開”であるかまたは動的である場合には、各指標
ルータは異なる指標の集合によっても動作することができる。このケースは新た
な指標がネットワーク内に現れ、ネットワークを介して全てのルータへ伝播する
際の遅延のために発生する。このとき所定の時点での任意の１点では各指標ルー
タはネットワーク内に存在する指標全体の全集合を有してはいない。したがって
送信機が全集合を有していないために指標ベクトルを計算することができず、パ
ケットヘッダ内の全ての宛先指標をリストアップしなければならない。その場合
各指標ルータはこの指標のリストを当該のルータに既知なものとして設定されて
いる指標に矛盾する指標のベクトルへ翻訳する。
【００５９】 ２． 指標集合の近似 ネットワークが指標の“開”集合を使用している場合、指標の個数がシステム
に負荷をかけるまでに大きくなったり、または少なくともパケットヘッダが相当
大きくなってしまったりすることがある。このため実施例によっては指標ルーテ
ィングのためにシステムが用いる指標の個数を低減するために近似を行うと有利
である。例えば種々の圧縮技術を使用して大幅に指標の個数を低減することがで
きる。
【００６０】 長い文字列に対する圧縮技術、例えばＬｅｍｐｅｌ‐ＺｉｖまたはＢｌｏｏｍ
フィルタ（これらについては後に詳述する）が設けられる場合、また別の実施例
により別の圧縮技術が使用される場合でもそうであるが、これらの記号列の占め
るスペースの節約はオリジナルの記号列全体を再現するサブ記号列の小さな集合
を形成することにより達成される。サブ記号列の構成およびサブ記号列の使用法
についての指示はオリジナル記号列の再現のために記憶されている。指標ルーテ
ィングの目的で、このサブ記号列が指標のオリジナルの集合の近似として用いら
れる。送信機およびルータはこの近似技術を使用している。ただしパケットスト
リームのうち第１のパケットは、エンドポイントでこれらのパケットが真に自身
に対して送信されたものであるか否かを検出するために、宛先指標のオリジナル
リストを送信しなければならない。
【００６１】 圧縮技術により記号列の数が指標の本来の個数よりも小さいサブ記号列の個数
まで低減されるので、指標ルータの行うべき比較作業は低減され、ルーティング
をいっそう迅速に行うことができる。またルーティングテーブルを大幅に小さく
できる。
【００６２】 指定手段が失われたため、この実施例での指標パケットはこれらのパケットを
受信する必要のないノードへもとりあえずフォワーディングされてしまい、その
結果、ルーティングツリーが剪定を必要とする余計なエラー分岐を含んでしまう
。メッセージに対する生きた宛先となる下流のルータが存在せず、またそれ自体
も指標メッセージの宛先ではないことを指標ルータが検出した場合、“プルーン
”メッセージが指標メッセージのソースへ向かう上流方向へ送信される。指標ル
ータが特定の指標メッセージに対するプルーンのメッセージを受け取ると、下流
のルータはルーティングキャッシュエントリからその指標メッセージを受け取る
。これにより下流ルータの数が０まで低下すれば、指標ルータは自身でプルーン
のメッセージを上流方向へ送信する。
【００６３】 本発明の実施例により、図５には指標の近似が使用される場合に過剰なルーテ
ィングツリーの分岐をプルーンするプロセスが示されている。解りやすくするた
めに図５では図２について説明したのと同じネットワーク構造の例を使用してい
る。図２と同様に、簡単化のために図示していないが、ここでのネットワークノ
ードはＡ，Ｂ，Ｃという名前の付されたホストノードまたはそのコンビネーショ
ンに接続されたルーティングノードを含んでおり、送信機ノードはメッセージを
送信する送信ホストノードを有するルーティングノードである。図５では送信機
ノード１０は全指標の集合の近似を用いた指標メッセージを送信する。指標の集
合の近似が使用され、各ノードでの次の希望が求められるので、送信機ノード１
０から受信ノードへのきわめて大きなルーティングが形成される。特に送信機ノ
ード１０は指標メッセージ（実線の矢印と点線の矢印とで表されている）を指標
の近似の集合（“近似指標メッセージ”と称する）を使用して送信し、これによ
りメッセージがＡ，Ｂ，Ｃの指標を有するノードへ送信される。この近似指標メ
ッセージはノード６０へ送信され、ここからその近似指標メッセージのコピーが
ノード４０へフォワーディングされ、さらにそのコピーがノード２５、４５へフ
ォワーディングされる。その後ノード２５は近似指標メッセージのコピーをノー
ド７５へフォワーディングし、ノード４５は近似指標メッセージのコピーをノー
ド８５、２０へフォワーディングする。ノード８５は近似指標メッセージのコピ
ーをノード９５へフォワーディングし、ノード２０は近似指標メッセージのコピ
ーをノード９０へフォワーディングし、ノード９０はコピーをノード１５へフォ
ワーディングする。図示されているように、矢印は最適なルーティングツリーと
後述するプルーンの必要な余計な分岐とを表している。最適なルーティングツリ
ーは実線の矢印で示されており、図２のように指標の集合の近似を使用しないで
得られたものである。余計なブランチは点線の矢印で示されており、近似を使用
したことによって発生したものである。
【００６４】 Ｃ． キャラクタリスティックパケット（指標パケット） 指標情報を使用したルーティングすべきパケットのために、指標ルーティング
プロトコルが種々の実施例に則してネットワークスタック層に設けられている（
例えばデータリンク層２、ネットワーク層３、またはオープンシステムインター
コネクトＯＳＩのプロトコルスタックのトランスポート層４など）。指標ルーテ
ィングプロトコルが存在する層によりインタフェースの決定および指標ルーティ
ングプロトコルのケイパビリティ決定が制御される。以下に各実施例について説
明するが、それぞれの実施例が種々の状況で有利に使用できることを指摘してお
く。
【００６５】 理想的な実施例では指標ルーティングプロトコルはネットワーク層内に構成さ
れる。本発明の実施例は、指標ルーティングプロトコルが（i）直接にデータリ
ンク層上にあるか擬似データリンク層のＩＰよりも下位にある場合、（ii）直接
にトランスポート層のＩＰ上にある場合、または（iii）直接にＩＰトランスポ
ート層（例えばＵＤＰまたはトランスミッションコントロールプロトコルＴＣＰ
など）上にある場合に有利である。これらの実施例を検討するコンテクストで、
図６に種々の従来のインターネットワーキングプロトコルのネットワークスタッ
ク位置を示してある。図６に示されているように、非同期伝送モードＡＴＭ、イ
ンテグレーティドＩＳ‐ＩＳ、およびマルチプロトコルレーベルスイッチングア
ーキテクチャＭＰＬＳは擬似データリンク層内で動作しているプロトコルの例で
ある。ＡＴＭプロトコルはローカルエリアネットワークエミュレーションＬＡＮ
Ｅ、マルチプロトコルオーバー非同期伝送モードＭＰＯＡ、マルチキャストアド
レスレゾリューションサーバＭＡＲＳ、ネクストホップレゾリューションプロト
コルＮＨＲＰを含む。ＳＯＮＥＴ、Ｅｔｈｅｒｎｅｔ、ＴｏｋｅｎＲｉｎｇなど
はデータリンク層内で動作するプロトコルである。ＯＳＰＦｖ２、ＵＤＰ、ＴＣ
Ｐ、インターゲートウェイルーティングプロトコルＩＧＲＰ、インターネットグ
ループ、マネジメントプロトコルＩＧＭＰ、プロトコルインディペンデントマル
チキャストＰＩＭのプロトコル、およびコアベーストツリーＣＢＴのマルチキャ
ストプロトコルはトランスポート層内で直接にＩＰ上で動作するプロトコルの例
である。ＯＳＰＦのマルチキャスト拡張部ＭＯＳＰＦ、ルーティングインフォメ
ーションプロトコルｖｅｒ．２（ＲＩＰｖ２）、ボーダーゲートウェイプロトコ
ルＢＧＰ、ディスタンスベクトルマルチキャストルーティングプロトコルＤＶＭ
ＲＰはトランスポート層のプロトコル上で動作するプロトコルの例である。
【００６６】 本発明の実施例によれば、指標にしたがってルーティングされるパケット（ま
たは“ｃｈａｒｃａｓｔパケット”）は少なくとも大域的に独自の識別子と指標
固有フラグとを有しており、これらはｃｈａｒｃａｓｔパケットヘッダ内に存在
している。大域的に独自の識別子は特定の１つまたは複数の宛先ノードの指標の
独自の集合に相応している。図７には指標パケットの大域的に独自の識別子３０
１のフォーマットが実施例にしたがって示されている。この実施例では識別子３
０１は送信機ＩＰアドレス３０３（４ｂｙｔｅ）、送信機ポート番号３０５（２
ｂｙｔｅ）、およびメッセージの連続番号３０７（２ｂｙｔｅ）を含む８ｂｙｔ
ｅのフィールドである。送信機ＩＰアドレス３０３およびポート番号３０５によ
り特定のホスト内のプロセスおよびソケットが識別され、連続番号３０７により
ソケットが目標としている種々の宛先が識別される。前述したように、指標はネ
ットワークにより宛先ノードの位置を求め、初期のルーティングツリーを形成す
るために用いられる。定義される指標固有フラグはCHARCAST＿TRAILBLASER＿PAC
KETのフラグを含み、これはｃｈａｒｃａｓｔパケットｖが後述するＣｈａｒＡ
ＲＰであるか否かを示している。またCHARCAST＿ORIGINAL＿CHARACTERISTICSの
フラグはｃｈａｒｃａｓｔパケットがＣｈａｒＡＲＰの上述のクエリ応答である
か否かを示している。この実施例によれば、指標固有フラグは１ｂｙｔｅのフィ
ールドであれば上述以外にも設定可能であり、これにより上述の種々の指標固有
フラグが現れる。
【００６７】 本発明の実施例では全てのｃｈａｒｃａｓｔパケットは独自の識別子および指
標固有フラグに加えて宛先ノードのリストを含んでいる。ただし指標のリストを
伝達する必要のあるオーバヘッドは大きいので、有利な実施例では“トレイルブ
レージングパケット”のみが指標のリストを含む。送信機がパケットを新たな宛
先へ送信する場合、送信ホストは新たな宛先を検出し、この新たな宛先に大域的
な識別子を割り当て、トレイルブレージングパケットを送信する。トレイルブレ
ージングパケットは通常の指標ヘッダを使用しており、これは独自の識別子およ
び指標ルーティング固有フラグと、さらにパケットのペイロード部分の指標のオ
リジナルリストを有している。有利な実施例では、トレイルブレージングパケッ
トが送信された直後に、送信機が送信したオリジナルのｃｈａｒｃａｓｔパケッ
トと続く全てのパケットとが通常のｃｈａｒｃａｓｔヘッダにより送信される。
通常のｃｈａｒｃａｓｔヘッダは独自の識別子およびフラグのみを含み、相応の
指標のリストを有さないヘッダである。トレイルブレージングパケットは設定さ
れたCHARCAST＿TRAILBLAZER＿PACKETのフラグを有している。トレイルブレージ
ングパケットは効率的にネットワークを介した指標のルーティングツリー経路を
形成し、宛先指標と送信機とを組み合わせる最適なルーティングツリーで得られ
るイベントのチェーンを開始する。各ルータは送信機から受信機のセットへの経
路に沿って本来の指標がトレイルブレージングパケットの到着時に形成されるフ
ォワーディングキャッシュエントリの一部として記録される。
【００６８】 上述したようにｃｈａｒｃａｓｔパケットの宛先ノードはリストに関連した大
域的に独自のパケット識別子に相応する指標のリストを備えたノードである。ｃ
ｈａｒｃａｓｔパケットには指標の宛先（または指標のリスト）が要素のリスト
として表されており、これは実施例では任意の大きさの割り当てられていないｂ
ｙｔｅから成る記号列である。別の実施例では要素のリストは内部に組み込まれ
た個々の要素としての他のリストを有していてもよい。
【００６９】 本発明の１つの実施例により、図８には指標宛先（指標のリスト）のフォーマ
ットが示されている。これはｃｈａｒｃａｓｔパケットの指標宛先を形成する２
つの要素（指標）を有している。図８に示されているように指標リスト３１１は
予め定められた順序にしたがう複数のフィールドを含んでいる。すなわちリスト
タイプフィールド３１３（１ｂｙｔｅ）、要素数フィールド３１５（１ｂｙｔｅ
）、リストサイズフィールド３１７（２ｂｙｔｅ）、および２つのリスト要素３
１９、３２９である。リストタイプフィールド３１３は例えばリストを示すため
に予め定められた０×０２の値に設定されている。要素数フィールドはリストの
要素の個数に設定されている（この実施例では要素数フィールド３１４は８ｂｉ
ｔのフィールドである／リストの要素は全部で２５６個までに限定されている）
。リストサイズフィールド３１７はリストタイプフィールド３１３、要素数フィ
ールド３１５、リストサイズフィールド３１７、および要素３１９、３２９を含
む符号化リスト全体のｂｙｔｅにおける全サイズを表している（例えばこの実施
例ではリスト全体のサイズは１８ｂｙｔｅである）。リストの各要素３１９、３
２９は１ｂｙｔｅの要素タイプフィールド３２１、３３１、１ｂｙｔｅのサイズ
フィールド３２３、３３３、および要素データフィールド３２５、３３５を含む
。１つのリストに含まれる要素は種々の大きさを取ることができることを指摘し
ておく。要素タイプフィールドは例えば要素を表すために予め定められた別の値
、例えば０×０１に設定されている。サイズフィールドは要素タイプフィールド
、サイズフィールドおよび要素データフィールドを含む符号化リスト全体のｂｙ
ｔｅにおける全サイズを表している（この実施例ではサイズフィールドは要素３
１９に対しては値６であり、要素３２９に対しては値８である）。１つの要素に
対して要素データフィールドはその時点での生の要素データそのものであり、要
素データフィールドの大きさは固定ではなくむしろ要素データの大きさに依存す
る（例えば前述したように、１つの要素リストにおける特定の要素はその特定の
要素内に組み込まれた要素のリストを有する）。もちろん指標宛先は種々のｃｈ
ａｒｃａｓｔパケットに対する任意の数の要素を含むことができる。これはリス
トに付加的な要素を加えることにより行われる。
【００７０】 ｃｈａｒｃａｓｔパケット内の要素のリストに関して、本発明の実施例では、
特定のリストの第１の要素はコマンドとなると見なされる。この実施例によれば
、次のコマンドが識別される。ＡＮＤ：リストは任意の数の要素を含んでおり、
宛先はリスト内の全ての要素に適合しなければならない。ＯＲ：リストは任意の
数の要素を含んでいるが、宛先はそのうち少なくとも１つの要素に適合していれ
ばよい。Ｒａｎｇｅ：レンジコマンドの後にはリストは少なくとも２つの要素を
含んでおり、宛先は第１のリスト要素と第２のリスト要素とのあいだの範囲に存
在する既知の全ての指標を有する。Ｓｉｍｉｌａｒ：リストが任意の数の要素を
含んでおり、コマンド後の第１の要素が所定のパーセンテージの類似度である場
合、宛先はリスト内の全ての要素に類似していなければならない（ここでのパー
センテージとは例えば１００％が正確なマッチングを表し、０％が完全な正反対
を表す）。バックワード互換性のために、リストの第１の要素としてコマンドが
与えられていないときにはＡＮＤコマンドが示唆されているものとする。種々の
コマンドは各要素の要素タイプフィールド内に示される相応の値を有しており、
これによりその要素が特定のコマンドとして識別される。
【００７１】 実施例によれば、また上述の表１に挙げられた指標を用いれば、指標宛先の例
は（AND ASIC Wavelet（RANGE Helium Hydrogen）RAM（RANGE DSP Flash））と
なる。ここで括弧はリストの開始部と終了部とを示している。この特定の指標宛
先を有する指標パケットは（ａ）ＡＳＩＣ、（ｂ）Ｗａｖｅｌｅｔ、（ｃ）Ｈｅ
ｌｉｕｍおよびＨｙｄｒｏｇｅｎ、（ｄ）ＲＡＭ、（ｅ）ＤＳＰおよびＦａｓｔ
ＦｏｕｒｉｅｒおよびＦｌａｓｈを有するノードによって受け取られる。
【００７２】 １． ＩＰよりも下位のインプリメンテーション ＩＰよりも下位で指標ルーティングを行う実施例ではＩＰの機能の標準セット
が得られる。特にデータリンク層のＩＰよりも下位の指標ルーティングを行う実
施例により、使用されている特定のデータリンク層のプロトコルフィーチャ（例
えば速度または機能）の利点を活用した指標ルーティングが可能となる。例えば
１つの実施例では、インタフェースを介してＶＩＡが可能なＥｔｈｅｒｎｅｔの
ハードウェアとの接続が形成され、これによりデータパケットの送受信の非同期
通知能力およびダイレクトメモリアクセスＤＭＡの使用能力が使用可能となる。
ただしデータパケットがマキシマムトランスポートユニットＭＴＵよりも大きく
、データリンク層のプロトコルが典型的なパケットのフラグメンテーションおよ
びリアセンブリを提示しない場合には、この実施例にフラグメンテーションおよ
びリアセンブリのインプリメンテーションは必要ない。さらにこの実施例は種々
のデータリンク層のプロトコルに対して構成された指標ルーティングの新たなイ
ンタフェースコードを要求しない。
【００７３】 ２． ネットワーク層内のインプリメンテーション 本発明の実施例によれば、指標ルーティングプロトコルは理想的にはネットワ
ーク層内に構成される。完全に新たなネットワーク層プロトコルが既存のプロト
コルを考慮せずに使用されるインターネットワーキング環境において、この実施
例では指標ルーティングプロトコルがネットワーク層プロトコルとして用いられ
る。
【００７４】 インターネットプロトコルＩＰすなわち既存のネットワーク層プロトコルは、
こんにちのネットワークではネットワークプロトコルに対するデ・ファクトなア
プリケーションプログラミングインタフェースＡＰＩを備えたＩＰとともに普及
しているので、ＩＰの互換性および共存性がますます大きく望まれるようになっ
ている。ＩＰの互換性が所望される場合、指標ルーティングプロトコルはネット
ワーク層内でＩＰと共存できるように種々の実施例に応じて構成される。１つの
実施例では指標ルーティングプロトコルは完全にＩＰから分離しており、ＩＰプ
ロトコルＩＰｖ４からの区別をはかるために新たなデータリンクカプセル化を要
求する。別の実施例では指標ルーティングプロトコルはＩＰの一部として構成さ
れ、ＩＰヘッダに対するオプションとして設けられたり、指標の集合および指標
固有フラグの集合のためのフィールドを従来のネットワークパケットに加えたり
することによって設けられる。有利にはこの実施例により、ルーティングされる
パケットについてＩＰがその上を走るデータリンク層の全てのプロトコルの利点
を活用でき、またＩＰ上を走るトランスポート層プロトコル（ユーザデータグラ
ムプロトコルＵＤＰなど）がただちに指標ルーティングによる付加的な機能を得
ることができる。しかも再符号化にかかる残りのアプリケーションの量も最小限
に抑えられる。ただしこの実施例はある種の一般的なルータ、すなわちパケット
を迅速にフォワーディングするためにヘッダのオプションを無視するタイプのル
ータを使用しているネットワークでは最適には動作しない。したがって別の実施
例では指標ルーティングプロトコルがＩＰプロトコルのファミリーの一部として
構成され、異なるバージョン数のＩＰとして当該のＩＰと共存する。この実施例
はＩＰの全てのリンクカプセル上で動作できる点が有利であり、ＩＰｖ５に類似
した別のプロトコルがあっても問題ない。ＩＰｖ５はＳＴ２＋プロトコルとして
も知られており、これについてはL.Delgrossi & L.Berger, "Internet Stream P
rotocol Version2 (ST2) Protocol Specification-VersionST2+", RFC1819, Aug
.1995 に記載されている。またこの種の実施例はＩＰｖ４のインプリメンテーシ
ョンを使用するインターネットワーキングでは動作しない。これはパケットヘッ
ダ内のバージョンフィールドがチェックされず、そのためにＩＰｖ５のパケット
を受信したときに混乱してしまうからである。さらにＩＰプロトコル数は８ｂｉ
ｔ幅の数から導出されるため、これを公的に得ることも困難である。
【００７５】 ここでは指標ルーティングプロトコルがＩＰヘッダオプションを用いたＩＰの
一部としてネットワーク層内に構成される実施例を説明する。クラスと数とが付
され、それぞれ定義されたＩＰヘッダオプションは種々のＩＰオプションのタイ
プを表している。例えば現在定義されているＩＰヘッダオプションには資格確認
情報およびグループメンバシップ情報（セキュリティオプション−クラス０、数
２）、パケットが宛先にいたるまでに通過するルータを表す情報（ルーソースル
ーティング−クラス０、数３）、およびここには挙げないが他のオプションなど
が存在する。図９には１ｂｙｔｅのオプションタイプフィールド３４１が示され
ており、このフィールドはこの実施例ではコピーフラグ３４３、クラスフィール
ド３４５、および数フィールド３４７を含んでいる。ＩＰヘッダオプションでは
指標ＩＰオプションのためのコピーフラグ３４３は１に設定され、パケットの全
ての断片またはコピーは指標ヘッダオプション情報を含む。指標ＩＰオプション
は指標宛先としての宛先を定義しており、０に設定されたクラスフラグ３４５を
有している。なぜならこれによりどのようにパケットがルーティングされるかが
制御されるからである。割り当てのないＩＰヘッダオプションの数の値、例えば
１０は数フィールド３４７のために用いられ、これにより指標ＩＰオプションと
称される新たなＩＰヘッダオプションが定められる。したがって１つの実施例で
は、指標ＩＰオプションが０に設定されたコピーフラグと０に設定されたクラス
フラグと１０に設定された数フラグとを有しており、指標オプションコードは０
×８Ａとなる。この実施例では、指標ルーティングはＩＰヘッダに対して個々に
定義されたオプションとして示されており、上述したように、付加的なフィール
ド（１つの指標ルーティングのバージョンに対して、大域的に独自の識別子や、
指標の集合、前述の指標ルーティング固有フラグなどのフィールドが相当）が従
来のＩＰネットワークパケットのペイロードに付加される。図９に関連して説明
した実施例によれば、有利には、指標ルーティングを用いてルーティングされた
パケットにおいてＩＰがその上で走っている全てのリンク層プロトコルの利点が
活用され、またＩＰ上を走っているトランスポート層プロトコル（ＵＤＰなど）
でもただちに指標ルーティングによって得られる付加的な機能の利点を得ること
ができ、その際にも残りのアプリケーションの再符号化量は最小限に保持される
。ただしこの実施例はパケットを迅速にフォワーディングするためにＩＰヘッダ
オプションを無視するある種の一般的なルータを用いるネットワークでは最適に
は動作しない。ＩＰヘッダオプションを無視するルータを用いたネットワークで
も最適に動作させるために、個別の指標オプションヘッダが典型的なＩＰヘッダ
に加えて使用される。パケットヘッダ３５１は図１０に示されており、ここには
典型的なＩＰヘッダについて拡張された指標ルーティングオプションの本発明の
実施例が示されている。特にパケットヘッダ３５１は典型的なＩＰヘッダ３５３
、指標オプションヘッダ３５５、およびＵＤＰヘッダ３５７を含んでいる。ＵＤ
Ｐヘッダ３５７に続いてパケットデータを含むデータペイロードフィールド３５
９と、従来のペイロード部に続く（図示されていない）他のフィールドとが設け
られる。ＩＰヘッダとこれに続く指標ルーティングオプション拡張部とは効率的
にパケットから宛先指標を備えたＵＤＰデータグラムを形成する。ＩＰヘッダ３
５３内のプロトコル数フィールド３６１はＩＰヘッダ３５３に続くヘッダのタイ
プを表している。例えばＵＤＰプロトコル数１７はＩＰヘッダ３５３の直後に続
くＵＤＰヘッダ３５７の有無を表すために用いられる。この実施例では、予め定
められた指標ルーティングプロトコル数、すなわち現在割り当てのないＩＰプロ
トコル数（例えば２５４）がＩＰヘッダ３５３に続く指標オプションヘッダ３５
５の有無を表すために用いられる。したがって指標ルータはＩＰヘッダ３５３の
プロトコルフィールド３６１を備えたパケットを受信したことに応じてこのパケ
ットをルータ内の指標ルーティング固有コードへ通し、パケットがＩＰ基準でな
く指標基準にしたがってフォワーディングされるようにする。指標ルータは正規
のＩＰルータのみを備えたネットワーク全域にわたって分布しているので、各指
標ルータはネクストホップ指標ルータのＩＰアドレスをＩＰヘッダ３５３の宛先
ＩＰアドレスフィールド３６３内に配置する。
【００７６】 図１０に示されている実施例では、トレイルブレージングパケットは既に送信
され、大域的に独自の識別子が特定の値、例えば０×８００６０５３５２ＥＥ０
０００１（１２８．６．５．５３＋１２０００＋１から形成される）へ設定され
る。パケットはＩＰアドレス１２８．６．５．５３、ポート番号１２０００、お
よび宛先ポート番号１５０００から送信される。図１０に示されているように指
標オプションヘッダ３５５はオプションコードフィールド３７１、オプション長
フィールド３７３、指標ヘッダバージョンフィールド３７５、指標固有ヘッダフ
ラグフィールド３７７、および大域的に独自の識別子フィールド３７９が含まれ
る。オプションコードフィールド３７１は０×８Ａに設定されており、これは図
９に則して説明したときと同様である。オプション長フィールド３７３は指標オ
プションヘッダ３５５およびデータフィールド３５９のパケットデータ（この実
施例では６ｂｙｔｅ）の全長のｂｙｔｅにおける所定の値（この実施例では１８
）に設定されている。指標ヘッダバージョンフィールド３７５は指標ルーティン
グプロトコルの特定のバージョン数に設定されている（この実施例ではバージョ
ンは１である）。指標固有ヘッダフラグフィールド３７７は予め定められた値に
設定されており、CHARCAST＿TRAILBLASER＿PACKET、CHARCAST＿ORIGINAL＿CHARA
CTERISTICS＿REQUEST、またはCHARCAST＿ORIGINAL＿CHARACTERISTICSを上述のよ
うに表している。大域的に独自の識別子フィールド３７９は送信ＩＰアドレス、
ポート番号および連続番号を含んでおり、このことは図７に関連して説明した通
りである。
【００７７】 ３． トランスポート層のＩＰよりも上位のインプリメンテーション 別の実施例によれば、図１１にはＩＰヘッダ直後の指標ヘッダを使用する指標
ルーティングパケットの例が示されている。特にパケットヘッダ４０１は典型的
なＩＰヘッダ４０３と指標ヘッダ４０５とを含んでいる。この実施例によれば、
ＩＰヘッダ４０３内のプロトコル数フィールド４０７はＩＰヘッダ４０３に続く
ヘッダのタイプを表している。この実施例では予め定められた指標ルーティング
プロトコル数、すなわち現在のところ割り当てのないＩＰプロトコル数（例えば
２５４）がＩＰヘッダ４０３に続く指標オプションヘッダ４０５の有無を表すた
めに用いられる。したがって指標ルータはＩＰヘッダ４０３のプロトコルフィー
ルド４０７を有するパケットを受信したことに応じてこのパケットをルータ内の
指標ルーティング固有コードへ通し、パケットがＩＰ基準でなく指標基準にした
がってフォワーディングされるようにする。指標ルータは正規のＩＰルータのみ
を備えたネットワーク全域にわたって分布しているので、各指標ルータはネクス
トホップ指標ルータのＩＰアドレスをＩＰヘッダ４０３の宛先ＩＰアドレスフィ
ールド４０９内に配置することになる。
【００７８】 図１１に示されている実施例では、トレイルブレージングパケットは既に送信
され、大域的に独自の識別子が特定の値、例えば０×８００６０５３５２ＥＥ０
０００１（１２８．６．５．５３＋１２０００＋１から形成される）へ設定され
る。パケットはＩＰアドレス１２８．６．５．５３、ポート番号１２０００、お
よび宛先ポート番号１５０００で送信される。図１１に示されているように指標
ヘッダ４０５は指標ヘッダバージョンフィールド４１１、指標固有ヘッダフラグ
フィールド４１３、指標ヘッダアンドデータチェックサムフィールド４１５、指
標ヘッダアンドデータ長フィールド４１７、大域的に独自の識別子フィールド４
１９、宛先ポート番号フィールド４２１、および送信機ポート番号フィールド４
２３が含まれる。指標ヘッダ４０５に続いてデータフィールド４２５が設けられ
ている。指標ヘッダバージョンフィールド４１１は使用される指標ルーティング
プロトコルの特定のバージョン数に設定されている（この実施例ではバージョン
は１である）。指標固有ヘッダフラグフィールド４１３は予め定められた値に設
定されており、CHARCAST＿TRAILBLASER＿PACKET、CHARCAST＿ORIGINAL＿CHARACT
ERISTICS＿REQUEST、またはCHARCAST＿ORIGINAL＿CHARACTERISTICSを上述のよう
に表している。
【００７９】 指標ルーティングヘッダアンドデータチェックサムフィールド４１５は指標ヘ
ッダおよびデータのエラーなしでの到着を検査するチェックサム値を含んでいる
。送信機から受信機のセットへ至る経路上のルータはこのチェックサムを検討し
なければならない。指標ルーティングヘッダアンドデータ長フィールド４１７は
データフィールド４２５の指標ヘッダ４０５およびデータ（この実施例では４ｂ
ｙｔｅ）の全長ｂｙｔｅにおける所定の値（この実施例では２２）に設定されて
いる。大域的に独自の識別子フィールド４１９は送信ＩＰアドレス、ポート番号
および連続番号を含んでおり、このことは図７に関連して説明した通りである。
宛先ポート番号フィールド４２１はパケット送信すべきＩＰポート番号を含んで
おり、送信機ポート番号フィールド４２３は送信機のＩＰポート番号を含んでい
る。送信機のソケットが特定のインターネット名前空間に結合されておらず、パ
ケットを送信するアプリケーションが宛先に関連するポート番号を有していない
場合には、送信機ポート番号フィールド４２３の値は０となる。
【００８０】 ただしネットワーク層のインプリメンテーションまたは上述のデータリンク層
のインプリメンテーションが使用される場合には、（図１１に関連して説明した
ように）トランスポート層のＩＰよりも上位で指標ルーティングを用いる実施例
が有利であり、本発明によりＩＰの機能を所望のように利用することができる。
ＩＰはすでに多数のデータリンク層プロトコル上で走っているので、ＩＰ上で動
作する実現形態によれば、有利には自動的に大規模にインストールされている機
能の基盤が活用され、ＩＰネットワーク層サービスの利点が生かされる（例えば
ＩＰパケットフラグメンテーションおよびリアセンブリをデータリンク層ＭＴＵ
を考慮せずに使用できる）。
【００８１】 ＯＳＰＦｖ２、ＲＩＰｖ２、ＤＶＭＲＰなどの幾つかのプロトコルはすでにネ
ットワークトポロジーのディスカバリとルーティングテーブルの自動コンフィギ
ュレーションとのために存在しており、本発明は種々のプロトコルの拡張のため
に指標ルーティング情報を実施例に応じて調整することができる。例えばＣｈａ
ｒＯＳＰＦ、ＣｈａｒＲＩＰ、ＣｈａｒＢＰ（後述）などのネットワークスタッ
ク位置が図１２に示されている。ＣｈａｒＯＳＰＦ、ＣｈａｒＲＩＰ、Ｃｈａｒ
ＢＰを用いる構成は図１１に則して説明した指標ヘッダフォーマットを使用でき
る。ＣｈａｒＯＳＰＦは本発明の実施例によるＯＳＰＦｖ２の拡張指標ルーティ
ングプロトコルである。ＣｈａｒＲＩＰは別の実施例によるＲＩＰｖ２の仕様を
変更せずこれを拡張した拡張指標ルーティングプロトコルである。ＣｈａｒＢＰ
は別の実施例によるＤＶＭＲＰの修正指標ルーティングプロトコルである。Ｃｈ
ａｒＯＳＰＦはルーティングのための最短経路法であり、ＣｈａｒＲＩＰ、Ｃｈ
ａｒＢＰは両方ともルーティングのための距離ベクトル法である。簡単化のため
にＣｈａｒＯＳＰＦ、ＣｈａｒＲＩＰ、ＣｈａｒＢＰの詳細は代表的な実施例を
挙げて後述する。また他の既存のネットワークトポロジーコンフィギュレーショ
ンプロトコルに類似した拡張指標ルーティング、例えばＢＧＰ、ＩＧＲＰ、ＰＩ
ＭまたはＣＢＴなども使用可能であることを指摘しておく。ルーティングのため
の経路探索法における他のプロトコルは、J.J.Garcia-Luna-Aceves & S.Murthy,
"A Path Finding Algorithm for Loop-Free Routing", IEEE/ACM Trans.Networ
king, Feb.1997 に記載されている。
【００８２】 ループなしのルーティングを行うのに必要な情報量について云えば、リンクス
テートの最短経路法（ＣｈａｒＯＳＰＦ）は最大情報を要求し、距離ベクトル法
（ＣｈａｒＲＩＰ、ＣｈａｒＢＰ）は最小情報を要求し、経路探索法は最短経路
法と距離ベクトル法とによって要求される情報の中間の情報量を要求する。パケ
ットフォワーディング前に拡張プロトコル（ＣｈａｒＯＳＰＦ、ＣｈａｒＲＩＰ
、ＣｈａｒＢＰ）で開始できる情報量は後に送信すべきプルーンメッセージの数
を直接に制御および処理して、これにより第１のｃｈａｒｃａｓｔメッセージを
フォワーディングして得られるルーティングツリーを剪定する。特にＣｈａｒＯ
ＳＰＦはネットワークトポロジーの完全な知識をネットワークデータベースに有
しており、このデータベースに働きかけてプルーン作業の要らないルーティング
ツリーを形成することができる。ＣｈａｒＲＩＰはネットワークの知識が不完全
であり、剪定すべきルーティングツリーとして得られた各宛先までのホップの最
小回数のみを既知としている。ＣｈａｒＢＰはルーティングテーブルのみを用い
てパケットが送信機からの最短経路で到着することを保証し、パケットをフォワ
ーディングするためにブロードキャスト・アンド・プルーンを使用する。Ｃｈａ
ｒＯＳＰＦ、ＣｈａｒＲＩＰ、ＣｈａｒＢＰはそれぞれソースベースのｃｈａｒ
ｃａｓｔルーティングツリーを形成しており、ここでＣｈａｒＯＳＰＦ、Ｃｈａ
ｒＲＩＰは全てのネットワークの指標到達情報をブロードキャストし、Ｃｈａｒ
ＢＰは簡単なブロードキャスト・アンド・プルーン法を使用する。ＣｈａｒＯＳ
ＰＦ、ＣｈａｒＲＩＰ、ＣｈａｒＢＰはデータ駆動型のプロトコルであり、全て
のルーティング決定は特定の送信機からの第１のデータパケットと特定の宛先指
標とが得られたときに形成される。
【００８３】 ＣｈａｒＯＳＰＦ、ＣｈａｒＲＩＰ、ＣｈａｒＢＰは既存のネットワークトポ
ロジーコンフィギュレーションプロトコルを拡張する指標ルーティングの例とし
て使用される。なぜならここではフォワーディングされたパケットの実行前にデ
ータベース内に収集および記憶すべき情報量についての取り決めが交わされるか
らである。ＣｈａｒＯＳＰＦ、ＣｈａｒＲＩＰ、ＣｈａｒＢＰおよびトランスポ
ート層プロトコル上で動作する他の指標ルーティングの構成によれば付加的なサ
ービスを得ることができる。例えばＵＤＰまたはＴＣＰ上で動作する実現形態は
付加的なチェックサムを使用することができ、これにより受信されたプロトコル
パケットの正確性を評価することができる。ＵＤＰまたはＴＣＰ上で動作する実
現形態はユーザスペース内でも特別な制約なしに動作することができる（逆に直
接にＩＰ上で動作する実現形態は使用のためにスーパーユーザ許可を要求する生
のソケットを使用しなければならない）。ＵＤＰまたはＴＣＰ上で動作する実現
形態は一層簡単に数の１６ｂｉｔ幅から導出されたポート番号を用いてプロトコ
ルまたはプロトコルのコンポーネントを区別することができる。さらにＴＣＰ上
を走る実現形態は全てのプロトコル情報の確実な供給を保証する。代表的な実現
形態、すなわちＵＤＰ上を走るＣｈａｒＲＩＰ、ＩＰ上を走るＣｈａｒＢＰ、お
よびＩＰ上を走るＣｈａｒＯＳＰＦについて説明する。
【００８４】 ａ． ＣｈａｒＯＳＰＦ トランスポート層プロトコル上を走るＣｈａｒＯＳＰＦは本発明の実施例によ
ればＯＳＰＦｖ２の拡張指標ルーティングプロトコルである。
【００８５】 最短経路法のプロトコル、すなわちOpen Shortest Path Firstプロトコル（J.
Moy, RFC2328で言及されているＯＳＰＦ）は自律的なＩＰシステムのルータ内で
ルーティングされるインターナルゲートウェイプロトコルＩＧＰである。自律シ
ステムは仲間内だけの小さなネットワークから大学全域にわたるキャンパスネッ
トワークまでそのサイズの点で種々の形態を取る。最短経路法を使用するプロト
コル例えばＯＳＰＦは、J.T.Moy, "OSPF:Anatomy of an Internet Routing Prot
ocol", Addison Wesley Publishing Co., Jan.1998 に記載されている方法論に
したがった実施例で拡張される。ＯＳＰＦはリンクステート公示を使用するダイ
ナミックリンクステートルーティングプロトコルであり、これによりネットワー
クトポロジーに関する知識がユニキャストおよび／またはマルチキャストルーテ
ィングに基づいて通用される。ダイナミックプロトコルとしてＯＳＰＦは迅速に
接続されたサブネットのステータスの変更を検出し、リンクステート公示により
これを放流してその変更を自律システム全域に公示する。ＯＳＰＦでは各ルータ
は直接に接しているサブネットのステータスを公示し、その公示を他のルータへ
フォワーディングする責任を有している。プロトコルの一部として各ルータは完
全な自律システムのトポロジーを記述するデータベースを維持する。このデータ
ベースは自律システム内の全てのノードおよびリンクを記述しているのでリンク
ステートデータベースと称されている。全てのルータが付随するサブネットのス
テータスを放流した後、全てのルータは同じリンクステートデータベースを有す
る。各ルータはダイクストラの最短経路アルゴリズムＳＰＦをリンクステートデ
ータベースについて実行し、これによりループのない最短経路のツリーを計算す
る。ここでこのツリーの本は自身であり、末は自律システムの全ての宛先である
。最短経路を計算するために、各リンクに次元のない単独のメトリックがそれを
公示したルータによって割り当てられる。宛先に至るまでにコストの等しいユニ
キャスト経路が複数存在する場合には、ＩＰトラフィックはそれらに等しく分配
される。ルータが放流されたサブネットのステータス変更、例えばリンクゴーイ
ングダウンを受け取った場合にはいつでも、ダイクストラのアルゴリズムが再起
動され、最短経路のツリーが再計算される。
【００８６】 ＯＳＰＦによれば自律システム内で定義される２レベル階層ルーティングスキ
ーマが得られ、これにより大規模なネットワークが構築される。隣接しているク
ラスタ化され、エリアと呼ばれるグループにまとめられる。２つのエリアの境界
は共通に使用しているルータである。これにより各サブネットが完全に１つのエ
リア内に含まれる。１つのエリア内部では、通常のＯＳＰＦルーティングが上述
のように行われる。ただしアドレシング情報はエリア境界を越える公示があって
詳細なエリアのトポロジー情報が残りの自律システムからは隠されている。こう
した情報の秘匿からは２つの利点が得られる。すなわち第１に自律システムの全
域にわたるルーティングテーブルのサイズが低減され、第２にエリア内のトポロ
ジー変更が残りの自律システムから隠されるので、ルーティングテーブルを維持
するのに必要なルーティングトラフィックも低減されるのである。
【００８７】 ＣｈａｒＯＳＰＦを使用する実施例によれば、新たなリンクステート公示は指
標ルーティングに関連して先行のリンクステート公示に加えて使用される。指標
ルーティングはユニキャストおよびマルチキャストに使用される先行のリンクス
テート公示を参照している。したがって指標情報はルーティングテーブル内の既
存のユニキャスト／マルチキャストエントリへ付加される。
【００８８】 ＣｈａｒＯＳＰＦはデータ駆動型およびソースベース型のルーティングプロト
コルであり、本発明の実施例によれば２つの手法でＯＳＰＦが拡張される。
【００８９】 第１に、ＣｈａｒＯＳＰＦはＯＳＰＦの階層的なエリア間の抽象化を拡張する
。エリア間での機構情報が公示されるとき、公示ルータはＣｈａｒＯＳＰＦエリ
ア内のサブネットの指標を統合した概要を公示する。ＣｈａｒＯＳＰＦによるこ
の指標の概要は続いてエリアからエリアへフォワーディングされ、そのエリア内
で公示される。したがってＣｈａｒＯＳＰＦエリア内の個々のルータは他のエリ
アの指標の到達状態について知識を得、当該のＣｈａｒＯＳＰＦエリアによって
カバーされている指標エリアへのキャルキャスト（charcast）の際に適切な境界
部のルータが使用される。ＣｈａｒＯＳＰＦはＯＳＰＦの既知の階層アスペクト
の利点を活用する。
【００９０】 第２に、ＣｈａｒＯＳＰＦは新たなリンクステート公示ＬＳＡ、いわゆる指標
エリアＬＳＡを付加することによりリンクステートデータベースに含まれるネッ
トワーク記述を増大させる。ＯＳＰＦ内の他のＬＳＡに加えて指標エリアＬＳＡ
を使用することにより、ルータに付随しているネットワークの指標の到達状態が
この指標エリアＬＳＡから記述される。これによりＯＳＰＦルータＬＳＡは置換
というよりもむしろ拡張される。指標エリアＬＳＡは自律システム全域へＬＳＡ
と同様に放流される。エリア放流の視点は１つだけなので、指標エリアＬＳＡは
唯一のエリアにわたってのみ指標ネットワーク情報を分配する。指標エリアＬＳ
Ａは識別用のＬＳＡタイプ数として９を使用する。
【００９１】 ＣｈａｒＯＳＰＦは新たなＣｈａｒビットフラグを８ｂｉｔのＯＳＰＦオプシ
ョンフィールドに組み込み、これによりＯＳＰＦが拡張され、バックワード互換
性が得られる。ＯＳＰＦオプションフィールドは各拡張ＯＳＰＦにフィールド内
の１つのビットを割り当てるが、これによりルータは自分以外のどのルータが特
定の拡張プロトコルを自律システムまたはエリア内で支援しているかを発見する
ことができる。ＯＳＰＦオプションフィールドはＯＳＰＦＨｅｌｌｏパケット、
ＯＳＰＦデータ記述パケット、およびＯＳＰＦＬＳＡの全てに含まれている。図
１３には本発明の実施例によるＣｈａｒＯＳＰＦオプションフィールド４３１が
示されている。Ｃｈａｒビットフラグ４３３をＣｈａｒＯＳＰＦ内に設定するこ
とによりルータはその指標を認識している自分以外のルータにそのことを公示す
ることができる。ＣｈａｒＯＳＰＦオプションフィールド４３１の他のビットは
他の拡張プロトコル、例えば拡張要求回路（ＤＣビット）、ＴＯＳベース拡張ル
ーティング（Ｔビット）、マルチキャスト拡張ルーティングなどを表すように設
定することができる。本発明の実施例によれば、隣接のルータがこの拡張を支援
していると宣言して、所定のルータのみが理解した拡張ＬＳＡをフォワーディン
グするまでは、ＣｈａｒＯＳＰＦなどのＯＳＰＦから導出されたプロトコルを使
用するルータは新たに拡張された隣接のルータのＬＳＡ（拡張指標ルーティング
など）には放流を行わない。
【００９２】 本発明の実施例によれば、図１４にはＣｈａｒＯＳＰＦで使用される指標エリ
アＬＳＡの実施例が示されている。指標エリアＬＳＡパケット４４１はＬＳＡヘ
ッダ４４３と指標ルーティングＬＳＡ拡張部４４５とを含んでいる。前述したよ
うに、指標エリアＬＳＡはルータＬＳＡ情報（サブネットのＩＰアドレス、マス
クおよびメトリック）を拡張する。これはサブネットの指標情報を有し、このサ
ブネットを記述するルータＬＳＡが先行して伝達されていることを通知すること
によって行われる。ＬＳＡヘッダ４４３はＯＳＰＦで使用される標準のＬＳＡヘ
ッダであるが、次の例外を含む。すなわち、オプションフィールド４４７は（図
１３に関連して説明したように）当該のルータが指標ルータであることを表すよ
うに設定されたＣｈａｒビットを有する；ＬＳタイプフィールド４４９はＣｈａ
ｒＯＳＰＦエリアＬＳＡのタイプ数９に設定されている；リンクステートＩＤフ
ィールド４５１は指標エリアＬＳＡが参照されるルータＬＳＡのリンクステート
ＩＤに設定される。指標ルーティングＬＳＡ拡張部４４５は参照リンクステート
ＬＳのタイプフィールド４５３と信号リスト４５５として符号化されたサブネッ
トの指標とを含む（これは図８に関連して説明したのと同様である）。参照ＬＳ
タイプフィールド４５３は参照リンクステートＩＤのリンクステートタイプをＬ
ＳＡヘッダ４４３のフィールド４５１内に含む。リンクステートタイプ情報は１
つ以上のエントリが同じリンクステートＩＤを有する場合に正確なリンクステー
トＩＤの適合の補助として用いられる。この実施例では、指標リスト４５５は２
つの要素４５７、４５９を有しているが、別の実施例にしたがって異なる個数の
要素をリストに設けてもよい。図１４の実施例は指標エリアＬＳＡであり、これ
はサブネット１２８．６．５．０／２４を記述していて先行して記述を行ったル
ータＬＳＡを参照している。リンクステートＩＤは１２８．６．５．０に設定さ
れており、参照ＬＳタイプフィールドはネットワークのタイプを表すために２に
設定されている。
【００９３】 ｂ． ＣｈａｒＲＩＰ 上述のように、ある特定の実施形態によれば、トランスポートレイヤープロト
コルで実行されるＣｈａｒＲＩＰは、ＲＩＰｖ２の指標ルーティングプロトコル
拡張であり、ＲＩＰの仕様は変更せず、単にそれを拡大しただけである。
【００９４】 （“RIP Version 2”（１９９８年１１月）と題するＲＦＣ ２４５３におい
て G. Malkin が説明しているような）ＲＩＰｖ２は、自律システム内のルータ
およびネットワークの間でＩＰパケットをルーティングするためのインターナル
ゲートウェイプロトコル（ＩＧＰ）である。ＲＩＰは、インターネットで使用さ
れる最初期のルーティングプロトコルのうちの１つとして、今日でも広く使用さ
れている。比較的新しいＩＧＰがより強力であるのに対して、ＲＩＰは生存可能
な代案としての利点をいまだに有している。ＲＩＰは、その相対的な簡単さのた
め、オーバーヘッド（使用される帯域の観点からの）、コンフィギュレーション
およびマネージメントを最小限に抑えることができる。また、ＲＩＰの記述は比
較的新しいＩＧＰの１／５のサイズであるため、ＲＩＰの実施は格段に容易であ
り、ＲＩＰのコードの占有面積は比較的小さい。しかしながらＲＩＰは、せいぜ
い中規模の自律システムでの使用に限定されており、大規模自律システムでの使
用には最適ではない。ＲＩＰは、Ｂｅｌｌｍａｎ方程式から導出されるＢｅｌｌ
ｍａｎ−Ｆｏｒｄアルゴリズム（ＦｏｒｄおよびＦｕｌｋｅｒｓｏｎのアルゴリ
ズムとしても知られている）に基づいた動的距離ベクトル（Distance Vector）
プロトコルである。
【００９５】 ＲＩＰを使用する際、ルータは各自のルーティングテーブル情報を近隣のルー
タと交換することによってネットワークに関する知識を蓄積する。ルーティング
テーブル情報は、既知のすべての宛先のリストと、パケットが特定の宛先に到達
するのに移動しなければならないルータホップの個数の形で表されるメトリック
と、前記宛先までのパス上での次のホップである近隣ルータとから成る。ルータ
は、まずすべての宛先のメトリックを１だけ増分し、つぎにテーブル全体をブロ
ードキャスト通信により広告することによって、ルーティングテーブル情報を周
期的に交換する。ルータはまた特定の宛先に対するルーティングテーブルのエン
トリを相互に明示的に要求する。
【００９６】 ルータは、近隣のルータからルーティングテーブルの広告を受け取ると、各々
の宛先に対する広告に含まれているメトリックを自身のルーティングテーブルに
含まれているメトリックと比較する。広告されたメトリックの方が小さければ、
ルータは前記宛先に対するメトリックを自身のルーティングテーブルに挿入し、
前記宛先に対する次ホップのルータが広告を送ったルータになるように変更する
。
【００９７】 ネットワークの一部は、“counting to infinity”と呼ばれる、ＲＩＰの第１
バージョン（ＲＩＰｖ１）における問題が原因でアクセス不能となることがある
。これはリンクが失敗したときに生じるルーティングループに起因する。ＲＩＰ
の第２バージョン（ＲＩＰｖ２）では、この問題を克服するために２つの方法、
すなわち、汚染されたリバースを有する水平線（horizon）の分割およびアップ
デートのトリガが導入された。汚染されたリバースを有する水平線の分割は、ル
ータＡが近隣ルータＢから知らされたルータメトリックを無限に設定することで
自身のルーティングテーブル広告を近隣ルータＢに移すようにルータＡに要求す
ることによって、２つのルータしか含まない任意のルーティングループを回避す
る。しかしながら、これでもなおルーティングループに陥る可能性があるので（
３つまたはそれ以上のルータのループも可能である）、トリガされたアップデー
トは、ルートに対するメトリックが変化したときにルータが直ちにアップデート
メッセージを送るよう要求することによって、ループの収束の加速を試みる。
【００９８】 ＣｈａｒＲＩＰは、現在のＲＩＰプロトコル仕様を変更せずに、認証がＲＩＰ
に加えられたのと同様の仕方で現在のＲＩＰプロトコル仕様を拡大する。特に、
ＣｈａｒＲＩＰは、指標情報ルートエントリ（Characteristic Information Rou
te Entry）を可能なルートエントリのリストに付加することによってネットワー
ク中の指標ルーティングテーブル情報を拡散させる。ある特定の実施形態によれ
ば、指標情報ルートエントリは、通常のＲＩＰルートエントリのアドレスファミ
リー（Address Family）フィールド内の事前定義された６値（例えば０ｘＦＦＦ
Ｅのような）を使用して識別される。下のテーブル２には、この特定の実施形態
による、ＣｈａｒＲＩＰに対する可能なアドレスファミリーフィールドの値のリ
ストが示されている。指標情報ルートエントリは、通常のＲＩＰルートエントリ
のすべてのスペースを使用する。というのも、ＲＩＰはルーティングテーブルの
アップデートにおいてルートエントリの個数を表示しないからである。ルーティ
ングテーブルを受け取ったルータは、アップデートのサイズをルートエントリの
サイズで除することによってルートエントリの個数を計算する。
【００９９】
【表１】
【０１００】 ＲＩＰｖ１またはＲＩＰｖ２ルータは、アドレスファミリーフィールド内の指
標情報ルートエントリの値を無視する。というのも、アドレスファミリーフィー
ルド内の指標情報ルートエントリの値は、ＩＰアドレスファミリールートエント
リとしても認証ルートエントリとしても識別されないからである。特定の実施形
態では、ＣｈａｒＲＩＰルーティングテーブルアップデートがＲＩＰバージョン
３（ＲＩＰｖ３）と標されているが、それは、ＲＩＰｖ１およびＲＩＰｖ２によ
る、上位バージョンのルーティングテーブルアップデートメッセージの処理の仕
方に起因するものである。特に、ＲＩＰｖ１またはＲＩＰｖ２ルータはバージョ
ン０のすべてのメッセージを棄却し、いずれかのＭｕｓｔ Ｂｅ Ｚｅｒｏ（Ｍ
ＢＺ）フィールドが非ゼロである場合は、バージョン１のメッセージを棄却し、
単にＭＢＺフィールドが非ゼロ値を有するという理由だけで、１より高い任意の
バージョンのメッセージは棄却しない。したがって、ＲＩＰｖ３として指示され
たＣｈａｒＲＩＰを使用すれば、ＣｈａｒＲＩＰは、以前のＲＩＰバージョンが
この動作を維持する限りは、完全に後向きに以前のＲＩＰバージョンと互換性を
持つことができる。ＣｈａｒＲＩＰルータは、ＲＩＰｖ１またはＲＩＰｖ２ルー
ティングテーブルエントリ要求を受け取ると、適切なバージョンのルーティング
テーブル広告に応答する。
【０１０１】 ＲＩＰルートエントリの空間的制限のため、指標情報ルートエントリは特定の
宛先に関するすべての情報を保持することはできない。むしろ、指標情報ルート
エントリは、以前に広告された特定の宛先に関する情報を増やす。特定の実施形
態によれば、ＣｈａｒＲＩＰルーティングテーブル広告パケットまたはレスポン
スパケットは、少なくとも３つの区分された部分を有している。これら３つの区
分された部分とは、すなわち、パケットがＣｈａｒＲＩＰパケットを含んでいる
ことを示す、バージョン番号が３に設定された標準ＲＩＰヘッダと、特定の宛先
に対する通常のＲＩＰｖ２ルートエントリと、この通常のＲＩＰｖ２ルートエン
トリによって記述される特定の宛先の指標を含む指標情報ルートエントリである
。ネットワークのすべての指標が単一の指標情報ルートエントリに適合しそうに
ない場合は、指標は単一のリストとして符号化され、この符号が複数のルートエ
ントリの間で分割される指標の単一ストリングとして扱われる。そして、これら
の指標情報ルートエントリはＣｈａｒＲＩＰパケット内に順番に配置され、これ
らルートエントリ内の情報は、指標リストの元々の符号化を再現するため受信端
で結合される。したがって、ＣｈａｒＲＩＰパケット内の第１の指標情報ルート
エントリは、（図２によるような）指標アドレスファミリー識別子と、基準とな
るＩＰアドレスと、符号化された指標リストの第１の部分を含んでいる。同じＣ
ｈａｒＲＩＰパケット内の以降のすべての指標情報ルートエントリは、指標アド
レスファミリー識別子と符号化された指標リストの後続セクションとを含んでい
る。
【０１０２】 この特定の実施形態にしたがって、図１５にはＣｈａｒＲＩＰパケット４６１
の例が示されている。ＣｈａｒＲＩＰパケット４６１は、ＲＩＰヘッダ４６３と
、通常のＲＩＰｖ２ルートエントリ４６５と、指標情報ルートエントリ４６７を
含んでいる。より具体的には、図１５には、ＩＰアドレス１２８．６．５．０．
のためのルーティングテーブルエントリに対する近隣ルータによる以前の要求へ
のＣｈａｒＲＩＰレスポンスパケットが示されている。このパケットはレスポン
スパケットなので、ＲＩＰヘッダ４６３のコマンドフィールドは２（レスポンス
メッセージを表す）にセットされる。ＲＩＰヘッダ４６３のバージョンフィール
ドは３にセットされ、この３によって、これがＣｈａｒＲＩＰパケットであるこ
とが表されている。パケット４６１のＲＩＰｖ２部分４６５は、この宛先に関す
る通常のルートエントリ情報を含んでいる。これに続く指標情報ルートエントリ
４６７は、アドレスフィールド４７３と、基準となるＩＰアドレスフィールド４
７５と、指標リスト４７７を含んでいる。上述したように、アドレスフィールド
４７３は指標情報が含まれていることを識別するため０ｘＦＦＦＥにセットされ
る。基準ＩＰアドレスフィールド４７５は、基準となるＲＩＰｖ２ルートエント
リ４６５のＩＰアドレスフィールド４８３内の同じＩＰアドレスを含んでいる。
ＲＩＰｖ２ルートエントリ４６５のルートタグフィールド４８５は、これが内部
ルートであることを表すためにゼロにセットされる。この実施例では、指標情報
ルートエントリ４６７内の指標リスト４７７は、要素４７９および４８１と符号
化された２つの指標を含んでいる。もちろん、他の例では、異なる個数の指標が
リストに含まれていてもよい。
【０１０３】 ｃ． ＣｈａｒＢＰ さらに別の特定の実施形態によれば、ＣｈａｒＢＰは（Waitzman, D. C. Patr
idge および S.Deering による“Distance Vector Multicast Routing Protocol
”RFC 1075，１９９８年１１月に記載されているような）ＤＶＭＲＰの指標ルー
ティングプロトコルの変形である。ＣｈａｒＢＰは、距離ベクトル技術を使用し
てルータホップ内の最短距離に関する知識をすべての潜在的パケットソースに拡
散させるブロードキャスト−プルーンプロトコルである。このように、Ｃｈａｒ
ＢＰはその動作方式の点でリバースＲＩＰと類似している。各々のＣｈａｒＢＰ
ルータは既知のソースのリストとそのソースまでのルータの（ルータホップにお
ける）距離を周期的に近隣のルータにブロードキャスト通信する。そして、各々
のＣｈａｒＢＰルータは、ソースから最短の距離を広告する近隣ルータを選択す
ることによって、各ソースへのパスに対する前ホップを決定する。ＣｈａｒＢＰ
は、ＲＩＰや他の距離ベクトルプロトコルが抱えているのと同じ収束問題を抱え
ており、汚染されたリバースを有する水平線を分割する方法を使用してこの問題
を緩和し、抑制することをねらいとしている。
【０１０４】 特定の実施形態にしたがって、図１６には、例としてＣｈａｒＢＰパケット５
０１が図示されている。この実施形態では、ＣｈａｒＢＰはＩＧＭＰによってカ
プセル化されており、ＣｈａｒＢＰパケット５０１は、ＩＧＭＰヘッダ５０３と
ＣｈａｒＢＰヘッダ５０５を含んでいる。ＩＧＭＰヘッダ５０３は、タイプフィ
ールド５０７とサブタイプフィールド５０９を含んでいる。ＣｈａｒＢＰパケッ
トは、いまのところ割当てされていない定義済みＩＧＭＰタイプとして符号化さ
れる。例えば、ＣｈａｒＢＰパケットが、タイプフィールド５０７内のＩＧＭＰ
タイプ０ｘ２０を使用することもあり得る。サブタイプフィールド５０９はＣｈ
ａｒＢＰパケットタイプ（例えば、ＣｈａｒＢＰルータを探査するＣｈａｒＢＰ
プローブパケット、ルート報告を要求するＣｈａｒＢＰルート報告パケット、プ
ローブパケットもしくはルート報告パケットに応答するＣｈａｒＢＰレスポンス
パケット、またはプルーンの実行を指示するＣｈａｒＢＰプルーンパケット）を
示している。より具体的には、図１６には、ＩＰアドレス１２８．６．５．０．
のためのソーステーブルエントリに対する近隣ルータの以前の要求へのＣｈａｒ
ＢＰレスポンスパケットが示されている。これはレスポンスパケットであるので
、ＩＧＭＰヘッダ５０３のサブタイプフィールド５０９は１（レスポンスメッセ
ージを表す）にセットされている。ＣｈａｒＢＰはＤＶＭＲＰの修正バージョン
なので、ＣｈａｒＢＰはＤＶＭＲＰルーティングコントロールメッセージコマン
ドの部分集合を使用する。ＣｈａｒＢＰによって使用されるＤＶＭＲＰコマンド
の部分集合はテーブル３に示されている。ＣｈａｒＢＰヘッダ５０５には、ルー
トを定義するのに必要な情報が含まれている。すなわち、メトリック（メトリッ
クコマンドフィールド５１３およびメトリック値フィールド５１５）、無限値（
無限コマンドフィールド５１７および無限値フィールド５１９）、フラグ（フラ
グコマンドフィールド５２１およびフラグ値フィールド５２３）、サブネットマ
スク（サブネットマスクコマンドフィールド５２５，カウントフィールド５２７
およびサブネットマスク値フィールド５２９）、およびソースアドレス（ソース
アドレスコマンドフィールド５３１、カウントフィールド５３３およびソースア
ドレス値フィールド５３５）が含まれている。ＲＩＰヘッダ４６３のバージョン
フィールド４７１は３にセットされ、これがＣｈａｒＲＩＰパケットであること
を表している。パケット４６１のＲＩＰｖ２部分４６５には、この宛先に対する
通常のルートエントリ情報が含まれている。それに続く指標情報ルートエントリ
４６７は、アドレスフィールド４７３、基準ＩＰアドレスフィールド４７５、お
よび指標リスト４７７を含んでいる。上述のように、アドレスフィールド４７３
は、指標情報が含まれていることを識別するため０ｘＦＦＦＥにセットされてい
る。基準ＩＰアドレスフィールド４７５は、基準となるＲＩＰｖ２ルートエント
リ４６５のＩＰアドレスフィールド４８３内の同じＩＰアドレスを含んでいる。
ＲＩＰｖ２ルートエントリ４６５のルートタグフィールド４８５はゼロにセット
され、これが内部ルートであることを表している。この実施例では、指標情報ル
ートエントリ４６７内の指標リスト４７７は、要素４７９および４８１として符
号化された２つの指標を含んでいる。もちろん、他の例では、異なる個数の指標
がリストに含まれていてもよい。
【０１０５】
【表２】
【０１０６】 Ｄ． キャラクタリスティック（指標）ルーティングフォワーディングキャッシ
ュおよびルーティングツリー ネットワークトポロジーを知り、自動的にルーティングテーブルを構成するた
めに、ＣｈａｒＯＳＰＦ，ＣｈａｒＲＩＰまたはＣｈａｒＢＰのような拡張され
たプロトコルを使用することで、指標ルータは、ネットワーク内の各々の宛先に
対する指標に基づいたルーティングテーブルエントリを入手する。
【０１０７】 フォワーディングコストを削減するため、指標ルータは最も近時の指標メッセ
ージパケットの次ホップ宛先のキャッシュを保持する。各々の＜sender address
,destination characteristics＞コンビネーションに対して、個別のキャッシュ
エントリが存在する。典型的には、ＣｈａｒＲＯＵＴＥＲが見る＜sender addre
ss,destination characteristics＞コンビネーションに対する第１のパケットは
、トレールブレージングパケットであり、キャッシュエントリを作成し定置させ
る。指標ルータは、指標メッセージパケットを受け取ると、インプットされたパ
ケット送信側ＩＰアドレスおよび宛先指標をともにキャッシュへの鍵として使用
する。これがこの宛先に達する第１のパケットでない場合、およびキャッシュエ
ントリのタイマーがまだ時間切れになっていない場合、キャッシュは、パケット
のコピーが送られるべきすべての近隣ルータのリストを返す。
【０１０８】 特定の実施形態によれば、指標ルータが保持している＜sender address,desti
nation characteristics＞コンビネーションに対する各々のフォワーディングキ
ャッシュエントリは、EXACT＿CHARACTERISTIC＿FLAG を含んでおり、これによっ
て、キャッシュアイテムが、宛先の元々の指標および指標メッセージの元々の宛
先指標のコピーを含んでいるかが示される。元々の宛先指標のコピーは、ルーテ
ィングツリーを作成し、かつルーティングツリーに沿ってルータ内にキャッシュ
エントリを作成した第１のトレールブレージング（trailblazing）パケットから
取られたものである。各々のキャッシュエントリには、この指標メッセージに対
するアップストリームルータに関する情報や指標メッセージの送信側に関する情
報も含まれている。特に、キャッシュエントリには、アップストリームルータの
ＩＰアドレスおよび送信側のＩＰアドレスが含まれている。また、キャッシュエ
ントリには、RECALCULATE＿ENTRY＿FLAG も含まれており、これによって、次の
指標パケットが同じ＜sender address,destination characteristics＞コンビネ
ーションに到達したとき、キャッシュエントリを削除および再計算すべきかが示
される。各々のキャッシュエントリはタイムスタンプを有しており、これにより
、キャッシュエントリの最新アップデートまたはリフレッシュの時期が示される
。キャッシュエントリは、同じ＜sender address,destination characteristics
＞コンビネーションを有する他のパケットが指標ルータを介して転送される度に
リフレッシュされる。また、各々のキャッシュエントリは、同じ＜sender addre
ss,destination characteristics＞コンビネーションを有するすべての指標パケ
ットのコピーを受け取るべき次ホップのダウンストリーム指標ルータのリストも
有している。各々のキャッシュエントリは、キャッシュエントリが送信ホストに
位置している場合には、ORIGINATING＿HOST＿FLAG をセットすることができる。
このフラグをセットすることによって、第１のパケットが自動的に生成され、ト
レールブレージングパケットが送信され、さらにキャッシュエントリは、関連す
るソケットが削除されるまで常駐することになる。最後に、各々のキャッシュエ
ントリは、付加的に、このキャッシュエントリの指標宛先に対する宛先の集合を
記述する各々のルーティングテーブルエントリへのポインタのリストも有してい
る。
【０１０９】 図１７は、ある特定の実施形態にしたがって、指標ルータフォワーディングキ
ャッシュ内のキャッシュエントリと指標ルータのルーティングテーブル内のエン
トリとの間のポインタリンクを図解する図の一例である。図１７に示されている
例では、指標ルータはキャッシュ５５１とルーティングテーブル５５３を有して
いる。キャッシュ５５１には、複数の一意的指標メッセージキャッシュエントリ
が存在する（各々の＜sender address,destination characteristics＞コンビネ
ーションに対して１つのエントリがあり、＜Ｓ，Ｇ＞と略記される。ここで、Ｓ
は送信側を表し、Ｇは指標宛先を表す）。この実施例では、キャッシュ５５１は
、＜Ｓ１，Ｇ１＞コンビネーションに対するキャッシュエントリ５５５、＜Ｓ１
，Ｇ２＞コンビネーションに対するキャッシュエントリ５５７，および＜Ｓ２，
Ｇ３＞コンビネーションに対するキャッシュエントリ５５９を有している。各々
のキャッシュエントリは、このキャッシュエントリの宛先指標に対する宛先の集
合を記述する各々のルーティングテーブルエントリへのポインタ（実線矢印で表
示）のリストを有している。逆に、各々のルーティングテーブルエントリは、こ
のルーティングテーブルエントリを参照するキャッシュエントリへのポインタ（
破線矢印で表示）のリストを有している。図１７の例から分かるように、キャッ
シュエントリ５５５はルーティングテーブルエントリ５６１へのポインタを有し
ている。これは、ノード１が指標メッセージ＜Ｓ１，Ｇ１＞に対する宛先の集合
の唯一の要素だからである。キャッシュエントリ５５７はルーティングテーブル
エントリ５６１および５６７へのポインタを有している。これは、ノード１およ
び４が指標メッセージ＜Ｓ１，Ｇ２＞に対する宛先の集合の一部だからである。
キャッシュエントリ５５９はルーティングテーブルエントリ５６３へのポインタ
を有している。これは、ノード２が指標メッセージ＜Ｓ２，Ｇ３＞に対する宛先
の集合の唯一の要素だからである。ルーティングテーブル５５３では、ルーティ
ングテーブルエントリ５６１は、指標メッセージ＜Ｓ１，Ｇ１＞および＜Ｓ１，
Ｇ２＞に対するキャッシュエントリ５５５および５５７へのポインタを有してい
る。これは、これらキャッシュエントリの両方が、それらの宛先の集合内にノー
ド１を含み、ノード１を参照するからである。ルーティングテーブルエントリ５
６３は指標メッセージ＜Ｓ２，Ｇ３＞に対するキャッシュエントリ５５９へのポ
インタを有している。これは、このキャッシュエントリがその宛先の集合内にノ
ード２を含み、ノード２を参照するからである。ルーティングテーブルエントリ
５６５はいずれのキャッシュへのポインタも有していない。というのも、どのキ
ャッシュエントリもそれの宛先の集合内にノード３を含んでいないからである。
ルーティングテーブルエントリ５６７は指標メッセージ＜Ｓ１，Ｇ２＞に対する
キャッシュエントリ５５７へのポインタを有している。これは、このキャッシュ
エントリがその宛先の集合内にノード４を含み、ノード４を参照するからである
。
【０１１０】 各々の指標ルータは各自のフォワーディングキャッシュを維持する。上述した
ように、典型的には、指標ルータが見る＜sender address,destination charact
eristics＞コンビネーションに対する第１のパケットはトレールブレージングパ
ケットであり、これによりキャッシュエントリが作成され定置されることになる
。キャッシュエントリはソフトな状態であり、周期的にリフレッシュされる間は
存在する。＜sender address,destination characteristics＞コンビネーション
に対する新たなパケットが指標ルータに到達する度に、このコンビネーションに
対するキャッシュエントリが参照され、そのタイムスタンプが更新される。所定
の時間（例えば３０秒）の間、新たなパケットが見られないときには、このキャ
ッシュエントリの情報は失効したものと見なされ、削除される。キャッシュエン
トリがまだ存在し、さらに＜sender address,destination characteristics＞コ
ンビネーションに対する新たなトレールブレージングパケットが到達したときに
は、元のキャッシュエントリは削除され、新たなキャッシュエントリが作成され
定置される。
【０１１１】 指標ルータに、ルーティングテーブル内にリストされた宛先の特定の部分集合
に影響を与えるネットワークトポロジー内の変化を告げる指標ルーティングプロ
トコルコントロールメッセージが到達すると、指標ルータフォワーディングキャ
ッシュもアップデータされなければならない。しかしながら、宛先の指標集合を
新たなネットワークトポロジーに基づいて再計算するには高いコストがかかるの
で、影響を受けるキャッシュエントリだけを変更するのが望ましく、影響を受け
るすべてのキャッシュエントリに対してパスを一度に再計算するのは望ましくな
い。このことは、特に、＜sender address,destination characteristics＞コン
ビネーションに対する付加的なパケットがまったく到着しないことがあり得るた
め、キャッシュエントリのうちのいくつかは再び使用されることがないという理
由からも言えることである。指標ルータは、どのキャッシュエントリが単に時間
切れになるのを待っていて、どのキャッシュエントリがアクティブに使用されて
いるかを知らないので、指標ルータは、単に、ＲＥＣＡＬＣＵＬＡＴＥ＿ＥＮＴ
ＲＹ＿ＦＬＡＧをセットすることによって、影響を受けるすべてのキャッシュエ
ントリをマークするだけである。影響を受けるキャッシュエントリは、入ってく
るルーティングプロトコルメッセージによって情報が変更されるルーティングテ
ーブルエントリから自らへのポインタを追うことで発見される。キャッシュエン
トリの RECALCULATE＿ENTRY＿FLAG をセットすることによって、指標ルータは、
＜sender address,destination characteristics＞コンビネーションに対する新
たなパケットが到着したときには、キャッシュ情報を再構成しなければならない
ことを示す。このようなパケットがまったく到着しない場合は、キャッシュエン
トリは通常通り時間切れとなり、削除される。しかし、新たなパケットが到着す
る場合は、この新たなパケットによりルーティングキャッシュエントリ情報の再
計算がトリガされるだけでなく、この新たなパケットにしたがって、指標ルータ
が＜sender address,destination characteristics＞コンビネーションに対する
新たなトレールブレージングパケットを発する。このようにして、格納されてい
た元々の指標宛先の指標情報を新たなトレールブレージングパケットに対して使
用することができる。この新たなトレールブレージングパケットは、すべてのダ
ウンストリームルータにもそれらのキャッシュエントリを再計算させる。これは
、たとえこれらのダウンストリームルータが、ネットワークトポロジーの変化を
示すいかなるルーティングプロトコルメッセージを受け取っていなくても行われ
る。新たなトレールブレージングパケットが送信された後、指標パケットはその
直後に送信される。特定の実施形態によれば、このスキームはキャッシュエント
リの再計算を時間軸上に効率よく拡散し、指標ルータをより安定させる。
【０１１２】 第１のトレールブレージングパケットが決して到着しない場合、または（トレ
ールブレージングパケットはネットワークの渋滞またはエラーのせいでルートの
途中でドロップしてしまうことがあるため）キャッシュエントリが、他の指標パ
ケットが指標ルータに到着する直前に時間切れになる場合、ルーティングツリー
は偶発的に忘れられ、再構成の必要が生じる。図１８は、指標ルータのキャッシ
ュの偶発的な失効が、如何にしてダウンストリームツリーを残りのルーティング
ツリーから効率的に切り離すことができるかを示す図の一例である。図１８には
、元々指標ルータ６０１から送られてきた（指標ルータ６０７，６０９および６
１１によって満たされた宛先指標に対する）トレールブレージングパケットによ
って形成されたであろうルーティングツリーまたは以前に形成されたルーティン
グツリーによる、指標ルータ（奇数の参照番号６０１〜６２１により識別される
）のインターネットワークが示されている。このルーティングツリー（矢印によ
り表示）は、ルータ６０９および６１１へのリーフを有するルータ６０１，６０
３，６０５，６０７を有している。第１のトレールブレージングパケットが決し
て指標ルータ６０３に到着しないか、またはキャッシュエントリが、他の指標パ
ケットが指標ルータ６０３に到着する直前に時間切れになる場合、ダウンストリ
ームのルーティングツリーは残りのルーティングツリーから（“Ｘ”によって示
されているように）切り離される。両方のケースにおいて、大域的に一意な識別
子しか持たない非トレールブレージング指標パケットが指標ルータ６０３に到達
する。
【０１１３】 本発明によるシステムはこの潜在的問題に対処することができる。図１９およ
び２０は、本発明が如何にして指標ルータの偶発的な失効という潜在的問題に対
処するかを示す図の例である。図１９および２０には、図１８と同じ指標ルータ
のインターネットワークが示されており、また図１８で論じられているのと同じ
ルーティングツリーを扱っている。図１９から分かるように、大域的に一意な識
別しか持たない非トレールブレージング指標パケット（矢印６３により表示）が
指標ルータ６０３に達する。大域的に一意な識別しか持たないこの非トレールブ
レージング指標パケットの受信に応答して、指標ルータは、本発明のある特定の
実施形態にしたがって、CHARCAST＿ORIGINAL＿CHARACTERISTICS＿REQUEST フラ
グがセットされたメッセージをアップストリームに送る。したがって、指標ルー
タ６０３は、アップストリームの指標ルータ６０１へのリクエストとして作用す
るメッセージを、元々の指標情報を有していない指標ルータ６０１にアップスト
リーム（矢印６３３により表示）で送り、先の指標情報をCHARCAST＿ORIGINAL＿
CHARACTERISTICS フラグがセットされたトレールブレージングパケット内におい
てダウンストリームに送る。（図１９の例では直面している問題に対する１−ホ
ップ解決手段しか示されていないが、元々の指標情報をリクエストするためアッ
プストリームに送られるメッセージは、ツリーがこの情報を必要としている限り
上まで伝わる。）そして、図２０から分かるように、指標ルータ６０１は、CHAR
CAST＿ORIGINAL＿CHARACTERISTICS フラグがセットされたトレールブレージング
パケットを指標ルータ６０３に送る（矢印６３５により表示）ことによって応答
する。このフラグがセットされたトレールブレージングパケットの到着の際、新
たなキャッシュエントリが指標ルータ６０３のフォワーディングキャッシュ内に
作成され、トレールブレージングパケットはダウンストリームに転送される。そ
の結果、ダウンストリームルーティングサブツリー（指標ルータ６０３から６０
５と６０７とを介して６０９および６１１の両方への矢印により形成）が形成さ
れ、このようにして所望のルーティングツリー（図２０において、矢印６３５を
除いたすべての矢印により表示）が形成される。
【０１１４】 特定の実施形態によれば、指標ルータは、ＣｈａｒＯＳＰＦ，ＣｈａｒＲＩＰ
またはＣｈａｒＢＰのような拡張されたプロトコルを使用してネットワークトポ
ロジーを知り、ネットワーク内の各々の宛先に対する指標に基づいて自動的にル
ーティングテーブルを構成する。また、この実施形態によれば、指標ルータは指
標ルーティングテーブルインデックスを用いてフォワーディングキャッシュエン
トリを作成し、指標パケットに対する宛先の集合を決定する。上述のように、キ
ャッシュエントリは、指標ルータが特定の＜sender,destination characteristi
cs＞コンビネーションに対する指標パケットを初めて見たときに作成される。本
発明の実施形態にしたがってＣｈａｒＯＳＰＦ，ＣｈａｒＲＩＰおよびＣｈａｒ
ＢＰを使用した指標ルータによるキャッシュエントリの作成は、以下に述べるよ
うに僅かに変更してもよい。
【０１１５】 ＣｈａｒＯＳＰＦを使用した場合、特定の＜sender,destination characteris
tics＞コンビネーションに対する第１の指標パケットの到着の際に、指標ルータ
がＳＰＦ計算を実行し、この＜sender,destination characteristics＞コンビネ
ーションに対するネットワーク中で最短パスのルーティングツリーが決定される
。ＳＰＦ計算の実行の際、ＣｈａｒＯＳＰＦだけが考慮され、プリセットされた
タイブレーカは、すべてのルータが正確に同じルーティングツリーを形成するよ
うに使用される。このルーティングツリーは送信側に根を持ち、宛先の集合をリ
ーフとして持つ。指標ルータは、このルーティングツリーから、指標パケットの
コピーが送られるべき次ホップの近隣ルータの集合を抽出する。ルーティングツ
リーインデックスから得られた宛先情報だけが使用され、ＳＰＦ計算が実行され
なければ、ルーティングツリーは、単純にコントロールメッセージのオーバーヘ
ッドを被るクロスブランチを含むことになる。というのも、これらのクロスブラ
ンチは剪定されなければならないからである。しかしながら、これらのクロスブ
ランチは除去することが可能であり、それらの剪定は、ＣｈａｒＯＳＰＦを使用
したこの特定の有利な実施形態にしたがってＳＰＦ計算を実行することにより省
くことができ、結果として最適なルーティングツリーが得られる。
【０１１６】 ＣｈａｒＲＩＰを使用した場合、特定の＜sender,destination characteristi
cs＞コンビネーションに対する第１の指標パケットの到着の際に、指標ルータは
指標ルーティングテーブルインデックスを使用して、指標バケットに対する宛先
の集合を決定する。指標ルータは、この宛先の集合から、指標パケットのコピー
が送られるべき次ホップの近隣ルータの集合を決定する。この実施形態では、剪
定する必要のあるクロスブランチが生じることに注意されたい。
【０１１７】 ＣＨａｒＢＰ、すなわちブロードキャスト−プルーンプロトコルを使用した場
合、指標ルータは周期的に近隣ルータに既知のソースのリストと各ソースへのル
ータの（ルータホップにおける）距離をブロードキャスト通信する。はじめに、
ネットワーク内のすべてのサブネットを含むルーティングツリーが形成される。
特定の＜sender,destination characteristics＞コンビネーションに対する第１
の指標パケットの到着の際に、この第１のパケットはこの最初のルーティングツ
リー上ですべてのサブネットにブロードキャスト通信される。フォワーディング
ループが生じるのを防ぐため、パケットが近隣ルータから最短パスでソースに戻
ってきた場合には、指標パケットは指標ルータによって転送される。指標ルータ
は、最短ソース距離に関する自身の格納された知識を用いて、この転送を決定す
る。指標パケットコピーのうちの１つがリーフルーティングノードに達すると、
指標ルータノードは、指標パケットの宛先指標エリアが付随するネットワークの
指標エリアと交差しているかどうかを判定する。交差していない場合は、指標ル
ータノードは、指標ルータノードをルーティングツリーノードから剪定すべきで
あることをアップストリームの近隣の指標ルータに応答する。このアップストリ
ームの近隣の指標ルータが、パケットの宛先指標と交差する付随のネットワーク
を有していない場合、および自身のダウンストリームのすべての近隣指標ルータ
もまたパケットの宛先指標と交差する付随のネットワークを有していないことを
プルーンメッセージの送信により示している場合、このアップストリームの指標
ルータも自身のアップストリームの近隣の指標ルータにプルーンメッセージを送
信する。これは、この特定の実施形態では、最初のルーティングツリーが、指標
のリーチが指標パケットの宛先指標と交差するようなサブネットへのパスだけを
含む最適なルーティングツリーに剪定されるまで、繰り返し生じる。
【０１１８】 III． 階層（ハイアラーキ）的指標ルーティングの実施形態 ルーティングテーブルのサイズを低減し、ノードの指標の変化により影響を受
けるネットワークエリアを最小化することが望ましいような幾つかの特定の実施
形態では、階層的指標ルーティング技術を使用してもよい。このような特定の実
施形態を以下においてより詳細に説明する。
【０１１９】 Ａ． 一般の場合 ルーティングテーブルのサイズを縮小するために、近隣ネットワークおよびホ
ストの集まりを単一の総体にグループ化することができる。このようなグループ
は、それに含まれているネットワークのうちのいずれかに対してインタフェース
を有するルータと共に、エリアと呼ばれる。各エリアは内部では基本指標ルーテ
ィングアルゴリズムの別個のコピーを実行する。外面的には、各エリアはネット
ワーク上の単一ノードのように見える。階層は複数のレベルから構成できること
に注意されたい。
【０１２０】 エリアのトポロジーはエリアの外部からは見えないが、エリア内のすべてのネ
ットワークの指標のサマリーはエリアに広告される。逆に、所定のエリアの内部
のルータがこのエリアの外部の詳細なトポロジーに関して何も知らないのと同様
に、これらのルータは外部エリアのサマリーを有している。この特定の実施形態
によれば、この知識の分離によって、指標ルーティングプロトコルは、ネットワ
ーク全体を単一のルーティングドメインとして扱う場合と比べて格段にルーティ
ングトラフィックを低減することができるようになる。
【０１２１】 エリア外部の指標宛先へのルーティングを可能にするため、エリアボーダール
ータは付加的な指標ルーティング情報をエリア内に注入する。各々のボーダール
ータは、他のエリアボーダールータへの送信ために、各自の付随エリアの指標の
リストを集約する。
【０１２２】 １つのエリアに対する指標の全リストのサマリーを作成するために、このエリ
ア内のすべてのネットワークに対するネットワーク指標宛先の論理和（ＯＲ）が
とられる。この特定の実施形態によれば、各々のネットワーク指標宛先は、以下
においてより詳細に論じられるように、ブルームフィルタとして格納される。論
理ＯＲ操作から生じるビットベクトルは、エリア内のすべての指標を正確に識別
するブルームフィルタである。他のボーダールータに広告されるのは、この新た
なサマリーフィルタである。
【０１２３】 このとき、ボーダールータは、他の各々のボーダールータからのエリアサマリ
ーを有している。この情報から、ボーダールータはすべてのエリア間宛先へのパ
スを計算する。そして、ルータはこれらのパスを自身の付随エリアに広告する。
これによって、エリア内部のルータは、トラフィックをエリア間宛先に転送する
際に、最良のイグジットボーダールータを選ぶことができる。階層が複数のレベ
ルから構成されている場合、各レベルは正確に同じように扱われる。
【０１２４】 「指標の集合の近似」と題されたセクションで説明したように、ネットワーク
が指標の「開」集合を使用している場合、指標の個数がシステムに負担をかける
ほど大きくなるか、少なくとも結果として生じるパケットヘッダが過度に大きく
なる可能性がある。したがって、幾つかの特定の実施形態では、さまざまな圧縮
技術を用いた近似によって、システムが指標ルーティングに使用する指標の個数
を減らすことが有効である。例えば、大きなストリングの場合、Ｌｅｍｐｅｌ−
Ｚｉｖまたはブルームフィルタのような圧縮技術（もちろん、他の実施形態では
他の圧縮技術も可能である）は、サブストリングの小さな集合を生成することに
よってスペースの余裕をとる。なお、元のストリングはこのサブストリングの集
合によって再形成することができる。そして、サブストリングおよびサブストリ
ングの使用法のインストラクションは、元のストリングを再形成するために格納
される。指標ルーティングの目的で、サブストリングは指標の元々の集合の近似
として使用することができる。送信側およびルータはこの近似技術を使用する。
パケットストリーム内の第１パケットはまだ指標宛先の元のリストを送らねばな
いので、終点はこれらのパケットが実際にこれらの終点に向けられたものなのか
否かを判定することができる。圧縮技術が、ストリングの個数を指標の元々の個
数からより少ないサブストリングの個数に減らすので、これらの実施形態におけ
る指標ルータは、より少ない比較動作をするだけでよく、したがってより迅速に
ルーティングを行うことができる。また、ルーティングテーブルも格段に小さく
なる。
【０１２５】 特定性の欠如のため、これらの実施形態における指標パケットは、これらのパ
ケットを最初に受け取るべきではなかったノードに転送されることがあり、結果
として生じるルーティングツリーは、剪定されるべき余分な誤ったブランチを含
むことになる。指標ルータが、どのダウンストリームルータもメッセージの実行
可能な宛先ではないこと、およびこの指標ルータ自体も指標メッセージの宛先で
はないことを検出した場合、この指標ルータは、指標メッセージのソースに向け
てアップストリームで「プルーン」メッセージを送信する。指標ルータは、特定
の指標メッセージに対するプルーンメッセージを受け取ると、その指標メッセー
ジに対するルーティングキャッシュエントリ（存在するならば）からダウンスト
リームルータを除去する。これによってダウンストリームルータの個数がゼロま
で落ちた場合には、指標ルータ自体がプルーンメッセージをアップストリームに
送信する。
【０１２６】 ブルームフィルタを用いた指標の近似集合を使用する特定の実施形態を以下に
おいて例として説明する。
【０１２７】 Ｂ． ブルームフィルタによる符号化指標 この特定の実施形態によるシステムのメモリ要求を低減するため、各々のネッ
トワーク指標宛先はブルームフィルタとして格納される。この実施形態によれば
、計算効率の良い、ハッシュベースの確率的スキームが得られる。この確率的ス
キームは、鍵の集合を最小メモリ要求を有する任意のストリングの形態で表すこ
とができ、同時にメンバーシップの問合せに対して、否定誤認についてはゼロの
確率で、肯定誤認については低い確率で応答する。
【０１２８】 ブルームフィルタは、メンバーシップ問合せをサポートするｎ個の要素（鍵と
も呼ばれる）の集合Ａ＝｛ａ１，ａ２，…，ａｎ｝を表す方法である。ブルーム
フィルタ（Burton Bloom による“Space/Time Trade−offs in Hash Coding Wit
h Allowable Errors,”Communications of ACM, Vol.13, No.7, pp. 422−426,
１９７０年７月において詳述されている）は過去においてスペルチェッカやウェ
ブページキャッシュに使用されてきた。
【０１２９】 ブルームフィルタの背後にある思想は、最初はすべて０にセットされているｍ
ビットのベクトルｖを割当て、つぎにｋ個の独立したハッシュ関数ｈ１，ｈ２，
…，ｈｋを選択することである。なお、各々のハッシュ関数は｛１，…，ｍ｝の
レンジを有している。各要素ａ∈Ａに対して、ｖの中での位置ｈ１（ａ），ｈ２ （ａ），…，ｈｋ（ａ）におけるビットは１にセットされる。（特定のビットは
複数回１にセットされることがある。）ｂに関する問合せの場合、位置ｈ１（ｂ
），ｈ２（ｂ），…，ｈｋ（ｂ）におけるビットがチェックされる。これらのビ
ットのいずれかが０であれば、確実にｂは集合Ａの中にはない。その他の場合、
ｂはこの集合内にあると予想される。しかし、この予想が正しくない（「肯定誤
認」と呼ばれる）確率もいくらかある。パラメータｋおよびｍは、肯定誤認（し
たがって誤ったヒット）の確率が受容可能であるように選ばれるべきである。
【０１３０】
【外１】
【０１３１】 数式１の右辺は、ｋ＝ｌｎ２×ｍ／ｎのとき最小であり、この場合、１／２ｋ ＝（０．６１８５）ｍ／ｎになる。したがって、最適のｋの下で、肯定誤認の確
率はｍが増大するにつれて指数関数的に低減する。実用においては、ｋは整数で
なければならず、計算のオーバーヘッドを減らすために最適値未満の値を選択し
てもよい。
【０１３２】 肯定誤認の確率は比α＝ｍ／ｎであり、この比は各エントリに割当てられたビ
ット数の関数である。例えば、エントリの個数の１０倍より大のビットアレイに
対しては、肯定誤認の確率は、４つのハッシュ関数の場合は１．２％であり、５
つのハッシュ関数の最適の場合では０．９％である。幾つかの特定の実施形態に
よれば、より多くのメモリを割当てることで容易に肯定誤認の確率を低下させる
ことができる。したがって、有利な特定の実施形態では、ハッシュ関数の個数ｋ
はおよそ３と６の間であり、有利にはせいぜい４である。計算オーバーヘッドの
増大に伴うより一層の確度のためには、幾つかの特定の実施形態ではｋは４また
はそれより大であるべきである。
【０１３３】 ブルームフィルタの幾つかの有用な性質は以下の通りである。
【０１３４】 ・Bad Spots−基礎となるメモリハードウェアがエラーを検出し、いずれかのブ
ロック内のエラーを報告すると、そのデータブロックは複数の１で置き換えられ
、誤ったヒットの頻度が僅かながら減る。否定誤認は付加されない。
【０１３５】 ・Non Power of Two−ストリング長が２のべきでないビットストリングが必要な
場合は、ストリング長は大きい方の次の２のべきであるが、付加ビットはすべて
１であるような仮想のビットストリングが生成されるが、実際には格納されない
。つまり、ビットインデックスがストリング長の範囲内に入らない場合はつねに
、１が見られているようなものであり、このロケーションへの書き込みは無視さ
れる。
【０１３６】 ・OR−ing together of filters−異なる場所または異なる時点に形成された異
なるフィルタの論理和をとり、先行するフィルタのいずれかによって認識された
どのグロブも認識するフィルタを生成することができる。複数の論理和フィルタ
によって高密度が生じるが、関与するフィルタの密度を低減することによってこ
れを改善してもよい。
【０１３７】 ・Filter shrinking−フィルタが当初の計画よりも少数のグロブを受け取った場
合、フィルタのサイズを論理和によって左半分と右半分とに２分してもよい。後
続のフィルタプローブは単にビットオフセットのハイビットをマスクオフするだ
けである。これは統合してもよい。
【０１３８】 特定の実施形態によれば、各々のネットワーク指標宛先はブルームフィルタと
して格納される。この特定の例では、ｋ＝４および各々の指標は、図２１に示さ
れているように、４つのハッシュ関数による各自の結果によって表されている。
各々の指標は４つの３２ビット整数として符号化され、ハッシュ関数による各結
果はこの特定の実施形態では３２ビット整数である。指標宛先は指標のリストの
形態をとる。ブルームフィルタの性質のため、“ＲＡＮＧＥ”および“ＳＩＭＩ
ＬＡＲ”（既に論じた）のような操作は、ブルームフィルタを用いたこれらの実
施形態では機能しない。実際、コマンド“ＡＮＤ”および“ＯＲ”だけがこれら
の実施形態では使用される。指標メッセージ内に如何なる操作も与えられていな
い場合は、ＡＮＤコマンドが含意されていることに注意されたい。使用プロファ
イルも、ほとんどの宛先が論理積または論理和をとられた指標の単純ななリスト
を利用していることを示している。したがって、単純化されたＡＮＤおよびＯＲ
リストを使用してもよい。
【０１３９】 図２２では、階層的指標ルーティングの特定の実施形態による、指標リスト７
０１（この実施例では、２つのリスト要素を有するＡＮＤリスト）の符号化が図
解されている。この実施例によれば、各々の単純リスト符号化はこの順序で以下
の情報を有する。すなわち、タイプフィールド７０３、要素数フィールド７０５
，サイズフィールド７０７、ならびに符号化されたリスト要素７０９および７１
１。この実施例では、タイプフィールド７０３は、ＡＮＤリストを表す０ｘ０４
にセットされた１バイトフィールドであり、ＯＲリストを表す０ｘ０８にセット
されることもある。要素数フィールド７０５は、このリスト内の要素の個数にセ
ットされた１バイトフィールドである（このフィールド７０５は８ビットフィー
ルドであるので、このリストは２５６個の要素に制限されている。しかし、異な
るビットサイズのフィールド７０５であれば、所望されているのとは別の要素限
界を有することもできる）。サイズフィールド７０７は、リストのサイズをバイ
トで表す２バイトフィールドである（このサイズは、タイプフィールド７０３、
要素数フィールド７０５，サイズフィールド７０７、ならびに要素７０７および
７１１自体を含むリストの全体的サイズを含む）。そして各リスト要素の符号化
。この実施例での全体的サイズは６４キロバイトに制限されているが、他の例で
はサイズに対する他の限界も可能である。前述したように、特定の実施形態によ
れば、各々のリスト要素は符号化された指標であり、各々の指標は４つのハッシ
ュ関数による各自の結果により符号化である。
【０１４０】 例えばブルームフィルタを介した、指標宛先に対する指標の集合の近似を用い
ることで、指標のいずれかの集合を表すビットベクトルのサイズに対する限界が
設けられることに注意されたい。指標のいずれかの集合を表すビットベクトルの
サイズを明確な所定のサイズに制限することにより、送信され処理されるパケッ
トの個数が減る。したがって、ルータメモリ要求および計算オーバーヘッドが最
小化され、同時に処理速度は有利には最大化される。
【０１４１】 Ｃ． ネットワークセグメントに関する指標の収集 各ルータが、指標の全リストを表すローカルブルームフィルタを維持している
ため、指標の集合（集合Ａと呼ぼう）に対する変更がサポートされなけらばなら
ない。特定の実施形態によれば、これはビットアレイ内の各ロケーションｌに対
してビットが１にセットされた回数（つまり、いずれかのハッシュ関数の下でｌ
にハッシュされた要素の個数）のカウントｃ（ｌ）を維持することにより行われ
る。すべてのカウントは最初は０である。鍵ａ（我々のケースでは指標）が挿入
または削除されると、カウントｃ（ｈ１（ａ）），ｃ（ｈ２（ａ）），…，ｃ（
ｈｋ（ａ））は相応に増分または減分される（ここで、ｈ１（ａ），ｈ２（ａ）
，…，ｈｋ（ａ）はｋ個のハッシュ関数を実行した結果を表している）。カウン
トが０から１へ変化すると、対応するビットがターンオンする。カウントが１か
ら０へ変化すると、対応するビットがターンオフする。したがって、ローカルブ
ルームフィルタはつねに指標の全リストを正確に反映する。
【０１４２】 Ｄ． ルーティングテーブル情報の交換 ルータは、ブルームフィルタのビットアレイ全体、ビットアレイの変化をブロ
ードキャスト通信するか、または他のルータにそれからアップデートをフェッチ
させる。周期的に、完全なアップデートを送信すべきである。正確な方法は、使
用されている基礎となるルーティングプロトコルによって決まる。８〜１６のロ
ードファクタは良く機能するが、ルータは自身のメモリとネットワークトラフィ
ック関連問題に応じてロードファクタを上げたり下げたりすることができる。特
定の実施形態では、ロードファクタに基づいて、４つまたはそれより多くのハッ
シュ関数を使用すべきである。
【０１４３】 ハッシュ関数は、まず、１２８ビットを生成する、指標のＭＤ５符号の計算を
行い、つぎにそれから３２ビットの４つのグループを取ることによって形成され
る。ＭＤ５（ A. J. Menzes 他による、Handbook of Applied Cryptography,CRC
Press, １９９７に記載されている）は、任意の長さのストリングを１２８ビッ
トにハッシュする暗号メッセージ解読アルゴリズムである。特定の実施形態によ
れば、ＭＤ５は、その周知の性質および比較的高速の実行の故に選択される。他
の比較アルゴリズムを用いた他の実施形態も可能である。すべてのルータが同じ
ハッシュ関数を使用することに注意されたい。
【０１４４】 ブルームフィルタの利点は、メモリ要求と肯定誤認率（これは誤ったヒットを
誘発する）との間のトレードオフをもたらすことにある。ルータにとっては、こ
れは帯域（転送される余分なパケットおよび余分な受信側の形態での）とコント
ロールオーバーヘッド（メモリ要求、およびルータ間のコントロールパケットの
サイズの形態での）との間のトレードオフと解釈される。したがって、ルータは
、サマリーにより少ないメモリを当てたい場合、ルータ間トラフィックを僅かに
増大させることでこれを行う。
【０１４５】 IV． 結論 以上の説明では特定の実施形態が説明されているが、本発明は説明された実施
形態に必ずしも限定されるものではないことが理解される。説明された実施形態
の変形または修正が、本発明の範囲を逸脱することなく可能である。本発明の範
囲は、提出された請求項によってのみ限定されるべきものである。
【図面の簡単な説明】
【図１】 従来技術の、マルチキャストを使用して、ネームＡ，ＢおよびＣの組み合わせ
を有しているネットワークノードにメッセージを送信する様子の略図である。
【図２】 本発明の実施形態に従った、キャラクタリスティックルーティングを使用して
、指標Ａ，ＢおよびＣの組み合わせを有しているネットワークノードにメッセー
ジを送信する様子の略図である。
【図３】 本発明の有利な実施例に従った、キャラクタリスティックルーティングシステ
ムの略図である。
【図４】 本発明の実施形態に従った、キャラクタリスティックルーティングノードの一
般化された機能ダイヤグラムの略図である。
【図５】 本発明の実施形態に従った、近似的なキャラクタリスティックルーティングを
使用して、指標Ａ，ＢおよびＣの組み合わせを有しているネットワークノードに
メッセージを送信し、かつ余分なルーティング・ツリー・ブランチをプルーニン
グする様子の略図である。
【図６】 従来技術に従った、種々様々なインターネットワークプロトコルのネットワー
クスタックロケーションの略図である。
【図７】 実施形態に従った、キャラクタリスティックパケットの地球規模でユニークな
識別子のフォーマットの略図である。
【図８】 実施形態に従った、キャルキャスト・パケットのキャラクタリスティック・デ
スティネーションを作っている２つの要素（指標）を含んでいるキャラクタリス
ティックデスティネーション（または指標のリスト）のフォーマットの略図であ
る。
【図９】 実施形態に従った、キャラクタリスティックＯＰオプションに対するオプショ
ン・タイプ・フィールド・セットの略図である。
【図１０】 実施形態に従った、キャラクタリスティックルーティング・オプション拡張を
備えたＩＰヘッダの略図である。
【図１１】 別の実施形態に従った、ＩＰヘッダ後すぐにキャラクタリスティックヘッダを
使用するキャラクタリスティックルーティングパケットの例の略図である。
【図１２】 本発明の種々の実施形態に従った、既存のネットワークトポロジーコンフィギ
ュレーションプロトコルに対すりキャラクタリスティック拡張ＣｈａｒＯＳＰＦ
，ＣｈａｒＲＩＰおよびＣｈａｒＢＰのネットワークスタックロケーションの略
図である。
【図１３】 実施形態に従った、ＣｈａｒＯＳＰＦオプションフィールドの略図である。
【図１４】 実施形態に従った、ＣｈａｒＯＳＰＦに使用されるキャラクタリスティック・
エリア・ＬＳＡパケットの例の略図である。
【図１５】 別の実施形態に従った、ＣｈａｒＲＩＰパケットの例の略図である。
【図１６】 別の実施形態に従った、ＣｈａｒＢＰパケットの例の略図である。
【図１７】 実施形態に従った、キャラクタリスティック・ルータのキャッシュにおけるキャ
ッシュ・エントリとキャラクタリスティック・ルータのルーティングテーブルエ
ントリとの間のポインタリンクを示している実施例の略図である。
【図１８】 キャラクタリスティック・ルータのキャッシュが意図せず満杯になった場合に
、ルーティングツリーの残りからダウンストリームツリーをどのように効率よく
再リンクすることができるかを説明している実施例の略図である。
【図１９】 実施形態に従った、キャラクタリスティック・ルータのキャッシュが意図せず
満杯になった場合に生じる潜在的な問題を本発明がどのように対処するかを説明
している実施例の略図である。
【図２０】 実施形態に従った、キャラクタリスティック・ルータのキャッシュが意図せず
満杯になった場合に生じる潜在的な問題を本発明がどのように対処するかを説明
している実施例の略図である。
【図２１】 ハイアラーキ式のキャラクタリスティックルーティングのための実施形態に従
った、指標が４つのハッシュ関数結果によっ表されているようにｋ＝４を有して
いるＢｌｏｏｍフィルタとして記憶されているネットワークキャラクタリスティ
ックデスティネーションの略図である。
【図２２】 ハイアラーキ式のキャラクタリスティックルーティングのための実施形態に従
った、キャラクタリスティックリスト７０１（この例は２つのリスト要素を有し
ているＡＮＤリストを示している）の符号化の略図である。
───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ０９／７２８，３８０ (32)優先日 平成12年11月28日(2000．11．28) (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ， ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，Ｊ Ｐ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ， ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，Ｒ Ｏ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ， ＹＵ，ＺＡ，ＺＷ

Claims (76)

    【特許請求の範囲】
  1. 【請求項１】 複数のノードを有するネットワークを介したパケットのルー
    ティング方法において、 前記ネットワークを介して送信側ノードからパケットを受け取るステップが設
    けられており、該パケットは複数の定義された指標をもつ少なくとも１つの宛先
    ノードのためのものであり、前記複数の定義された指標が前記送信側ノードによ
    って決定され、前記パケットには前記複数の定義された指標に関する情報が含ま
    れており、 前記の受け取りステップが、前記複数の定義された指標をもつ少なくとも１つ
    の宛先ノードにおいて行われ、 前記複数の定義された指標は、前記ネットワークにおける複数のノードのアス
    ペクトを表すマルチプルな任意の指標から成る部分集合または全体集合であるこ
    とを特徴とする、 パケットのルーティング方法。
  2. 【請求項２】 マルチプルな任意の指標から成る前記全体集合に基づきネッ
    トワークのトポロジーを発見するステップが設けられており、該ネットワークは
    前記送信側ノードと前記少なくとも１つの宛先ノードと少なくとも１つのルーテ
    ィングノードを結合しており、 各ルーティングノードに対し個々にローカルにネットワーク部分の前記トポロ
    ジーの各ルーティングノードにおいてルーティングテーブルをコンフィグレーシ
    ョンするステップが設けられており、該ルーティングテーブルは、前記ネットワ
    ーク部分における各ノードの前記の個々の指標に基づくエントリを有しており、 該ルーティングテーブルのエントリに基づき前記パケットのコピーを伝送する
    ステップが設けられている、 請求項１記載の方法。
  3. 【請求項３】 前記の発見ステップにおいて、前記ネットワークにおける各
    ノード間の最短経路に関する情報が収集される、請求項２記載の方法。
  4. 【請求項４】 前記の発見ステップは各ルータノードにより実行され、各ル
    ータノードは、マルチプルな任意の指標の全体集合を有するキャラクタリスティ
    ック・アドレス・レゾリューション・プロトコル（characteristic address res
    olution protocol CharARP）クエリーをブロードキャストし、前記ネットワーク
    部分における各ノードは前記キャラクタリスティック・アドレス・レゾリューシ
    ョン・プロトコル・クエリーに応じてそれらの個々の指標を伝送する、請求項２
    記載の方法。
  5. 【請求項５】 前記発見ステップはさらに、前記ネットワーク部分に対しロ
    ーカルなルータノードに指標を明らかにした前記ネットワーク部分における各々
    新たなネットワークノードにより実行される、請求項４記載の方法。
  6. 【請求項６】 前記パケットのヘッダに前記複数の定義された指標に関する
    情報が含まれている、請求項１記載の方法。
  7. 【請求項７】 前記ＩＰアドレスはユニキャストアドレスまたはマルチキャ
    ストアドレスである、請求項１記載の方法。
  8. 【請求項８】 前記エントリの各々は前記マルチプルな任意の指標から成る
    全体集合のビットベクトルであり、前記マルチプルな任意の指標の各々は前記ビ
    ットベクトルにおいてまえもって決められたビットロケーションをもつ、請求項
    ２記載の方法。
  9. 【請求項９】 前記伝送ステップは、前記ルーティングテーブルにおける前
    記エントリのビットベクトルと、前記パケットに含まれている少なくとも１つの
    宛先ノードにおける前記定義された指標のビットベクトルとのＡＮＤ論理演算の
    結果に基づき実行される、請求項８記載の方法。
  10. 【請求項１０】 前記ＡＮＤ論理演算の結果が正確にマッチしていれば、該
    パケットは前記定義された指標のビットベクトルをもつ前記少なくとも１つの宛
    先ノードへ伝送される、請求項９記載の方法。
  11. 【請求項１１】 前記伝送ステップは、前記ルーティングテーブルにおける
    エントリのビットベクトルと前記パケットに含まれている少なくとも１つの宛先
    ノードにおける前記定義された指標のビットベクトルとの間のＯＲ論理演算の結
    果に基づき実行される、請求項８記載の方法。
  12. 【請求項１２】 前記ＡＮＤ論理演算の結果がゼロよりも大きければ前記パ
    ケットは、前記定義された指標のビットベクトルをもつ少なくとも１つの宛先ノ
    ードと、前記定義された指標のいくつかのビットベクトルをもつ少なくとも１つ
    の別のノードへ伝送される、請求項９記載の方法。
  13. 【請求項１３】 前記定義された指標のビットベクトルと前記定義された指
    標のいくつかのビットベクトル間の角度は、前記送信側ノードにより決定され前
    記パケット内に含まれている、請求項１２記載の方法。
  14. 【請求項１４】 前記パケットは、該パケットのペイロード中のまえもって
    決められたロケーションにおける複数の定義された指標に関する情報を有してい
    る、請求項１記載の方法。
  15. 【請求項１５】 前記パケットを前記送信側ノードから送信するステップが
    設けられており、該送信ステップは圧縮技術を利用する、請求項１記載の方法。
  16. 【請求項１６】 前記エントリの各々は前記マルチプルな任意の指標から成
    る全体集合の近似的なビットベクトルであり、前記圧縮技術により前記複数の定
    義された指標に関する情報の近似的なビットベクトルが得られる、請求項１５記
    載の方法。
  17. 【請求項１７】 前記伝送ステップにより不必要なノードへ前記パケットの
    コピーが伝送される可能性があり、該パケットのコピーを伝送した受信ノードか
    ら前記送信側ノードへ上り方向でプルーンメッセージを送信するステップが設け
    られており、該送信は前記の受信ノードと該受信ノードから下り方向のノードの
    両方が前記パケットの無効な宛先であるときに行われる、請求項１６記載の方法
    。
  18. 【請求項１８】 前記伝送ステップは、前記ルーティングテーブルにおける
    エントリのビットベクトルと、前記パケットに含まれている少なくとも１つの宛
    先ノードにおける定義された指標の近似的なビットベクトルとのＡＮＤ論理演算
    に基づき行われる、請求項１６記載の方法。
  19. 【請求項１９】 前記伝送ステップは、前記ルーティングエントリのビット
    ベクトルと、前記パケットに含まれている少なくとも１つの宛先ノードにおける
    定義された指標の近似的なビットベクトルとの間のＯＲ論理演算に基づき行われ
    る、請求項１６記載の方法。
  20. 【請求項２０】 前記ＡＮＤ演算の結果が正確にマッチしていれば、前記パ
    ケットは前記定義された指標の近似的なビットベクトルを有する少なくとも１つ
    の宛先ノードへ伝送される、請求項１６記載の方法。
  21. 【請求項２１】 前記ＡＮＤ論理演算の結果がゼロよりも大きければ、前記
    定義された指標の近似的なビットベクトルをもつ少なくとも１つの宛先ノードと
    、前記近似的なビットベクトルに近いビットベクトルをもつ少なくとも１つの別
    のノードへ、前記パケットが伝送される、請求項１６記載の方法。
  22. 【請求項２２】 マルチプルな任意の指標から成る全体集合のうちまえもっ
    て定義された部分集合をもつ少なくとも１つの宛先ノードへネットワークを介し
    てパケットをルーティングするシステムにおいて、 前記ネットワークに結合された複数のノードが設けられており、該複数のノー
    ドは少なくとも１つのホストノードと少なくとも１つのルーティングノードを有
    しており、 各ホストノードは、マルチプルな任意の指標から成る前記全体集合のうちまえ
    もって定義された部分集合を選択し、該まえもって定義された部分集合をもつす
    べてのホストノード宛のパケットを送信し、該パケットには前記まえもって定義
    された部分集合が含まれており、 各ルーティングノードは、前記ネットワークの発見されたローカルのトポロジ
    ーの記憶されたローカルキャラクタリスティックルーティングテーブルに基づき
    前記パケットのコピーを伝送し、該ルーティングテーブルには、前記ルーティン
    グノードとローカルに結合された各ノードの固有の指標に基づくエントリが含ま
    れていることを特徴とする、 ネットワークを介してパケットをルーティングするシステム。
  23. 【請求項２３】 前記記憶されたローカルキャラクタリスティックルーティ
    ングテーブルには、前記ネットワークにおける各ノード間の最短経路ルートに関
    して収集された情報が含まれている、請求項２２記載のシステム。
  24. 【請求項２４】 前記記憶されたローカルキャラクタリスティックルーティ
    ングテーブルにおけるエントリは、前記マルチプルな任意の全体集合を含むキャ
    ラクタリスティック・アドレス・レゾリューション・プロトコル（characterist
    ic address resolution protocol CharARP）クエリーをブロードキャストする各
    ルーティングノードと、前記キャラクタリスティック・アドレス・レゾリューシ
    ョン・プロトコル・クエリーに応答して固有の指標を伝送する各ホストノードに
    よって得られる、請求項２２記載のシステム。
  25. 【請求項２５】 記憶されたローカルキャラクタリスティックルーティング
    テーブルは、各々新たなノードがその固有の指標をそのローカルルーティングノ
    ードへ伝送するたびに更新される、請求項２４記載のシステム。
  26. 【請求項２６】 前記まえもって定義された部分集合は前記パケットのヘッ
    ダ内に含まれている、請求項２２記載のシステム。
  27. 【請求項２７】 前記パケットにはＩＰアドレスが含まれており、該ＩＰア
    ドレスはユニキャストアドレスまたはマルチキャストアドレスである、請求項２
    ２記載のシステム。
  28. 【請求項２８】 前記エントリの各々は前記マルチプルな任意の指標から成
    る全体集合のビットベクトルであり、前記マルチプルな任意の指標の各々は前記
    ビットベクトルにおいてまえもって定義されたビットロケーションを有する、請
    求項２２記載のシステム。
  29. 【請求項２９】 前記記憶されたローカルキャラクタリスティックルーティ
    ングテーブルにおけるエントリのビットベクトルと、前記少なくとも１つの宛先
    ノードにおけるまえもって定義された部分集合のビットベクトルとの間のＡＮＤ
    論理演算の結果を用いて、前記ルーティングノードにより前記パケットのコピー
    が伝送される、請求項２８記載のシステム。
  30. 【請求項３０】 前記ＡＮＤ論理演算の結果が正確にマッチしていれば、前
    記まえもって定義された部分集合のビットベクトルをもつ少なくとも１つの宛先
    ノードへ前記パケットが伝送される、請求項２８記載のシステム。
  31. 【請求項３１】 前記ＡＮＤ論理演算の結果がゼロよりも大きければ、前記
    まえもって定義された部分集合のビットベクトルをもつ少なくとも１つの宛先ノ
    ードと、前記まえもって定められた部分集合におけるさらに別の部分集合のビッ
    トベクトルをもつ少なくとも１つの別のノードへ前記パケットが伝送される、請
    求項３０記載のシステム。
  32. 【請求項３２】 前記まえもって定義された部分集合のビットベクトルと前
    記まえもって定義された部分集合におけるさらに別の部分集合のビットベクトル
    との間の角度は、前記パケットを送信するホストノードにより決定され、該角度
    も前記パケットに含まれている、請求項３１記載のシステム。
  33. 【請求項３３】 前記記憶されたローカルキャラクタリスティックルーティ
    ングテーブルにおけるエントリのビットベクトルと、前記少なくとも１つの宛先
    ノードにおけるまえもって定義された部分集合のまえもって定義された指標のビ
    ットベクトルとのＯＲ論理演算の結果を用いて、前記ルーティングノードは前記
    パケットのコピーを伝送する、請求項２８記載のシステム。
  34. 【請求項３４】 前記パケットにおけるペイロード内のまえもって決められ
    た位置に、前記まえもって定義された部分集合が含まれている、請求項２２記載
    のシステム。
  35. 【請求項３５】 前記送信において圧縮技術が使用される、請求項２２記載
    のシステム。
  36. 【請求項３６】 前記エントリの各々はマルチプルな任意の指標から成る前
    記全体集合の近似的なビットベクトルであり、前記圧縮技術により前記まえもっ
    て定義された部分集合の近似的なビットベクトルが得られる、請求項３５記載の
    システム。
  37. 【請求項３７】 前記伝送により不必要なノードへ前記パケットのコピーが
    伝送される可能性があり、前記複数のノードは前記パケットを送信するホストノ
    ードへ向かって上り方向でプルーンメッセージを送信し、該送信は前記プルーン
    メッセージを送信するノードと該送信ノードから下り方向のノードの両方が前記
    パケットの無効な宛先であるときには常に行われる、請求項３６記載のシステム
    。
  38. 【請求項３８】 前記記憶されたローカルキャラクタリスティックルーティ
    ングテーブルのエントリにおけるビットベクトルと、前記少なくとも１つの宛先
    ノードにおけるまえもって定義された部分集合の定義された指標の近似的なビッ
    トベクトルとの間のＯＲ論理演算の結果を用いて、前記ルーティングノードは前
    記パケットのコピーを伝送する、請求項３６記載のシステム。
  39. 【請求項３９】 前記記憶されたローカルキャラクタリスティックルーティ
    ングテーブルにおけるエントリのビットベクトルと、前記少なくとも１つのノー
    ドにおけるまえもって定義された部分集合の近似的なビットベクトルとの間のＡ
    ＮＤ論理演算の結果を用いて、前記ルーティングノードは前記パケットのコピー
    を伝送する、請求項３６記載のシステム。
  40. 【請求項４０】 前記ＡＮＤ論理演算の結果が正確にマッチしていれば、前
    記まえもって定義された部分集合のビットベクトルを有する少なくとも１つの宛
    先ノードへ前記パケットが伝送される、請求項３９記載のシステム。
  41. 【請求項４１】 前記ＡＮＤ論理演算の結果がゼロよりも大きければ、前記
    まえもって定義された部分集合の近似的なビットベクトルをもつ少なくとも１つ
    の宛先ノードと、前記まえもって定義された部分集合におけるさらに別の部分集
    合のビットベクトルをもつ少なくとも１つの別のノードへ前記パケットが伝送さ
    れる、請求項３９記載のシステム。
  42. 【請求項４２】 前記まえもって定義された部分集合と前記まえもって定義
    された部分集合におけるさらに別の部分集合の前記近似的なビットベクトル間の
    角度は、前記パケットを送信するホストノードによって決定され、該角度も前記
    パケット内に含まれている、請求項４１記載のシステム。
  43. 【請求項４３】 ルータノードにおいて使用するためのコンピュータプログ
    ラム製品において、 ネットワークの発見されたローカルトポロジーのローカルキャラクタリスティ
    ックルーティングテーブルをコンフィグレーションするための、コンピュータに
    より読み取り可能なコードが設けられており、前記ネットワークはマルチプルな
    任意の指標から成る全体集合をもつことのできるノードを結合し、 前記ローカルキャラクタリスティックルーティングテーブルには、該テーブル
    と結び付けられた前記ルーティングノードとローカルに結合された各ノードの固
    有の指標に基づくエントリが含まれており、 前記コンピュータにより読み取り可能なコードにより、前記パケット内に含ま
    れているマルチプルな任意の指標から成る前記全体集合のうちまえもって定義さ
    れた部分集合に基づきパケットが伝送され、 該コンピュータにより読み取り可能なコードは、コンピュータにより読み取り
    可能な媒体に記憶されていることを特徴とする、 ルータノードにおいて使用するためのコンピュータプログラム製品。
  44. 【請求項４４】 前記コンピュータにより読み取り可能なコードにより前記
    ルーティングノードは、マルチプルな任意の指標から成る前記全体集合を含むキ
    ャラクタリスティック・アドレス・レゾリューション・プロトコル（characteri
    stic address resolution protocol CharARP）クエリーをブロードキャストし、
    受信すると前記キャラクタリスティック・アドレス・レゾリューション・プロト
    コル・クエリーに応答して各ホストノードから個々の指標が伝送される、請求項
    ４３記載のコンピュータプログラム製品。
  45. 【請求項４５】 前記コンピュータにより読み取り可能なコードにより前記
    ルーティングノードは、前記ネットワークに加えられた新たなホストノードから
    伝送された個々の指標を受信する、請求項４４記載のコンピュータプログラム製
    品。
  46. 【請求項４６】 前記コンピュータにより読み取り可能なコードにより、前
    記ルーティングノードは各ノード間の最短経路を取得し、各ノード間の該最短経
    路に関する情報を前記ローカルキャラクタリスティックルーティングテーブルに
    記憶する、請求項４３記載のコンピュータプログラム製品。
  47. 【請求項４７】 前記エントリは各ノードの個々の指標に基づくビットベク
    トルであり、前記パケットを伝送するため前記コンピュータにより読み取り可能
    なコードにより、該パケット内に含まれているマルチプルな任意の指標の全体集
    合のうちまえもって定義された部分集合に基づくビットベクトルが前記エントリ
    と比較される、請求項４３記載のコンピュータプログラム製品。
  48. 【請求項４８】 前記コンピュータにより読み取り可能なコードにより、前
    記まえもって定義された部分集合に基づく前記ビットベクトルと等しくマッチし
    たエントリをもつノードへ前記パケットが伝送される、請求項４７記載のコンピ
    ュータプログラム製品。
  49. 【請求項４９】 前記コンピュータにより読み取り可能なコードにより、前
    記まえもって定義された部分集合に基づく前記ビットベクトルに部分的にマッチ
    したエントリをもつノードへ前記パケットが伝送され、前記の部分的なマッチは
    前記パケットからのベクトルの角度により定義される、請求項４７記載のコンピ
    ュータプログラム製品。
  50. 【請求項５０】 ホストノードにおいて使用するためのコンピュータプログ
    ラム製品において、 マルチプルな任意の指標全体の集合のうち部分集合をパケットに入れるための
    、コンピュータにより読み取り可能なコードが設けられており、マルチプルな任
    意の指標全体の前記集合はネットワーク内のノードの可能な指標を表し、 前記パケットは前記部分集合をもつノードのためのものであり、 前記パケットはネットワークを介して前記部分集合をもつノードへ送信される
    ことを特徴とする、 ホストノードにおいて使用するためのコンピュータプログラム製品。
  51. 【請求項５１】 前記コンピュータにより読み取り可能なコードは前記パケ
    ットのヘッダ内に部分集合を有する、請求項５０記載のコンピュータプログラム
    製品。
  52. 【請求項５２】 前記部分集合は、マルチプルな任意の指標全体の前記集合
    各々に対するビットロケーションをもつビットベクトルを有する、請求項５１記
    載のコンピュータプログラム。
  53. 【請求項５３】 前記コンピュータにより読み取り可能なコードにより前記
    ホストノードは、該ホストノードがネットワークへ加えられると個々の指標を伝
    送する、請求項５０記載のコンピュータプログラム製品。
  54. 【請求項５４】 前記コンピュータにより読み取り可能なコードにより前記
    ホストノードは、マルチプルな任意の指標全体の集合を含むキャラクタリスティ
    ック・アドレス・レゾリューション・プロトコル（CharARP）クエリーを該ホス
    トノードが受け取ると、その個々の指標を伝送する、請求項５０記載のコンピュ
    ータプログラム製品。
  55. 【請求項５５】 前記コンピュータにより読み取り可能なコードにより前記
    ホストノードは、該ホストノードのマルチプルな任意の指標全体の部分集合を含
    むキャラクタリスティック・アドレス・レゾリューション・プロトコル（CharAR
    P）クエリーを該ホストノードが受け取ると、その個々の指標を伝送する、請求
    項５０記載のコンピュータプログラム製品。
  56. 【請求項５６】 前記コンピュータにより読み取り可能なコードは前記パケ
    ット内にＩＰアドレスも有する、請求項５０記載のコンピュータプログラム製品
    。
  57. 【請求項５７】 前記コンフィグレーションステップは拡張ＩＧＰ（intern
    al gateway protocol）を利用して実行される、請求項２記載の方法。
  58. 【請求項５８】 前記拡張ＩＧＰはＣｈａｒＯＳＰＦを有する、請求項５７
    記載の方法。
  59. 【請求項５９】 前記拡張ＩＧＰはＣｈａｒＲＩＰを有する、請求項５７記
    載の方法。
  60. 【請求項６０】 前記コンフィグレーションステップは拡張ディスタンスベ
    クトルプロトコルを利用して実行される、請求項２記載の方法。
  61. 【請求項６１】 前記拡張ディスタンスベクトルプロトコルはＣｈａｒＢＰ
    を有する、請求項６０記載の方法。
  62. 【請求項６２】 前記伝送ステップは "RANGE" オペレーションの結果に基
    づき実行される、請求項８記載の方法。
  63. 【請求項６３】 前記エントリの各々は Bloom フィルタとして記憶される
    、請求項１６記載の方法。
  64. 【請求項６４】 前記 Bloom フィルタは４つのハッシュ関数を有する、請
    求項６３記載の方法。
  65. 【請求項６５】 前記伝送ステップは "RANGE" オペレーションの結果に基
    づき実行される、請求項１６記載の方法。
  66. 【請求項６６】 前記エントリの各々は Bloom フィルタとして記憶される
    、請求項１６記載の方法。
  67. 【請求項６７】 前記 Bloom フィルタは４つのハッシュ関数を有する、請
    求項６６記載の方法。
  68. 【請求項６８】 ネットワークにおける効率的階層型ルーティング方法にお
    いて、 指標的宛先のための指標の集合をビットベクトルとして表すステップと、 該指標の集合を近似して、該指標の集合を表すビットベクトルの全体サイズに
    対する制限を設けるステップと、 近似された指標の集合を利用しネットワークを介してコントロールメッセージ
    を伝送するステップ、 を有することを特徴とする、効率的階層型ルーティング方法。
  69. 【請求項６９】 前記コントロールメッセージは階層型コントロールメッセ
    ージである、請求項６８記載の方法。
  70. 【請求項７０】 前記近似ステップにおいて圧縮技術を使用する、請求項６
    ８記載の方法。
  71. 【請求項７１】 前記圧縮技術は Lempel-Ziv フィルタである、請求項７０
    記載の方法。
  72. 【請求項７２】 前記圧縮技術は Bloom フィルタである、請求項７０記載
    の方法。
  73. 【請求項７３】 前記 Bloom フィルタは４以上のｋ個のハッシュ関数を有
    する、請求項７２記載の方法。
  74. 【請求項７４】 前記 Bloom フィルタは３から６の範囲のｋ個のハッシュ
    関数である、請求項７２記載の方法。
  75. 【請求項７５】 前記 Bloom フィルタは４と等しいｋ個のハッシュ関数を
    有する、請求項７２記載の方法。
  76. 【請求項７６】 前記ｋ個のハッシュ関数は前記指標のＭＤ５シグネーチャ
    の計算により算出される、請求項７２記載の方法。
JP2001541194A 1999-11-30 2000-11-30 キャラクタリスティックルーティング Pending JP2003516035A (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US16842699P 1999-11-30 1999-11-30
US60/168,426 1999-11-30
US21366600P 2000-06-23 2000-06-23
US60/213,666 2000-06-23
US72838000A 2000-11-28 2000-11-28
US09/728,380 2000-11-28
PCT/US2000/032514 WO2001041380A2 (en) 1999-11-30 2000-11-30 Characteristic routing

Publications (1)

Publication Number Publication Date
JP2003516035A true JP2003516035A (ja) 2003-05-07

Family

ID=27389522

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001541194A Pending JP2003516035A (ja) 1999-11-30 2000-11-30 キャラクタリスティックルーティング

Country Status (5)

Country Link
EP (1) EP1236312A2 (ja)
JP (1) JP2003516035A (ja)
AU (1) AU772747B2 (ja)
CA (1) CA2395347A1 (ja)
WO (1) WO2001041380A2 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006526302A (ja) * 2003-05-13 2006-11-16 カイヨン・インコーポレイテッド 有線又は無線ネットワークにおけるパケットのルーティングのためのシステム及び方法
JP2008011448A (ja) * 2006-06-30 2008-01-17 Ntt Docomo Inc アドホックネットワーク、ノード、経路制御方法、及び経路制御プログラム
JP2011223494A (ja) * 2010-04-14 2011-11-04 Fujitsu Ltd 通信装置および通信プログラム
US8209761B2 (en) 2007-04-19 2012-06-26 Oki Electric Industry Co., Ltd. Wireless network system, information providing apparatus and wireless terminal
JP2013102330A (ja) * 2011-11-08 2013-05-23 National Institute Of Information & Communication Technology 情報中心ネットワークにおけるポテンシャルに基づくルーティング方法およびそれを用いたネットワーク
KR20140051770A (ko) * 2012-10-23 2014-05-02 삼성전자주식회사 협력 전송을 수행하는 소스, 릴레이 및 데스티네이션 및 각각의 제어 방법
JP2015181273A (ja) * 2010-02-23 2015-10-15 インテル・コーポレーション ワイドチャンネル無線通信のための装置、方法、及びコンピュータ可読不揮発記憶媒体

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7120120B2 (en) * 2001-11-29 2006-10-10 Ipsum Networks, Inc. Method and system for topology construction and path identification in a two-level routing domain operated according to a simple link state routing protocol
US7330435B2 (en) * 2001-11-29 2008-02-12 Iptivia, Inc. Method and system for topology construction and path identification in a routing domain operated according to a link state routing protocol
DE60311157T2 (de) * 2002-01-24 2007-11-15 Alcatel Canada Inc., Kanata Verfahren und Vorrichtung um redundante Kommunikationsaufgaben zu synchronisieren
US7406035B2 (en) 2002-01-24 2008-07-29 Alcatel-Lucent Canada Inc. Method and apparatus for providing redundant protocol processes in a network element
US8769154B2 (en) 2002-01-24 2014-07-01 Alcatel Lucent Method and apparatus for facilitating routing protocol redundancy in a network element
US8005980B2 (en) 2002-01-24 2011-08-23 Alcatel Lucent Method and apparatus for synchronizing redundant communication tasks
AU2003299435A1 (en) * 2002-12-17 2004-07-09 Girish P. Saraph Routing scheme based on virtual space representation
GB0322491D0 (en) 2003-09-25 2003-10-29 British Telecomm Virtual networks
GB0322494D0 (en) 2003-09-25 2003-10-29 British Telecomm Computer networks
RU2477583C2 (ru) * 2006-11-08 2013-03-10 Нокиа Сименс Нетворкс Гмбх Унд Ко. Кг Поддержка связи в сетях ieee 802.16 с помощью ретрансляций через cid-инкапсуляцию
WO2008151673A1 (en) 2007-06-14 2008-12-18 Telefonaktiebolaget Lm Ericsson (Publ) Routing in a network
CN103200099B (zh) * 2012-01-10 2016-08-24 迈普通信技术股份有限公司 一种mpls中快速查找目标节点的方法及装置
WO2014072374A1 (en) * 2012-11-09 2014-05-15 Siemens Aktiengesellschaft Method for transmitting messages in an industrial communication network of an industrial automation system and communication device for an industrial communication network
US10841222B2 (en) 2016-07-05 2020-11-17 Ologn Technologies Ag Systems, apparatuses and methods for network packet management
US11570098B2 (en) 2016-07-05 2023-01-31 Six Impossible Things Before Breakfast Limited Systems, apparatuses and methods for cooperating routers
EP3923495A1 (en) * 2016-11-11 2021-12-15 OLogN Technologies AG Systems, apparatuses and methods for cooperating routers

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6006264A (en) * 1997-08-01 1999-12-21 Arrowpoint Communications, Inc. Method and system for directing a flow between a client and a server

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006526302A (ja) * 2003-05-13 2006-11-16 カイヨン・インコーポレイテッド 有線又は無線ネットワークにおけるパケットのルーティングのためのシステム及び方法
JP2008011448A (ja) * 2006-06-30 2008-01-17 Ntt Docomo Inc アドホックネットワーク、ノード、経路制御方法、及び経路制御プログラム
US7970933B2 (en) 2006-06-30 2011-06-28 Ntt Docomo, Inc. Ad hoc network, node, routing control method and routing control program
JP4732972B2 (ja) * 2006-06-30 2011-07-27 株式会社エヌ・ティ・ティ・ドコモ アドホックネットワーク、ノード、経路制御方法、及び経路制御プログラム
US8209761B2 (en) 2007-04-19 2012-06-26 Oki Electric Industry Co., Ltd. Wireless network system, information providing apparatus and wireless terminal
JP2015181273A (ja) * 2010-02-23 2015-10-15 インテル・コーポレーション ワイドチャンネル無線通信のための装置、方法、及びコンピュータ可読不揮発記憶媒体
US10129879B2 (en) 2010-02-23 2018-11-13 Intel Corporation Bandwidth and channel notification for wide-channel wireless communication
JP2011223494A (ja) * 2010-04-14 2011-11-04 Fujitsu Ltd 通信装置および通信プログラム
JP2013102330A (ja) * 2011-11-08 2013-05-23 National Institute Of Information & Communication Technology 情報中心ネットワークにおけるポテンシャルに基づくルーティング方法およびそれを用いたネットワーク
KR20140051770A (ko) * 2012-10-23 2014-05-02 삼성전자주식회사 협력 전송을 수행하는 소스, 릴레이 및 데스티네이션 및 각각의 제어 방법
KR102198349B1 (ko) 2012-10-23 2021-01-05 삼성전자주식회사 협력 전송을 수행하는 소스, 릴레이 및 데스티네이션 및 각각의 제어 방법

Also Published As

Publication number Publication date
WO2001041380A2 (en) 2001-06-07
WO2001041380A3 (en) 2001-12-27
EP1236312A2 (en) 2002-09-04
AU1933001A (en) 2001-06-12
AU772747B2 (en) 2004-05-06
CA2395347A1 (en) 2001-06-07

Similar Documents

Publication Publication Date Title
JP2003516035A (ja) キャラクタリスティックルーティング
US20030026268A1 (en) Characteristic routing
US5361256A (en) Inter-domain multicast routing
US8724533B2 (en) Multicast support by mobile routers in a mobile ad hoc network
US6870851B1 (en) Method and system for optimizing routing of data packets
JP5350481B2 (ja) マルチキャストサービス用のモビリティ処理
EP3038327B1 (en) System and method for multi-source multicasting in content-centric networks
US20030185209A1 (en) Scalable IP multicast with efficient forwarding cache
Jain et al. Viro: A scalable, robust and namespace independent virtual id routing for future networks
JPH11243416A (ja) ノード装置及びラベルスイッチングパスのループ検出方法
JP2003209567A (ja) パケット交換システム、パケット交換方法、ルーティング装置、パケットデータ及びその生成方法
CN107623630B (zh) 一种位索引显式复制信息传递方法和装置
Qian et al. ROME: Routing on metropolitan-scale Ethernet
Wu Dominating‐set‐based routing in ad hoc wireless networks
Ballardie et al. Core Based Tree (CBT) Multicast
Moy RFC1584: Multicast Extensions to OSPF
CN113992564B (zh) 报文处理方法及装置
Cisco Configuring Networking Protocols
Cisco Configuring Networking Protocols
Cisco Configuring Networking Protocols
Osipov tinyLUNAR: One-byte multihop communications through hybrid routing in wireless sensor networks
KR100552518B1 (ko) 네트워크 프로세서에서의 ｅｃｍｐ 구현장치
Hong et al. Dynamic group support in LANMAR routing ad hoc networks
Ferdaus et al. Routing: internet routing protocols and algorithms
Ranjitkar et al. IP multicast implementation based on the multicast extensions to OSPF protocol

Legal Events

Date Code Title Description
A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20041027

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20041027