JP3916542B2

JP3916542B2 - アドレス割当システム

Info

Publication number: JP3916542B2
Application number: JP2002293623A
Authority: JP
Inventors: 敦史須川
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2002-10-07
Filing date: 2002-10-07
Publication date: 2007-05-16
Anticipated expiration: 2022-10-07
Also published as: JP2004129126A

Description

【０００１】
【発明の属する技術分野】
本発明はアドレス割当システムに関し、例えば、ＤＨＣＰサーバなどを利用するシステムに適用して好適なものである。
【０００２】
【従来の技術】
ＤＨＣＰサーバは本来、ＭＡＣアドレスを有する端末からIＰアドレスの取得要求がきた時点で、端末に割り当てるIＰアドレスを決定・確保し、その端末のＭＡＣアドレスと、割り当てたＩＰアドレスとを対応付けて管理する
この端末がＶｏＩＰ(Voice ovre IP)用ＴＡ１３である場合、これを含むＶｏＩＰネットワーク中のシステム１０の概略構成は図６に示すものとなり、このシステム１０内のプロビジョニングシステム１１とＤＨＣＰサーバ１５の動作は、図２に示すものとなる。
【０００３】
ＶｏIＰサービスのプロビジョニングでは、図２に示すように、プロビジョニングシステム１１が、ＶｏＩＰ用ＴＡ１３からの要求に応じてＤＨＣＰサーバ１５にＩＰアドレスの取得要求を送信すると（Ｓ１１、Ｓ１）、ＤＨＣＰサーバ１５は、当該取得要求にともなって受信したＭＡＣアドレスを当該取得要求に応じて確保した（割り当てる）ＩＰアドレスに対応付けてアドレス管理テーブルＴＢ１に格納したあと、確保したＩＰアドレスを返送する（Ｓ１２、Ｓ１）。これを受信すると、プロビジョニングシステム１１は、取得したＩＰアドレスと前記ＭＡＣアドレスの対応関係をＶｏＩＰシステム１２に通知する（Ｓ２）。
【０００４】
ＶｏIＰ用ＴＡ１３には、その情報を元にＩＰアドレスが設定される。
【０００５】
このとき取得したＩＰアドレスは、ＤＨＣＰサーバ１５が用意している複数のＩＰアドレスのうち、取得要求が出された時点で未使用であった任意のＩＰアドレスである。したがって、同じＶｏＩＰ用ＴＡ（例えば、１３）に設定されるＩＰアドレスは、新たに取得要求を出すたびに変動し得る。
【０００６】
ＶｏＩＰシステム１２の配下には、前記ＶｏＩＰ用ＴＡ１３と同様な端末が複数もうけられ得るから、これらの端末からの要求に応じて、同様な処理は、図２のステップＳ１３，Ｓ１４に示すように、複数回繰り返される。
【０００７】
【発明が解決しようとする課題】
ところが、このようなアドレス割当方法を用いると、前記ＤＨＣＰサーバ１５に対して取得要求を送信するシステムが図３のシステム１０と２０のように複数存在する場合などには、他システム２０によって大量のＩＰアドレスを取得されてしまい、取得要求に応じたＩＰアドレスの割当てが行えない場合があり、システムの可用性が低い。
【０００８】
この場合の処理は、例えば、図４のステップＳ１５〜Ｓ１８に示すような手順になる。
【０００９】
図４では、ＤＨＣＰサーバ１５は、取得要求に応じて割り当てるＩＰアドレスとして２５４ホスト分のＩＰアドレスを用意していたが、システム２０からの２５４回の取得要求（１つのステップＳ１５として図示している）で２５４個のＩＰアドレスを割り当ててしまったあと（Ｓ１６）、システム１０から取得要求を受けても（Ｓ１７）、すでに割り当てることのできる未使用のＩＰアドレスは残っていないため、使用可能なＩＰアドレスが存在しないことを通知することになる（Ｓ１８）。
【００１０】
いったん割り当てられたＩＰアドレスも、そのＩＰアドレスを用いる通信が終了すれば返却されて未使用状態となるため、この返却のあと、ＤＨＣＰサーバ１５はシステム１０からの取得要求にこたえることが可能であるが、返却が行われるまでの期間は、ＶｏＩＰを利用する電話機１４は例えば発呼することも着呼することもできず、緊急性を要する会話のために電話をかけたり、受けたりする場合などに著しく不都合である。
【００１１】
このケースで、他システムもＶｏＩＰに対応するシステム１０と同様なＶｏＩＰ通信に対応するシステムであれば、結局は、ホスト数や通信の頻度に比較してＤＨＣＰサーバ１５が用意したＩＰアドレスの数が不足しているという問題に帰着することになるが、他システム２０がＶｏＩＰの通信のようにリアルタイム性を必要としないアプリケーション（例えば、ＦＴＰなど）に対応したものである場合などには、適切な対策を講じることによって、柔軟に、リアルタイム通信の可用性を高めることができる可能性がある。
【００１２】
ここで、リアルタイム通信とは、例えば、ＩＰ電話などのように、呼び出しや応答に即時性が要求される通信を指す。
【００１３】
一方、図２に示すようなアドレス割当方法では、取得要求が出された時点で未使用のＩＰアドレスが割り当てられるため、例えば図５に示すように、ＶｏＩＰシステム１２が自身の配下の複数のＶｏＩＰ用ＴＡ（その１つが１３）のために複数のＩＰアドレスを取得した場合、それらのＩＰアドレスは不連続な値を持つものとなり、ＶｏＩＰシステム１２におけるアドレス管理が複雑で非効率なものになる。
【００１４】
同様に、ＤＨＣＰサーバ１５などにおけるアドレス管理も、複雑なものになる。
【００１５】
図５においてＤＨＣＰサーバ１５は取得要求を受けた順番に、１ずつ大きな値のＩＰアドレスを割り当ててる動作を繰り返すが、ステップＳ２０，Ｓ２１でシステム１０がＩＰアドレスを取得したあと、ステップＳ２２，Ｓ２３でシステム２０がＩＰアドレスを取得したため、そのあと、ステップＳ２４，Ｓ２５でシステム１０が取得するＩＰアドレスの値は、前記ステップＳ２０、Ｓ２１で取得した値に連続した値（すなわち、前回取得したＩＰアドレスの値を＋１または−１して得られる値）ではなくなってしまう。
【００１６】
【課題を解決するための手段】
かかる課題を解決するために、本発明では、所定の管理範囲内に存在する通信端末からの割当要求を受けるたびに、自身が保管しているアドレスのうち未割当のアドレスのなかから選択したアドレスを動的に割り当てる動的アドレス割当サーバを有するアドレス割当システムにおいて、（１）前記動的アドレス割当サーバと複数の通信端末とのあいだに介在するアドレス割当中継システムを設け、前記アドレス割当中継システムは、前記複数の通信端末のため、各通信端末が実際に割当要求を送信する前に、前記動的アドレス割当サーバに対し、要求元アドレスとして仮の要求元アドレスを含む、複数のアドレスを連続的に有するアドレスブロックを確保するための連続割当要求を送出し、（２）前記動的アドレス割当サーバは、（２−１）前記アドレス割当中継システムからの前記連続割当要求を受けると、自身が保管しているアドレスのうち未割当のアドレスのなかから連続した所定数のアドレスを確保すると共に、確保した所定数のアドレスに前記仮の要求元アドレスを対応付けることで予約済みであることを管理し、（２−２）前記アドレス割当中継システムによる中継対象である前記通信端末が割当要求を送信してきたときには、確保された所定数のアドレスのうち、前記仮の要求元アドレスに対応付けられている一つのアドレスを割り当て、その割当アドレスに対し、前記仮の要求元アドレスに代え、今回の要求元の前記通信端末に係る要求元アドレスを対応付けることを特徴とする。
【００１７】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかるアドレス割当システムを、ＩＴＵ−Ｔ勧告Ｈ．３２３に準拠した環境などでＶｏＩＰを行うＶｏＩＰネットワークに適用した場合を例に、実施形態について説明する。
【００１８】
（Ａ−１）実施形態の構成
本実施形態のＶｏＩＰネットワーク３０の全体構成例（構成要素の詳細構成例を含む）を、図８に示す。
【００１９】
図８において、当該ＶｏＩＰネットワーク３０は、ＩＰ網３１と、当該ＩＰ網３１によって接続された４つの拠点３２〜３５を備えている。
【００２０】
このうちＩＰ網３１は、インターネットなどにも置換可能であるが、ここでは特定の通信事業者が構築、運営して、ユーザに提供するＩＰ網であるものとする。このようなＩＰ網はＩＰプロトコルを用いた通信を行う点でインターネットと同じであるが、通信事業者の用意する設備などに応じて、通信品質を保証することができる点が相違する。
【００２１】
ＩＰ網３１は、ユーザ企業自らが自身の社員等に利用させるために構築するものであってもかまわないが、このように通信事業者が構築したものである場合、当該通信事業者は当該ＩＰ網３１を複数のユーザ企業に共用させ、各ユーザ企業に対し、ＶｏＩＰサービスを提供する形態となるのが普通である。この場合、１つの企業がその拠点間を秘匿性を保ちながら接続できるように、ＩＰ−ＶＰＮを利用することが多い。
【００２２】
当該ＩＰ網３１は、必要に応じて、インターネットと接続したり、既存の加入電話網と接続することもできる。
【００２３】
図８中に示した拠点３２〜３５は、当該ＩＰ網３１を共用する複数のユーザ企業のうち、１つの企業の営業所、支社、本社などに相当するＬＡＮ（ローカルエリアネットワーク）であってよい。
【００２４】
ＬＡＮ３２〜３５内のネットワーク構成には様々なものがあり得、実際には本社と、支社、営業所などではネットワーク構成が相違することも多いが、少なくとも、プロビジョニングシステム４１，ＤＨＣＰサーバ４２，ＶｏＩＰシステム４５などの主要な構成要素を備えている点で同じであってよいため、ここでは細部にこだわらず、すべての拠点３２〜３５のネットワーク構成が実質的に同じであるものとして説明する。
【００２５】
このような拠点３２〜３５のうち、拠点３５の構成要素は例えば図７に示す通りであってよいが、図８には、当該拠点３５について、より詳細な構成例を示している。
【００２６】
すなわち当該拠点３５は、ルータ４０と、前記プロビジョニングシステム４１と、ＤＨＣＰサーバ４２と、パソコン４３，４４（図７の他システム７０に対応）と、ＶｏＩＰシステム４５と、ＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎと、一般電話機４７Ａ〜４７Ｎとを備えている。
【００２７】
このうちルータ４０は、ＩＰ網３１に対し拠点３５内の伝送路Ｌ１を接続する機器である。
【００２８】
ここでは、ルータ４０がＩＰ網３１側のポートＰ１と、伝送路Ｌ１側のポートＰ２しか持たないものとしているが、拠点３５の内部側にポートＰ２以外のポートを持つ場合には、プロビジョニングシステム４１と、ＤＨＣＰサーバ４２と、パソコン４３，４４と、ＶｏＩＰシステム４５を別のポートに接続するようにしてもよいことは当然である。
【００２９】
前記ＩＰ−ＶＰＮを利用する場合、ＩＰ−ＶＰＮのために必要な暗号化や復号化の機能は、当該ルータ４０に搭載されるものであってよい。
【００３０】
ゲートキーパ機能なども、当該ルータ４０に搭載され得る。
【００３１】
ゲートキーパとは、電話番号とＩＰアドレスの対応関係を管理する一種のサーバで、ＶｏＩＰ用ＴＡ（例えば、４６Ａ）などからの問い合わせに応じて、ＩＰアドレスを返す機能を持つ。電話をかける際、電話機のユーザ（例えば、Ｕ３）が電話機（例えば、４７Ｎ）に入力するのは、通信相手の電話番号だけであるが、ＩＰプロトコルに応じた通信を行うＩＰ網３１上で通信相手を識別するために有効な唯一の識別子はＩＰアドレスであるから、当該ゲートキーパに問い合わせて、当該電話番号に対応するＩＰアドレスを取得することが必要になる。
【００３２】
パソコン４３，４４は、ネットワーク機能を搭載した通常のパーソナルコンピュータであるが、ＦＴＰクライアントの機能や、ビデオ会議システムの機能などを搭載するものであってもよい。マイクやスピーカなどを装備させ、ＩＰ電話機としてのソフトウエアを搭載させれば、パソコン４３，４４をＩＰ電話機として利用することも可能である。
【００３３】
ただし本実施形態では、上述したリアルタイム通信を行うＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎなどとの対比を明確化するため、当該パソコン４３，４４はリアルタイム通信ではない、ＦＴＰ通信などを行うＦＴＰクライアントとしての機能を持つ場合を想定する。
【００３４】
前記パソコン４３はユーザＵ４によって操作され、パソコン４４はユーザＵ５によって操作されるものとする。
【００３５】
後述する２５４ホスト分のグローバルＩＰアドレスがＤＨＣＰサーバ４２に用意されていることからすると、拠点３５内のホスト数がこの２５４よりも少ないということは通常あり得ないため、パソコン４３，４４などの数は、数百台程度、あるいはそれ以上であってよい。
【００３６】
ＶｏＩＰシステム４５は、ＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎを介して一般電話機４７Ａ〜４６Ｎを収容し、ＶｏＩＰを用いた音声通信に対して、ＰＢＸ（構内交換機）や公衆電話網上の電話交換機に類似した交換機能を提供するシステムである。
【００３７】
このためＶｏＩＰシステム４５は、ＶｏＩＰ用ＴＡ（例えば、４６Ａ）にＤＨＣＰサーバ４２からＩＰアドレスが割当られた場合、プロビジョニングシステム４１を介して、そのＩＰアドレスと、当該ＶｏＩＰ用ＴＡ（この場合、４６Ａ）のＭＡＣアドレスの対応関係の通知を受ける。当該ＶｏＩＰシステム４５は、前記通信事業者が拠点３５内に設置するものであってよい。
【００３８】
ＶｏＩＰ用ＴＡ４６Ａ〜４７Ｎは、呼制御機能、コーデック機能、ＶｏＩＰ機能などを装備したターミナルアダプタである。ＶｏＩＰ機能を装備していることから、当該ＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎは、一種のＶｏＩＰゲートウエイとみることができる。
【００３９】
また、必要に応じて、前記ＤＨＣＰサーバ４２に対して取得要求の送信などを行うＤＨＣＰクライアントの機能も、当該ＶｏＩＰ用ＴＡ４６Ａ〜４７Ｎに搭載するものであってよい。
【００４０】
ここでは、一般電話機４７Ａ〜４７Ｎを接続しているが、ＶｏＩＰ用ＴＡは、Ｇ３ファクシミリや、パソコンなどをＩＰ網に接続することもでき、比較的低コストでＩＰ統合を実現することが可能である。
【００４１】
ＶｏＩＰ用ＴＡ４６Ａは一般電話機４７Ａのために機能し、ＶｏＩＰ用ＴＡ４６Ｂは一般電話機４７Ｂのために機能し、…、ＶｏＩＰ用ＴＡ４６Ｎは一般電話機４７Ｎのために機能する。
【００４２】
一般電話機４７Ａ〜４７Ｎは、自身ではＶｏＩＰ機能を搭載していないＶｏＩＰ非対応の通常の電話機である。
【００４３】
いわゆるＩＰ電話機は、原理上、当該一般電話機の機能とＶｏＩＰ用ＴＡの機能を１装置内に備えた通信装置であるとみることができる。
【００４４】
したがって、ＶｏＩＰシステム４５は、必要に応じて、ＩＰ電話機を収容することも可能である。
【００４５】
一般電話機４７ＡはユーザＵ１によって操作され、一般電話機４７ＢはユーザＵ２によって操作され、…、一般電話機４７ＮはユーザＵ３によって操作される。
【００４６】
前記ＤＨＣＰサーバ４２は、ＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎ、パソコン４３、４４などからの取得要求に応じて、ＩＰアドレスを割り当てるサーバである。
【００４７】
多くの場合、ＤＨＣＰサーバは、ＮＡＴを併用するなどの条件下で、ＬＡＮ内でのみ一意なプライベートＩＰアドレスを割り当てるが、本実施形態のＤＨＣＰサーバ４２が割り当てるのはグローバルＩＰアドレスである。グローバルＩＰアドレスは、グローバルに一意性が保証されている（したがって、当然、ＬＡＮ内でも一意性が保証されている）が、現在では枯渇が危惧されている。
【００４８】
呼制御プロトコルとして、ＩＴＵ−Ｔ勧告Ｈ．３２３やＳＩＰを利用するＩＰ電話はＮＡＴ（あるいは、ＩＰマスカレード）を経由すると正常な通信を行うことが困難になるアプリケーションの１つである。
【００４９】
その原因は、主として、ＩＰパケットのデータ部（ペイロード部）に、送信元ＩＰアドレス（プライベートＩＰアドレス）やポート番号を格納して送信し、通信相手が、当該データ部から取り出した送信元ＩＰアドレスを宛先ＩＰアドレスとして、返送のＩＰパケットを送り返す仕組みになっており、なおかつ、ＮＡＴ（あるいは、ＩＰマスカレード）が、ヘッダ部の送信元ＩＰアドレスは変換しても、データ部の送信元ＩＰアドレスまでは変換しないことによる。プライベートＩＰアドレスは、ＬＡＮの外部では有効な識別子として機能し得ないからである。
【００５０】
この対策としては、ＬＡＮ内でプライベートＩＰアドレスを用いずグローバルＩＰアドレスを用いること（したがって、ＮＡＴを用いない）や、いわゆるＮＡＴトラバーサルの利用が有効である。
【００５１】
ＬＡＮ内でグローバルＩＰアドレスを用いれば、ＬＡＮ内の構造が外部から知られやすくセキュリティ性が低下したり、十分な数のグローバルＩＰアドレスを用意することが困難である等の問題が生じ得るが、特別な機能の追加などが不要で、簡単な処理によって通信を行うことができる。
【００５２】
これに対し、ＮＡＴトラバーサルでは、ＮＡＴは利用し、前記データ部に格納する送信元ＩＰアドレスとして、ルータ４０のポートＰ１側のＩＰアドレス（グローバルＩＰアドレス）を格納させるため、セキュリティ性は低下せず、グローバルＩＰアドレスの数が不足することもない。しかしながら、適宜、ルータ４０のポートＰ１側のＩＰアドレス（グローバルＩＰアドレス）をＶｏＩＰ用ＴＡ（例えば、４６Ａ）などに通知する処理が必要になり、そのような通知を要求したり、通知を行ったりするため、ルータ４０やＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎ、パソコン４３，４４などが、ＮＡＴトラバーサルに対応したものであることが条件となり、実現に多くのコストや手間を要することが多い。
【００５３】
本実施形態はこれらのいずれの場合にも適用可能である。
【００５４】
ＬＡＮ（拠点３５）内でプライベートＩＰアドレスを用いずグローバルＩＰアドレスを用いる場合には、各端末（例えば、ＶｏＩＰ用ＴＡ４６Ａ）は、ＤＨＣＰサーバ４２が割り当てるグローバルＩＰアドレスを、自身の送信元ＩＰアドレスとして用いることとなり、ＮＡＴトラバーサルを用いる場合には、ルータ４０から通知されるポートＰ１のグローバルＩＰアドレスを、ＤＨＣＰサーバ４２が割り当てるグローバルＩＰアドレスに対応させておけばよいからである。
【００５５】
ＤＨＣＰサーバ４２はＴＣＰ／ＩＰ関連の各種設定情報（ＩＰアドレスも含む）の設定を自動化し、必要が生じたときに動的に設定するサーバである。したがってＤＨＣＰサーバが設定する設定情報には、サブネットマスク、デフォルトゲートウエイなどＩＰアドレス以外の情報も含まれるが、ここでは、ＩＰアドレスに注目する。ＤＨＣＰサーバ４２を用いることにより、各端末に手動で設定情報の設定を行う場合などに比べ、設定に関する作業負担の軽減、設定ミスによるトラブル発生の防止、ＩＰアドレスの使用効率向上（多数のホスト間で、少数のＩＰアドレスを共用する）などの効果を得ることができる。
【００５６】
当該ＤＨＣＰサーバ４２は例えば図９に示すような内部構成を有する。ＤＨＣＰサーバの機能は、例えばルータ４０などに、ソフトウエア的に実装することもできるが、本実施形態のＤＨＣＰサーバ４２は独立したマシンである。
【００５７】
（Ａ−１−１）ＤＨＣＰサーバの内部構成例
図９において、当該ＤＨＣＰサーバ４２は、通信部５０と、制御部５１と、アドレス管理部５２と、レンジ（ＲＡＮＧＥ）対応部５３とを備えている。
【００５８】
このうち通信部５０は、前記伝送路Ｌ１を介して拠点３５内の各構成要素４１，４３，４４などと通信を行う部分である。
【００５９】
制御部５１はハードウエア的には当該ＤＨＣＰサーバ４２の中央処理装置（ＣＰＵ）であり、ソフトウエア的にはオペレーティングシステム（ＯＳ）などである。
【００６０】
アドレス管理部５２は、所定のアドレス管理テーブルＴＢ２を管理する部分で、一種のデータベースを構成する。
【００６１】
当該アドレス管理テーブルＴＢ２は、図１に示すように、列名（データ項目）としてＩＰアドレスとＭＡＣアドレスを備えたテーブルであり、ＩＰアドレスとＭＡＣアドレスの対応関係を管理する。対応するＭＡＣアドレスが空値となっているＩＰアドレスが、未使用のＩＰアドレスである。
【００６２】
図１上、当該アドレス管理テーブルＴＢ２には、ドット表記でＩＰアドレスが格納されており、小さな値のＩＰアドレスほど、上の行に配置され、上下に隣接するＩＰアドレスの値（１だけ相違する）は連続したものとなっている。
【００６３】
すなわち、最上部の行には「１．１．１．１」が配置され、上から２番目の行には、「１．１．１．２」が配置され、上から３番目の行には、「１．１．１．３」が配置され、…というように、値が連続している。
【００６４】
このように連続した値をアドレス管理テーブルＴＢ２に格納することができるのは、その前提として、このユーザ企業または通信事業者が、グローバルＩＰアドレスの配布を管理する組織（レジストリ等）から、値の連続したＩＰアドレスの集合（アドレスブロック）の配布を受けたことを意味する。
【００６５】
過去に配布されたものは別として、ＩＰアドレスの枯渇問題が深刻化している現在では、レジストリから大きなアドレスブロック（例えば、２５６個（２５４ホスト分）の連続したＩＰアドレスを含むアドレスブロック（これは、クラスＣに相当））が配布されることはなく、ＣＩＤＲにより、高々、１０数個程度の連続した値のＩＰアドレスを含む小さなアドレスブロックが配布されるにすぎない（その場合でも、そのなかから、後述するレンジブロックを確保することは可能である）が、ＩＰ網３１を運営する通信事業者が過去に大きなアドレスブロック（例えば、クラスＡやクラスＢ）の配布を受けている場合などには、そのアドレスブロックのなかから、例えば２５６個ものＩＰアドレスを含む大きなアドレスブロックを選定し、企業ユーザに対して再配布できる可能性はある。
【００６６】
また、ＩＰ網３１などのルータ（図示せず）が管理する経路情報を簡単にする観点などから、高々、１０数個程度であるとしても、不連続ではなく、連続した値のＩＰアドレスが配布される可能性は高い。
【００６７】
当該アドレス管理部５２は、ＤＨＣＰサーバ４２がＩＰアドレスの取得要求に応じてＩＰアドレスを割り当てるたびに、割り当てたＩＰアドレスに対し、取得要求の送信元の端末（例えば、４６Ａや、４３など）のＭＡＣアドレスを対応付けて格納する。ここでは、一例として、ＩＰアドレスの値が小さい順に、割り当てを行っている。
【００６８】
拠点３５内で、例えば、ＡＲＰプロトコルにしたがって、あるＭＡＣアドレスに対応するＩＰアドレスの問い合わせが発生した場合（あるいは、その逆の問い合わせが発生した場合）など、当該アドレス管理テーブルＴＢ２の内容を基準に応答することができる。
【００６９】
レンジ対応部５３は、当該アドレス管理テーブルＴＢ２上に、値の連続したＩＰアドレスの確保を行わせる部分で、ＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎのために機能する。
【００７０】
レンジ対応部５３は、前記プロビジョニングシステム４１からの要求に応じて、連続した所定の範囲（レンジ）のアドレスブロック（レンジブロック）を、ＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎのために確保する部分である。
【００７１】
拠点３５内で様々な構成要素から送信される取得要求のうち、レンジブロックの確保を要求する信号をどのようにして識別するかについては、様々な方法が利用可能であるが、ここでは、送信元ＭＡＣアドレスが所定の値（仮ＭＡＣアドレスに対応）であれば、レンジブロックの取得要求と判定するものとする。
【００７２】
この判定を行うのも、当該レンジ対応部５３である。
【００７３】
また、レンジブロックに含まれるＩＰアドレスの数を可変とするか固定とするか等に関しても様々な方法が利用可能であるが、ここでは、可変とし、一例として、５個に設定するものとする。
【００７４】
この値（ここでは、５個）は、ＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎの数を上限として変更可能である。一般電話機４７Ａ〜４７Ｎの利用頻度（稼働率）が高ければ上限値に設定するとよく、低い場合には、上限値よりも小さな値、例えば、ＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎの数の半分、あるいは３分の１などに設定してもよい。
【００７５】
また、ネットワーク構成が変更され、一般電話機の追加や削除などが行われることもあり得るが、そのようなケースも、この値（ここでは、５個）を変更する要因となる。
【００７６】
この値は、後述する仮ＭＡＣアドレスを送信元ＭＡＣアドレスとし、宛先ＭＡＣアドレスをＤＨＣＰサーバ４２とするＭＡＣフレーム（前記取得要求などのために送信される）にカプセル化されているＩＰパケットのペイロード部に記述するようにしておくとよい。
【００７７】
レンジブロックは連続した値になっているため、３２ビットのＩＰｖ４アドレスのうち、多くの場合、右端部の高々１バイト程度を管理すればよく、ＤＨＣＰサーバやＶｏＩＰシステムにおける管理も効率的に行うことができる。
【００７８】
具体的には、１．１．１．１〜１．１．１．５のレンジブロックでは、右端部の１バイトの変化幅が１０進数表示で、１〜５（すなわち、二進数表示で、０００００００１〜０００００１０１）であるため、右端部の１バイトのなかでも、右端に位置する３ビットの変化だけを管理すれば、レンジブロック全体の管理を矛盾なく行うことが可能になる。
【００７９】
このような管理を行うと、レンジブロックが大きくなればなるほど、効率が高まる。
【００８０】
一方、前記プロビジョニングシステム４１は、ネットワークに柔軟性を付与するために前記通信事業者が拠点３５内に設置する機器で、その主要部の構成例を、図１０に示す。
【００８１】
（Ａ−１−３）プロビジョニングシステムの構成例
図１０において、当該プロビジョニングシステム４１は、通信部６０と、制御部６１と、予約対応部６２と、仮ＭＡＣアドレス生成部６３とを備えている。
【００８２】
このうち通信部６０は前記通信部５０に対応し、制御部６１は前記制御部５１に対応するので、その詳しい説明は省略する。
【００８３】
仮ＭＡＣアドレス生成部６３は上述した仮ＭＡＣアドレスを生成する部分である。
【００８４】
仮ＭＡＣアドレスは基本的に架空のＭＡＣアドレスであるが、その値をどのように決定するかについては様々な方法を用いることができる。ＭＡＣアドレスはＬＡＮカードなどの製造段階などにおいて各製造業者によって決定される４８ビット長のデータで、ＯＳＩ参照モデルのデータリンク層の識別子として利用される。本来、一意性が保証されているものであり、各種の通信システムは、ＭＡＣアドレスの一意性が保証されていることを前提に構築されるため、仮ＭＡＣアドレスの生成によって一意性が失われることは好ましくない。
【００８５】
したがって、仮ＭＡＣアドレス生成部６３は、当該仮ＭＡＣアドレスを生成する前に、拠点３５内に偶然、同じ値のＭＡＣアドレスを持つ端末が存在しないことを確認してから仮ＭＡＣアドレスを生成することが望ましい。
【００８６】
もし可能ならば、プロビジョニングシステム４１の通信部６０（通信部６０のうちのＬＡＮカードに対応する部分（ＯＳＩ参照モデルのデータリンク層以下のプロトコルに対応する））の持つ実際のＭＡＣアドレスを当該仮ＭＡＣアドレスとして利用するようにしてもよい。
【００８７】
以下、上記のような構成を有する本実施形態の動作について、図１のシーケンス図を参照しながら説明する。
【００８８】
図１のシーケンス図は、Ｓ３０〜Ｓ３８の各ステップから構成されている。
【００８９】
（Ａ−２）実施形態の動作
ステップＳ３０において、前記プロビジョニングシステム４１が前記仮ＭＡＣアドレスを送信元ＭＡＣアドレスとするＭＡＣフレームを送信することで、ＤＨＣＰサーバ４２に対し前記レンジブロックの取得要求を出す。
【００９０】
レンジブロックの取得要求は、ＤＨＣＰサーバ１５が取得要求を受けるたびに１つずつ先着順で割り当てて行くＩＰアドレスを、まとめて予約することに等しい。この予約はＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎのために行われる予約である。
【００９１】
このときもしも、アドレス管理テーブルＴＢ２上に、前記固定値（５個）分の連続した未使用（未割当）のＩＰアドレスがなければ、ＤＨＣＰサーバ４２はレンジの設定が不可能である旨の通知を返送することになり、この通知を受けたプロビジョニングシステム４１は例えば定期的にレンジブロックの取得要求を送信する。
【００９２】
通常、いったんＤＨＣＰサーバ１５から割り当てられたＩＰアドレスも、割当先の端末（例えば、パソコン４３）による通信が終了すれば回収され、未使用の状態にもどるため、いつかは必ずレンジブロックを取得することが可能になり、レンジの設定が行われた旨の応答（Ｓ３１）が、ＤＨＣＰサーバ４２からプロビジョニングシステム４１に返送される。
【００９３】
なお、当該プロビジョニングシステム４１によるレンジブロックの取得要求は、ＶｏＩＰ用ＴＡ４６Ａ〜４６Ｎから取得要求が出されるか否かと無関係に、プロビジョニングシステム４１の機能によって実行される。
【００９４】
図１では、当該ステップＳ３１でレンジ設定応答を受けた後、実際に静的確保（予約）を指示するステップＳ３２を行っているが、ステップＳ３１とＳ３２は１ステップに集約することも可能である。
【００９５】
いずれにしても、レンジブロックが確保（予約）できると、図１に示すように、前記アドレス管理テーブルＴＢ２のＭＡＣアドレスとして、仮ＭＡＣアドレスの値が格納される。
【００９６】
図１の例では、５つの連続するＩＰアドレス（１．１．１．１〜１．１．１．５）がレンジブロックとして予約されている。
【００９７】
このあと、もしもパソコン４３などが取得要求を送信したとしても、ＤＨＣＰサーバ４２は当該レンジブロック以外の範囲のＩＰアドレス（例えば、１．１．１．６など）を割り当て、当該レンジブロック内のＩＰアドレスを割り当てることはない。
【００９８】
レンジブロックが予約されたあと、実際に、いずれかのＶｏＩＰ用ＴＡ（例えば、４６Ａ）が、自身のＭＡＣアドレス（ここでは、「ＡＡ−ＡＡ−ＡＡ−ＡＡ−ＡＡ−０１」）を送信元ＭＡＣアドレスとするＭＡＣフレームを、前記ＶｏＩＰシステム４５またはプロビジョニングシステム４１に送信することによって、取得要求が出されると、プロビジョニングシステム４１がこの取得要求をＤＨＣＰサーバ４２へ中継し（Ｓ３３）、予約したレンジブロックのなかから任意の１つのＩＰアドレスの割り当てを受ける。
【００９９】
ここでは、ＤＨＣＰサーバ４２が先着順で小さい値から割り当てて行くものとしているため、予約後、最初に取得要求を出した当該ＶｏＩＰ用ＴＡ４６Ａには、前記「１．１．１．１」が割り当てられている。
【０１００】
割り当てられたＩＰアドレスの値や、当該ＩＰアドレスの値とＭＡＣアドレスの対応関係は、ＤＨＣＰサーバ４２からプロビジョニングシステム４１へ返送される（Ｓ３４）。
【０１０１】
図１の例では、上述したパソコン４３などからの取得要求はステップＳ３４のあとで発生しており（Ｓ３５）、この取得要求に応じて、ＤＨＣＰサーバ４２は、前記レンジブロック以外のＩＰアドレスを割り当てている（Ｓ３６）。
【０１０２】
このあと、ＶｏＩＰ用ＴＡ４６Ｂ〜４６ＮのうちのいずれかのＴＡから取得要求が出され、プロビジョニングシステム４１によって中継された場合も、前記ＶｏＩＰ用ＴＡ４６Ａの場合と同様に、前記レンジブロックのなかからＩＰアドレスが割り当てられる（Ｓ３７，３８）。
【０１０３】
以降は同様な動作の繰り返しである。
【０１０４】
（Ａ−３）実施形態の効果
本実施形態によれば、プロビジョニングシステム（４１）の機能などによって柔軟性が高まり、リアルタイム通信を行うＶｏＩＰ用ＴＡ（４６Ａ〜４６Ｎ）のために限られたグローバルＩＰアドレスを予約することができるから、ＶｏＩＰ用ＴＡの可用性が高まる。
【０１０５】
また、レンジブロックは連続した値になっているため、ＤＨＣＰサーバやＶｏＩＰシステムにおけるアドレス管理も効率的に行うことができる。
【０１０６】
（Ｂ）他の実施形態
上記実施形態のＩＰ電話（一般電話機とＶｏＩＰ用ＴＡの組）は、ネットワークゲームやビデオ会議システムなど、各種のリアルタイム通信のための通信端末（アプリケーション）に置換することが可能である。
【０１０７】
また、上記実施形態では、プロビジョニングシステム４１やＤＨＣＰサーバ４２は専用のマシンであったが、これらの機能をソフトウエア的に実現し、拠点３５内のその他の構成要素（例えば、ルータ４０など）に実装することも可能である。
【０１０８】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０１０９】
【発明の効果】
以上に説明したように、本発明によれば、柔軟性を高め、前記通信端末の可用性を向上することができる。
【０１１０】
また、本発明では、アドレス管理を効率化することも可能である。
【図面の簡単な説明】
【図１】実施形態に係るＶｏＩＰネットワークの主要部の動作を示すシーケンス図である。
【図２】従来のＶｏＩＰネットワークの主要部の動作を示すシーケンス図である。
【図３】発明が解決しようとする課題を説明するための、ＶｏＩＰネットワークの主要部の構成例を示す概略図である。
【図４】発明が解決しようとする課題を説明するための、ＶｏＩＰネットワークの主要部の動作を示すシーケンス図である。
【図５】発明が解決しようとする課題を説明するための、ＶｏＩＰネットワークの主要部の動作を示すシーケンス図である。
【図６】発明が解決しようとする課題を説明するための、ＶｏＩＰネットワークの主要部の構成例を示す概略図である。
【図７】実施形態に係るＶｏＩＰネットワークの主要部の構成例を示す概略図である。
【図８】実施形態に係るＶｏＩＰネットワークの主要部の接続関係の一例を示す概略図である。
【図９】実施形態に係るＶｏＩＰネットワークで使用するＤＨＣＰサーバの主要部の構成例を示す概略図である。
【図１０】実施形態に係るＶｏＩＰネットワークで使用するプロビジョニングシステムの主要部の構成例を示す概略図である。
【符号の説明】
１１、４１…プロビジョニングシステム、１２，４５…ＶｏＩＰシステム、１３，４６Ａ〜４６Ｎ…ＶｏＩＰ用ＴＡ、１４，４７Ａ〜４７Ｎ…一般電話機、１５，４１…ＤＨＣＰサーバ、３０…ＶｏＩＰネットワーク、３１…ＩＰ網、３２〜３５…ＬＡＮ、４０…ルータ、５２…アドレス管理部、５３…レンジ対応部、６２…予約対応部、６３…仮ＭＡＣアドレス生成部。

Claims

所定の管理範囲内に存在する通信端末からの割当要求を受けるたびに、自身が保管しているアドレスのうち未割当のアドレスのなかから選択したアドレスを動的に割り当てる動的アドレス割当サーバを有するアドレス割当システムにおいて、
前記動的アドレス割当サーバと複数の通信端末とのあいだに介在するアドレス割当中継システムを設け、
前記アドレス割当中継システムは、前記複数の通信端末のため、各通信端末が実際に割当要求を送信する前に、前記動的アドレス割当サーバに対し、要求元アドレスとして仮の要求元アドレスを含む、複数のアドレスを連続的に有するアドレスブロックを確保するための連続割当要求を送出し、
前記動的アドレス割当サーバは、
前記アドレス割当中継システムからの前記連続割当要求を受けると、自身が保管しているアドレスのうち未割当のアドレスのなかから連続した所定数のアドレスを確保すると共に、確保した所定数のアドレスに前記仮の要求元アドレスを対応付けることで予約済みであることを管理し、
前記アドレス割当中継システムによる中継対象である前記通信端末が割当要求を送信してきたときには、確保された所定数のアドレスのうち、前記仮の要求元アドレスに対応付けられている一つのアドレスを割り当て、その割当アドレスに対し、前記仮の要求元アドレスに代え、今回の要求元の前記通信端末に係る要求元アドレスを対応付ける
ことを特徴とするアドレス割当システム。
請求項１のアドレス割当システムにおいて、
前記連続割当要求には、アドレス割当を要求する所定数の情報が盛り込まれていることを特徴とするアドレス割当システム。