(57)【要約】イーサネットまたはIEEE 802.3技術を使用してアクセスネットワークが構築される。このネットワークは、複数の端末と、集信装置段の階層と、ＤＨＣＰサーバーとからなる。端末が起動すると、その端末のＭＡＣアドレスを含むサーバーへＤＨＣＰ発見メッセージが送られる。これらのアドレスは、それらが受信されるポートに逆らって集信装置にキャッシュされる。従って、未知のＭＡＣアドレスは上流へだけ送られる。クライアントＰＣがＡＲＰを使用して他の何れかのクライアントのＭＡＣアドレスを見出すために任意の時点に同報するメッセージでネットワークが溢れるのを回避するために、中央サーバーはプロキシＡＲＰ機能を提供する。
2004528755.tif 000002
【特許請求の範囲】
【請求項１】
サーバー、集信装置の上流ポートを介して上記サーバーに結合されている少なくとも１つの集信装置、及び上記集信装置の少なくとも１つの下流ポートを介して上記集信装置に結合されている複数の端末を含むアクセスネットワークにおいてデータを経路指定する方法であって、
各端末毎の独自アドレスを上記端末から上記集信装置を介して上記サーバーへ送るステップと、
上記独自端末アドレスを上記集信装置に格納するステップと、
所与の行先端末へ宛てられたフューチャーデータを上記集信装置に格納されているその端末のアドレスに従って経路指定するステップと、
を含み、
もし上記データの行先が下流ポートを介して接続されていれば、上記データをそのポートへ送り、他のポートへは送らないことを特徴とする方法。
【請求項２】
もし上記データが下流ポートを介して受信され、上記データの行先が下流ポートを介して接続されていなければ、上記データを上記上流ポートへ送るステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
もし上記データが上流ポートを介して受信され、上記データの行先が下流ポートを介して接続されていなければ、上記データを破棄するステップを含むことを特徴とする先行請求項の何れかに記載の方法。
【請求項４】
同報データは上流だけへ送られ、決して下流へは送られないことを特徴とする先行請求項の何れかに記載の方法。
【請求項５】
上記独自アドレスを送るステップは、各端末のＭＡＣアドレスを送ることからなることを特徴とする先行請求項の何れかに記載の方法。
【請求項６】
上記サーバーはＤＨＣＰサーバーであり、独自アドレスを上記サーバーへ送るステップはＤＨＣＰ発見メッセージを上記サーバーへ送ることからなり、上記ＤＨＣＰ発見メッセージは上記独自アドレスを含むことを特徴とする先行請求項の何れかに記載の方法。
【請求項７】
上記独自端末アドレスを上記集信装置に格納するステップは、それらを受信する上記集信装置のポートに逆らって上記端末アドレスを格納することからなることを特徴とする先行請求項の何れかに記載の方法。
【請求項８】
上記各端末、上記サーバー、及び上記集信装置は、格納したエントリについてタイムアウト期間を有しており、上記方法は、上記端末アドレスのタイムアウトを上記集信装置の記憶装置または上記サーバーのそれよりも短いタイムアウトにセットするステップを含むことを特徴とする先行請求項の何れかに記載の方法。
【請求項９】
アドレス解決プロトコル（ＡＲＰ）同報メッセージをある端末から上記集信装置へ送るステップと、上記ＡＲＰ同報メッセージを上記サーバーへ経路指定するステップを含むことを特徴とする先行請求項の何れかに記載の方法。
【請求項１０】
上記サーバーは、上記ＡＲＰ要求内に識別されている端末の独自アドレスを上記要求中の端末へ送出することを特徴とする請求項９に記載の方法。
【請求項１１】
上記サーバーは、上記ＡＲＰ要求をユニキャストメッセージとして、上記ＡＲＰ要求内に識別されている端末の独自アドレスへ転送することを特徴とする請求項９に記載の方法。
【請求項１２】
サーバー、集信装置の上流ポートを介して上記サーバーに結合されている少なくとも１つの集信装置、及び上記集信装置の少なくとも１つの下流ポートを介して上記集信装置に結合されている複数の端末を含むアクセスネットワークであって、上記各端末はその端末の独自アドレスを上記集信装置を介して上記サーバーへ送る手段を含み、上記集信装置は上記独自端末アドレスを格納する記憶装置を含み、上記集信装置はデータをそのデータの行先が下流ポートを介して接続されている場合にはそのポートへ送り、他のポートへは送らない手段を含むことを特徴とするアクセスネットワーク。
【請求項１３】
上記集信装置は、下流ポートを介して受信したデータをそのデータの行先が下流ポートを介して接続されていない場合には上記上流ポートへ送る手段を含むことを特徴とする請求項１２に記載のアクセスネットワーク。
【請求項１４】
上記集信装置は、上記上流ポートを介して受信したデータをそのデータの行先が下流ポートを介して接続されていない場合には破棄する手段を含むことを特徴とする請求項１２または１３に記載のアクセスネットワーク。
【請求項１５】
上記集信装置は、同報データを上流へ送り、決して下流へは送らない手段を含むことを特徴とする請求項１２または１３に記載のアクセスネットワーク。
【請求項１６】
上記各端末に位置する上記独自アドレスを送る手段は、その端末のＭＡＣアドレスを送る手段を含むことを特徴とする請求項１２乃至１５に記載のアクセスネットワーク。
【請求項１７】
上記サーバーはＤＨＣＰサーバーであり、上記各端末に位置する独自アドレスを上記ＤＨＣＰサーバーへ送る手段はＤＨＣＰ発見メッセージを上記ＤＨＣＰサーバーへ送る手段を含み、上記ＤＨＣＰ発見メッセージは上記独自アドレスを含むことを特徴とする請求項１２乃至１６に記載のアクセスネットワーク。
【請求項１８】
上記集信装置の記憶装置は、上記独自端末アドレスを、それらを上記端末から受信するポートに逆らって格納することを特徴とする請求項１２乃至１７の何れかに記載のアクセスネットワーク。
【請求項１９】
上記各端末、上記サーバー、及び上記集信装置の記憶装置は、格納したエントリについてタイムアウトを含み、上記端末のタイムアウトは上記サーバーまたは上記集信装置の記憶装置のタイムアウトよりも短い時間にセットされることを特徴とする請求項１２乃至１８の何れかに記載のアクセスネットワーク。
【請求項２０】
上記端末は、ＡＲＰメッセージを上記集信装置を介して上記サーバーへ同報する手段を含むことを特徴とする請求項１２乃至１９の何れかに記載のアクセスネットワーク。
【請求項２１】
上記サーバーは、上記ＡＲＰ要求内に識別されている端末の独自アドレスを上記要求中の端末へ送出する手段を含むことを特徴とする請求項２０に記載のアクセスネットワーク。
【請求項２２】
上記サーバーは、上記ＡＲＰ要求を上記ＡＲＰ要求内に識別されている端末へ経路指定することを特徴とする請求項２０に記載のアクセスネットワーク。
【請求項２３】
上記ネットワークは、イーサネットまたはIEEE 802.3ネットワークであることを特徴とする請求項１２乃至２２の何れかに記載のアクセスネットワーク。
【請求項２４】
上記ネットワークは、上記サーバーと上記端末との間に配列されている複数の集信装置を含み、第１の集信装置は上記サーバーと他の複数の集信装置との間に接続され、上記他の複数の集信装置は上記端末に、または１つまたはそれ以上の上記他の集信装置を介して間接的に上記端末に結合されていることを特徴とする請求項１２乃至２３の何れかに記載のアクセスネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを電気通信（テレコミュニケーション）交換局から顧客構内へ配送するためのアクセスネットワークに関する。
【背景技術】
【０００２】
従来から、電気通信サービスプロバイダには、顧客に音声通信を供給することが要求されてきた。近年になって、ＩＰを通しての音声、ビデオ、インターネットアクセス等のようないろいろなＩＰサービスが利用可能になってきた。そのため、アクセスネットワークをどのように設計するかが再評価されるようになっている。
【０００３】
電気通信会社からサービスを受ける多くのビジネスは、イーサネットまたはIEEE 802.3標準に準拠するコンピュータネットワークを使用している。我々は、これらの標準に準拠するアクセスネットワークを構築することが望ましいことを理解している。
【０００４】
また我々は、このような解決法が、アクセスネットワークとイーサネット／IEEE 802.3ネットワークとの間の特性の差によってもたらされる多くの異なる問題を解消する必要があることも認識している。図１ａ及び１ｂはそれぞれ、典型的なイーサネット／IEEE 802.3ネットワーク及びアクセスネットワークを示している。ビジネス環境において使用される前者は、種々のノード間のネットワークの周囲のトラフィックが極めてランダムに流れるような状況下で動作する。図示の簡単な例では、相互接続されている２つのノード１０、１２が存在しており、各ノードには複数のクライアント１４及びサーバー１６が接続されている。ランダムトラフィックはクライアントとサーバーとの間であり、ネットワーク全体に広がっていよう。図１ｂのアクセスネットワークは複数のサーバー２０を含んでおり、これらのサーバーはヘッドエンド集信装置（コンセントレータ）ノード２２に接続され、このノード２２は別の１対の集信装置ノード２４に接続されている。各ノード２４には複数のクライアント２６が接続されている。ほぼ全てのトラフィックは、クライアントからサービスネットワークへの接続点であるヘッドエンドノードへ、及びその逆へ流れる。
【０００５】
ビジネスネットワーク内のノード間の長さは典型的には短い。その結果、高帯域幅リンクの設置は比較的安価である。これに対してアクセスネットワークではクライアントが地理的に広範な領域に広がっているので、多くのリンクはＤＳＬまたはモデムリンクのような低帯域幅技術を使用している。更に、アクセスネットワークは、典型的にはビジネスネットワークより数倍も大きい。
【０００６】
イーサネット／IEEE 802.3スイッチは、その位置が未知のホストを見出すのに同報の使用に頼っている。これは、ビジネスネットワークより遙かに大きいアクセスネットワークにおいては受け入れ難い。何故ならば、同報トラフィックは帯域幅資源が乏しい環境において、大量の帯域幅を残らず使用してネットワーク内の全ての経路に沿ってむなしく走行するからである。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、上述した諸問題を解消することである。
【課題を解決するための手段】
【０００８】
本発明は、サーバー、上記サーバーに結合されている少なくとも１つの集信装置、及び上記集信装置に結合されている複数の端末を含むアクセスネットワークにおいてデータを経路指定する方法を提供する。本方法は、各端末毎の独自アドレスを上記集信装置を介して上記端末から上記サーバーへ送るステップと、上記独自の端末アドレスを上記集信装置に格納するステップと、所与の端末へ宛てられたフューチャーデータを上記集信装置に格納されているその端末のアドレスへ経路指定するステップとを含む。
【０００９】
本発明はまた、サーバー、上記サーバーに結合されている少なくとも１つの集信装置、及び上記集信装置に結合されている複数の端末を含むアクセスネットワークをも提供する。上記各端末はその端末の独自アドレスを上記集信装置を介して上記サーバーへ送る手段を含み、上記集信装置は上記独自の端末アドレスを格納する記憶装置を含むので、上記集信装置は所与の端末へ宛てられたフューチャーデータを上記記憶装置内に格納されたその端末のアドレスへ経路指定することができる。
【００１０】
本発明の実施例は、端末アドレスを集信装置にキャッシュすることによって、そのような状況は発生しないであろうけれども、行先アドレスが未知である時に全てのポートへフレームを同報する必要がないという長所を有している。これにより、イーサネット／IEEE 802.3技術を使用してアクセスネットワークを構築することが実現可能になる。
【００１１】
好ましくは、サーバーはＤＨＣＰサーバーであり、独自アドレスはＤＨＣＰ発見メッセージの中で送られる端末ＭＡＣアドレスである。
【００１２】
好ましくは、集信装置は、端末アドレスを受信したポートに逆らって、端末アドレスを格納する。
【００１３】
好ましくは、端末のＩＰアドレスは既知であるがＭＡＣアドレスが未知である場合、ＡＲＰ要求をサーバーに送る。サーバーは全てのＭＡＣアドレスを既に知っているので、ＡＲＰ要求自体に答えることも、またはそれを適切な行先へユニキャストとして送ることもできる。これは、ネットワーク全体にＡＲＰ要求を同報することが回避されるという長所を有する（ＡＲＰ要求を同報すると、ネットワークが溢れ、性能が低下する）。
【発明を実施するための最良の形態】
【００１４】
以下に、添付図面を参照して本発明の実施例を説明する。
【００１５】
図２のアクセスネットワーク２５においては、少数のＰＣ  ３０ａ−３０ｆが２つの集信装置３２ａ、３２ｂの１つに接続されている。この例ではＰＣを使用しているが、他のイーサネットデバイスを使用できることを理解されたい。２つの集信装置は、別の集信装置３４に接続されている。この集信装置３４は、ＤＨＣＰ（動的ホスト構成プロトコル）サーバー３６及びルーター３８に接続されている。ルーターは、別のＰＣ４０に接続されているが、これは直接接続しないことができる。ＰＣ  ３０ａ、３０ｂは同一のローカルエリアネットワーク（ＬＡＮ）内にある。
【００１６】
ソースＰＣ（例えば、ＰＣ  ３０ａ）がイーサネットフレームを別のＰＣへ送りたい場合、最も望ましいフレーム経路指定はネットワーク内の行先ＰＣの位置に依存しよう。
【００１７】
同一ＬＡＮ  ４１上にあるＰＣ  ３０ｂと通信するためには、経路指定は、結局はフレームをアクセスネットワークへ送ることなくＬＡＮ上でなされる。これは、図２に矢印４２で示されている。実際には、もしＬＡＮがイーサネットスイッチを使用していれば、フレームをＬＡＮ内に維持することができる。しかしながら、もし代わりに簡単なイーサネットハブが使用されていれば、フレームは集信装置３２ａに現れよう。フレームは、アクセスネットワーク全体に更に伝播させるべきではない。
【００１８】
ソースＰＣ  ３０ａがフレームをＰＣ  ３０ｃへ送りたい場合、理想的なルートは、そのフレームをＰＣ  ３０ｃは接続されている集信装置３２ａ上のポートへ送るが、例えばのポートへは送らないことである。従って、メッセージはユニキャストになる。このルートが矢印４４で示されている。
【００１９】
フレームをソースＰＣ  ３０ａからＰＣ  ３０ｅへ送る場合に最も望ましいルートは、集信装置３２ａを通り、次いで第２の集信装置３４を通り、次いで第３の集信装置３２ｂを通るものであり、第３の集信装置３２ｂがＰＣ  ３０ｅが接続されているポートへ経路指定する。どの集信装置もフレームを他の何れかのポートへ経路指定すべきではない。
【００２０】
最後に、ソースＰＣがフレームをＰＣ  ４０へ送りたい場合、フレームはローカルネットワークを出なければならず、そしてＩＰ伝送プロトコルを使用してそのフレームを第１の集信装置３２ａへ、第２の集信装置３４へ、及び１つまたはそれ以上のルーター３８を介してＰＣ  ４０へ送る。
【００２１】
以上のように、例示した各経路指定シナリオでは、たとえＰＣの行先アドレスが未知であっても、他の全てのＰＣへ同報することは受け入れられない。経路指定環境はユニキャストである。各集信点毎の上流及び下流伝送のためのフレーム伝送規則は、以下のように要約することができる。
【００２２】
上流フレーム
もしフレームの行先ＭＡＣ（メディアアクセス制御）が何れかの集信装置の出力ポートの下流にあることが分かれば、そのフレームがそのポートで受信されたものではない限りそのフレームをそのポートへ送り、他のポートへは送らない。そうでない時には、そのフレームを次の上流集信点へ送る。
【００２３】
下流フレーム
もしフレームの行先ＭＡＣアドレスが何れかの出力ポートの下流にあることが分かれば、そのフレームをそのポートへ送り、他のポートへは送らない。そうでない時には、そのフレームを破棄する。
【００２４】
従来のイーサネットスイッチは、行先が分かっている場合には上流及び下流の両条件に従うことができるが、もしアドレスが未知であれば規則には従わず、それ自体を識別するためにネットワーク同報に頼って行先を尋ねる。この問題は、上流位置のネットワーク上に全てのＰＣの識別の記録を維持することによって解消される。アクセスネットワークにおいては、各集信段は、そのポートの下流のＰＣの全てのＭＡＣアドレスを知っていることが不可欠である。普通のＬＡＮとは異なり、クライアントは、それがそれ自体のことを伝えてしまうまでは話かけられることはできない。
【００２５】
図２の実施例では、ＤＨＣＰサーバー３６へのＤＨＣＰ要求を使用し、端末と集信装置内のアドレスとのアソシエーションを作成することによってこれが達成されている。ＰＣを起動させ、それがブートアップすると、ＰＣはそのＭＡＣアドレスを含むＤＨＣＰ発見メッセージを送る。これらのＭＡＣアドレスは集信装置において受信され、キャッシュされ、ＤＨＣＰサーバーへ送る前にそれらを受信したポートに逆らって格納される。
【００２６】
以上のように、各イーサネット集信装置は、その種々のポート番号の記録と、これらのポートに接続されている各ＰＣのアドレスとを格納しているアドレステーブルを有している。集信装置は、アドレステーブル内のエントリをエージアウトすることが多い。これが問題になることを防ぐために、ＤＨＣＰリースタイムアウトを、集信装置のエージタイムアウトよりも短い時間にセットすることができる。従って、インターネット上で活動的なクライアントは、彼等が彼等のＤＨＣＰリースを更新する時に彼等のＭＡＣアドレスをリフレッシュする。
【００２７】
以下に、もしあるクライアントのＩＰアドレスが既知であれば、どのようにしてそのクライアントのＭＡＣアドレスを決定できるかを説明する。普通は、この状況ではＡＲＰ（アドレス解決プロトコル）メッセージが送られる。このプロトコルは、それ自体を識別するために同報メッセージを使用する。アクセスネットワークにおいては、この挙動は望ましくない。
【００２８】
もしアクセスネットワークにおいて普通のように使用されれば、ＡＲＰを使用しているクライアントＰＣが他の何れかのクライアントのＭＡＣアドレスを見出そうとする場合にも何時でも他の全てのクライアントへ同報メッセージを送るので、ネットワークは同報メッセージで溢れてしまうことになる。これは、アクセスネットワークのような制限された帯域幅のネットワークの性能を低下させる。
【００２９】
この問題は、ＤＨＣＰサーバーまたはヘッドエンド集信装置３４内にＡＲＰプロキシ機能を使用することによって排除することができる。集信装置は、接続されているポートの上流及び下流の両方へ全ての同報メッセージを戻して送るのではなく、上流へ転送する。次いで、全てのクライアントのＭＡＣアドレスのリストを格納しているＡＲＰ機能がクライアントに代わって応答する。
【００３０】
代替として、ＡＲＰプロキシ機能はそのＡＲＰ要求を受信し、意図された受信者のＭＡＣアドレスを探索し、そしてその受信者のＡＲＰ要求を転送する。これは、下流への同報ではなく、ユニキャストである。そこで、クライアントは通常の技法で元の要求者に応答する。この方法は、クライアントのソフトウェアがユニキャストＡＲＰ要求を受け入れる場合に限って動作する。
【００３１】
以上に説明したシステム及び方法においては、同報フレームは上流へのみ送られ、決して下流へは伝送されない。
【００３２】
以上の説明から、この実施例によってイーサネット／IEEE 802.3ネットワークをアクセスネットワーク内に使用できることが理解されたであろう。アクセスネットワークに接続されている多くの顧客がこの型のネットワークを既に使用しているから、これは長所である。
【００３３】
当業者には理解できるように、本発明の範囲から逸脱することなく上述した実施例に種々の変更が可能である。本発明は、特許請求の範囲によって限定されるものである。
【図面の簡単な説明】
【００３４】
【図１ａ】典型的なビジネスネットワーク及びアクセスネットワークの例を示す図である。
【図１ｂ】典型的なビジネスネットワーク及びアクセスネットワークの例を示す図である。
【図２】本発明を実施するアクセスネットワークを示す図である。
【図１ａ】
2004528755.tif 000003
【図１ｂ】
2004528755.tif 000004
【図２】
2004528755.tif 000005
【国際公開パンフレット】
2004528755.tif 000006
2004528755.tif 000007
2004528755.tif 000008
2004528755.tif 000009
2004528755.tif 000010
2004528755.tif 000011
2004528755.tif 000012
2004528755.tif 000013
2004528755.tif 000014
2004528755.tif 000015
2004528755.tif 000016
2004528755.tif 000017
2004528755.tif 000018
2004528755.tif 000019
【国際公開パンフレット（コレクトバージョン）】
2004528755.tif 000020
2004528755.tif 000021
【国際公開パンフレット（コレクトバージョン）】
2004528755.tif 000022
2004528755.tif 000023
【国際調査報告】
2004528755.tif 000024
2004528755.tif 000025