JP2007221533A - Ｐｐｐゲートウェイ装置 - Google Patents

Abstract

【課題】ＰＰＰクライアント端末とレイヤ２ネットワークとを接続するＰＰＰゲートウェイ装置を提供する。
【解決手段】クライアント端末と接続されるアクセス回線またはレイヤ２フレーム転送装置と接続されるコア回線の何れかを収容する複数の回線インタフェースと、フレーム転送制御テーブルと、フレーム転送を制御するフレーム処理部とを備えたＰＰＰゲートウェイ装置において、上記フレーム転送制御テーブルが、ＰＰＰセッション番号と、クライアントＭＡＣアドレスと、コア回線側のフレーム定義情報との対応関係を示し、フレーム処理部が、上記フレーム転送制御テーブルに基いて、各アクセス回線から受信したＰＰＰフレームをレイヤ２イーサネットフレームに変換した後、何れかのコア回線に転送し、各コア回線から受信した特定クライアントのＭＡＣアドレス宛フレームをＰＰＰフレームに変換した後、何れかのアクセス回線に転送する。
【選択図】図１

Description

本発明は、ＰＰＰゲートウェイ装置に関し、更に詳しくは、ＯＳＩ参照モデルのレイヤ２のプロトコルでフレーム転送を行うアクセス網に対して複数のクライアント端末をＰＰＰリンクで接続するためのＰＰＰゲートウェイ装置に関する。

ＲＦＣ１６６１（非特許文献１）、ＲＦＣ１３３２（非特許文献２）では、通信ノード間にＰＰＰ（Point to Point Protocol）リンクを確立する手順、ＰＰＰリンク上に各種のレイヤ３リンクを確立して双方向通信を行う手順が定義されている。ＲＦＣ１３３４（非特許文献３）では、ＰＰＰリンクの接続過程で接続相手となるネットワーク装置を認証するためのプロトコルについて定義している。

ＲＦＣ２５１６（非特許文献４）では、イーサネット（登録商標）上に複数のＰＰＰを設定するためのプロトコルＰＰＰｏＥ（PPP over Ethernet）について規定している。ＰＰＰｏＥでは、同一回線上に多重化された複数のリンクがセッション番号によって識別される。イーサネットやＡＴＭ網上に形成された複数のＰＰＰリンクを収容し、それらをインターネットに接続するネットワーク装置は、一般に、ＢＡＳ（Broadband Access Server）と呼ばれている。

ＰＰＰリンクの接続過程で、通信ノードは、例えば、ＲＦＣ２８５６（非特許文献５）で規定されたＲＡＤＩＵＳ（Remote Authentication Dial In User Service）や、ＲＦＣ１４９２（非特許文献６）で規定されたＴＡＣＡＣＳなどの認証サーバと連携して、クライアント端末を認証することができる。ＲＡＤＩＵＳサーバは、ユーザ認証機能の他に、ユーザへの権限付与機能や課金機能を備えており、ユーザ端末のインターネットへの接続にダイヤルアップ方式が採用されていた頃から、ＰＰＰと共に使用されている。また、ユーザ端末に対するＩＰアドレスの付与方式して、ＲＦＣ２１３１（非特許文献７）で規定されたＤＨＣＰ（Dynamic Host Configuration Protocol）がある。

イーサネットでは、受信パケットをＩＰアドレスによってルーティングするルータに代えて、ＭＡＣアドレスに従って受信フレームを転送するレイヤ２フレーム転送装置（Ｌ２ＳＷ）が提供されている。Ｌ２ＳＷは、比較的単純なロジックで安価にシステムを構成できるため、ユーザ端末のインターネットへの接続サービスを提供するＩＳＰ網では、イーサネットとＬ２ＳＷとを組み合わせたネットワーク構成が注目されている。

ＲＦＣ１６６１"The Point-to-Point Protocol (PPP)" ＲＦＣ１３３２"The PPP Internet Control Protocol (IPCP)" ＲＦＣ１３３４"PPP Authentication Protocols" ＲＦＣ２５１６"A Method of PPP over Ethernet (PPPoE)" ＲＦＣ２８６５"Remote Authentication Dial In User Service (RADIUS)" ＲＦＣ１４９２"An Access Control Protocol, Sometimes Called TACACS" ＲＦＣ２１３１"Dynamic Host Configuration Protocol"

ユーザ端末として、レイヤ２レベルでの接続制御機能をもつＰＰＰクライアント端末を使用した場合、これらの端末を収容する通信ノード（ＰＰＰゲートウェイ装置）では、一般的に、ＰＰＰプロトコルを終端し、インターネット（Internet）とレイヤ３（ＩＰ）でパケットを送受信している。しかしながら、最近では、ＩＳＰ網として、イーサネットとＬ２ＳＷとを組み合わせたレイヤ２接続形式のものが増えている。

Ｌ２ＳＷを含むレイヤ２接続形式のＩＳＰ網に対しては、ユーザ端末は、ＰＰＰリンクでの接続が困難となるため、単なるイーサネットリンクで接続されるのが普通である。なぜなら、ＰＰＰゲートウェイ装置を介して、Ｌ２ＳＷにＰＰＰクライアント端末（ＰＰＰリンク）を接続しようとすると、クライアントからの受信フレーム（ＩＰパケットを含むＰＰＰフレーム）の処理時に、デカプセル化されたＩＰパケットのルーティングに代えて、所定のポリシーに基く新たなレイヤ２フレーム転送技術が必要となる。また、インターネット側からの受信フレーム（ＩＰパケットを含むイーサネットフレーム）の処理時に、宛先ＩＰアドレスに応じて適切なＰＰＰリンクを選択し、受信パケットをＰＰＰフレームに変換する技術が必要となる。

本発明の目的は、複数のＰＰＰクライアント端末をレイヤ２フレーム転送装置（Ｌ２ＳＷ）に接続可能なＰＰＰゲートウェイ装置を提供することにある。

上記目的を達成するため、本発明のＰＰＰゲートウェイ装置は、クライアント端末と接続されるアクセス回線またはレイヤ２フレーム転送装置と接続されるコア回線の何れかを収容する複数の回線インタフェースと、それぞれがＰＰＰセッション番号と、クライアントＭＡＣアドレスと、コア回線側のフレーム定義情報との対応関係を示す複数のテーブルエントリからなるフレーム転送制御テーブルと、上記各クライアント端末とレイヤ２フレーム転送装置との間の通信フレームの転送を制御するフレーム処理部とを備え、
上記フレーム処理部が、上記フレーム転送制御テーブルに基いて、各アクセス回線から受信したＰＰＰフレームをレイヤ２イーサネットフレームに変換した後、何れかのコア回線に転送し、各コア回線から受信した特定クライアントのＭＡＣアドレス宛フレームをＰＰＰフレームに変換した後、何れかのアクセス回線に転送することを特徴とする。

ここで、アクセス回線がイーサネットの場合、ＰＰＰフレームは、イーサネットヘッダと、ＰＰＰｏＥヘッダと、ＰＰＰヘッダと、ＩＰパケットからなり、レイヤ２イーサネットフレームは、イーサネットヘッダと、ＩＰパケットからなる。

更に詳述すると、本発明のＰＰＰゲートウェイ装置は、上記フレーム転送制御テーブルの各テーブルエントリが、アクセス回線インタフェース番号を含み、上記フレーム処理部が、コア回線からの受信フレームを処理するとき、上記フレーム転送制御テーブルから、クライアントＭＡＣアドレスが上記受信フレームの宛先ＭＡＣアドレスと一致するテーブルエントリを検索し、該テーブルエントリが示すセッション番号に従って受信フレームをＰＰＰフレームに変換し、これを上記テーブルエントリが示すアクセス回線インタフェース番号で特定された回線インタフェースから送信することを特徴とする。

また、本発明のＰＰＰゲートウェイ装置は、上記フレーム転送制御テーブルの各テーブルエントリが、コア回線側のフレーム定義情報として、コア回線インタフェース番号と、フレーム転送装置ＭＡＣアドレスを含み、上記フレーム処理部が、アクセス回線からの受信フレームを処理するとき、上記フレーム転送制御テーブルから、セッション番号が上記受信フレームから抽出されたＰＰＰセッション番号と一致するテーブルエントリを検索し、該テーブルエントリが示すフレーム転送装置ＭＡＣアドレスを宛先として、受信フレームをレイヤ２イーサネットフレームに変換し、これを上記テーブルエントリが示すコア回線インタフェース番号で特定された回線インタフェースから送信することを特徴とする。

本発明の１実施例では、上記コア回線インタフェース番号が、物理リンク番号と論理リンク番号とからなり、上記フレーム処理部が、物理リンク番号で特定されたコア回線上に、論理リンク番号を識別情報として含むレイヤ２イーサネットフレームを送信する。

本発明の１実施例では、ＰＰＰゲートウェイ装置が、クライアント端末との間でＰＰＰｏＥおよびＰＰＰの通信手順を実行するセッション制御部を有し、上記セッション制御部が、ＰＰＰｏＥの接続手順を実行中にクライアント端末のＭＡＣアドレスとＰＰＰセッション番号を特定し、ＰＰＰリンクの確立後に行われるクライアント認証手順の実行中にコア回線側のフレーム定義情報を特定して、上記フレーム転送制御テーブルに新たなＰＰＰセッション番号と対応したテーブルエントリを追加する。

本発明の１実施例では、ＰＰＰゲートウェイ装置が、ドメイン名と、コア回線インタフェース番号と、フレーム転送装置ＭＡＣアドレスとの対応関係を定義したドメイン情報テーブルを有し、上記セッション制御部が、クライアント認証手順の実行中に、認証サーバから通知されたクライアント端末の所属ドメイン名に基いて、上記ドメイン情報テーブルからコア回線インタフェース番号とフレーム転送装置ＭＡＣアドレスを特定し、該コア回線インタフェース番号とフレーム転送装置ＭＡＣアドレスをコア回線側のフレーム定義情報として、前記フレーム転送制御テーブルに新たなテーブルエントリを追加する。

本発明のゲートウェイ装置によれば、ＰＰＰクライアント機能を備えるユーザ端末と、イーサネットからなるレイヤ２ネットワークとの接続が可能となる。また、ＰＰＰリンクを確立する際に、クライアント端末のＭＡＣアドレスを学習しておき、このＭＡＣアドレスをＰＰＰリンクが生存中に保存しておくことによって、Floodingを行うことなく、コア回線からの受信フレームの転送先を決定することが可能となる。

図１は、本発明のＰＰＰゲートウェイ装置が適用されるネットワークの概要を示す。
本発明のＰＰＰゲートウェイ装置（ＰＰＰ ＧＷ）１０は、アクセス回線Ｌａ（Ｌａ−１〜Ｌａ−ｍ）を介して複数のＰＰＰクライアント端末２０（２０−１〜２０−ｍ）に接続され、コア回線Ｌｃ（Ｌｃ−１、Ｌｃ−２）を介して、レイヤ２のフレーム転送装置（以下、Ｌ２ＳＷという）３０（３０−１、３０−２）に接続されている。Ｌ２ＳＷ３０は、クライアント端末へのＩＰアドレスの割当てを行うＤＨＣＰサーバ５０と各種の情報サービスを提供するサーバ６０とを含むインターネットＮＷと接続されている。
図１では、簡単化のためにＤＨＣＰサーバ５０とサーバ６０が、それぞれ１つずつしか示されていないが、インターネットＮＷには、ドメインと対応した複数のＤＨＣＰサーバ５０と、クライアント端末がアクセス可能な多数のサーバ６０が存在している。

ＰＰＰゲートウェイ装置１０とＬ２ＳＷ３０は、コア回線Ｌｃ上に形成されたレイヤ２のイーサネット（Ethernet）リンクによって接続され、ペイロードにＩＰパケットを含むイーサネットフレームを送受信する。この区間では、ＩＥＥＥ８０２．１ＱによるＶＬＡＮ（Virtual LAN）を適用することによって、同一の物理回線上に複数のＶＬＡＮを多重化することが可能である。この場合、イーサネットヘッダに付されるＶＬＡＮタグ（ＶＬＡＮ ＩＤ）に従って、フレームの転送制御が行われる。

Ｌ２ＳＷ３０は、イーサネットスイッチとして動作し、ＰＰＰゲートウェイ装置１０から受信したイーサネットフレームをヘッダ変換して、インターネットＮＷに転送する。また、インターネットＮＷからクライアント宛のＩＰパケットを含むイーサネットフレームを受信すると、ヘッダ変換してＰＰＰゲートウェイ装置１０に転送する。

ＰＰＰゲートウェイ装置１０に収容された各クライアント端末２０は、ＰＰＰクライアントの通信機能を備えている。各クライアント端末２０は、アクセス回線Ｌａ上に確立されたＰＰＰリンクによって、ＰＰＰゲートウェイ装置１０に接続される。本実施例では、各アクセス回線Ｌａはイーサネットであり、各クライアント端末２０とＰＰＰゲートウェイ装置１０は、ＰＰＰｏＥヘッダとＰＰＰヘッダをもつイーサネットフレーム形式で通信するものと仮定する。

ＰＰＰゲートウェイ装置１０は、ＰＰＰｏＥを適用して、同一の物理回線上に複数のＰＰＰリンクを設定できる。図１では、各物理回線（アクセス回線）Ｌａに１つのクライアント端末２０が接続されているが、同一の物理回線上に論理的な複数のＰＰＰリンクを設定することによって、ＰＰＰゲートウェイ装置１０には、１つのアクセス回線Ｌａで複数のＰＰＰクライアント端末２０を収容できる。

ＰＰＰゲートウェイ装置１０は、後述するフレーム処理プロセッサ（Intelligent Switching機能）によって、各アクセス回線のＰＰＰリンクからの受信フレームをデカプセル化し、受信フレームをＬ２ＳＷ３０との通信に適合したイーサネットフレーム形式に変換した上で、適切なコア回線Ｌｃ（イーサネットリンク）に転送する。逆に、コア回線Ｌｃ（イーサネットリンク）からイーサネットフレームを受信すると、受信フレームから抽出したＩＰパケットをＰＰＰｏＥヘッダ、ＰＰＰヘッダでカプセル化し、クライアント端末との通信に適合したイーサネットフレーム形式に変換した上で、適切なＰＰＰリンクに転送する。

ＰＰＰゲートウェイ装置１０は、ＰＰＰ接続要求の発行元となったクライアント端末２０について、ユーザ認証と課金を行うＲＡＤＩＵＳサーバ４０と接続されている。ＰＰＰゲートウェイ装置１０は、ＲＡＤＩＵＳサーバ４０から、クライアント端末２０とのＰＰＰ接続の可否を示す判定結果と共に、クライアント端末に与える各種の権限情報を入手できる。但し、ＰＰＰゲートウェイ装置１０にとって、ＲＡＤＩＵＳサーバ４０との接続は必須の要件ではない。ＰＰＰゲートウェイ装置１０自身が、クライアントの認証に必要な情報を保持してもよい。クライアント端末２０に付与すべきＩＰアドレスは、ユーザ認証の際に、上記ＲＡＤＩＵＳサーバ４０から入手することも可能であるが、一般的なレイヤ２ネットワークでは、ＩＰアドレスはＤＨＣＰサーバ５０から取得する。

図１のネットワーク構成では、各クライアント端末２０が、レイヤ２のＰＰＰでＰＰＰゲートウェイ装置１０と接続されているため、クライアント端末２０からＤＨＣＰサーバ５０を直接アクセスすることができない。そこで、本実施例では、ＰＰＰゲートウェイ装置１０が、ＤＨＣＰクライアント機能を備え、クライアント端末２０に代わって、コア回線上のレイヤ２のイーサネットリンクを介してＤＨＣＰサーバ５０をアクセスし、クライアント端末に付与すべきＩＰアドレスを取得する。

図２は、図１のネットワークにおけるクライアント端末２０、ＰＰＰゲートウェイ装置（ＰＰＰ ＧＷ）１０、Ｌ２ＳＷ３０、サーバ６０のプロトコルスタックを示す。
クライアント端末２０は、インターネットＮＷに接続されたサーバ６０とＩＰによるアプリケーション間通信を行うために、ＰＰＰゲートウェイ装置１０との間にＰＰＰリンクを確立する。本実施例では、ＰＰＰリンクが、イーサネットアクセス回線Ｌａ上に確立されると仮定しているため、クライアント端末２０のプロトコルスタックでは、イーサネットを最下層として、その上にＰＰＰｏＥとＰＰＰが位置し、ＰＰＰの上位スタックとして、ＩＰとアプリケーションが位置している。

ＰＰＰゲートウェイ装置１０は、クライアント端末２０からイーサネットフレームを受信すると、イーサネットからＰＰＰまでのヘッダ処理を行う。本発明のＰＰＰゲートウェイ装置１０は、Ｌ２ＳＷ３０と通信するためのプロトコルスタックとして、イーサネットのみを備えており、ゲートウェイでありながら、そのプロトコルスタックにＩＰが存在していない。

Ｌ２ＳＷ３０は、イーサネットスイッチとして動作し、イーサネットフレーム形式で、次ノードにフレームを転送する。インターネットＮＷ上のサーバ６０は、クライアント端末２０とアプリケーション間通信を行うため、イーサネットを下位スタックとしたＩＰ通信機能を備える。

図３は、本発明のＰＰＰゲートウェイ装置１０を経由したクライアント端末２０とインターネットＮＷとの接続シーケンスを示す。
クライアント端末２０は、一般的なＰＰＰｏＥプロトコルに従って、ＰＰＰゲートウェイ装置１０との間でＰＰＰｏＥセッションの接続手順を実行する（ＳＱ１）。ＰＰＰｏＥセッションの接続時に、クライアント端末２０は、自分のＭＡＣアドレスをイーサネットフレームの送信元ＭＡＣアドレスに適用しているため、ＰＰＰゲートウェイ装置１０は、ＰＰＰｏＥセッション接続中に、クライアント端末２０のＭＡＣアドレスを学習できる（ＳＱ２）。

ＰＰＰｏＥセッションを確立すると、クライアント端末２０は、ＰＰＰゲートウェイ装置１０との間で、ＰＰＰにおけるＬＣＰ（Link layer Control Protocol）のネゴシエーションを行って、ＰＰＰリンクを確立する（ＳＱ３）。ＰＰＰリンクが確立されると、ＰＰＰゲートウェイ装置１０２は、ライアント端末２０の接続認証を行う。ここでは、クライアント端末２０側からＰＰＰゲートウェイ装置１０に、ユーザ認証情報（ユーザ識別子、パスワードなど）を含んだ認証要求を送信（ＳＱ４）した場合を示している。

上記認証要求を受信すると、ＰＰＰゲートウェイ装置１０は、ＲＡＤＩＵＳサーバ４０に対して、ユーザ認証情報を含むＲＡＤＩＵＳプロトコルに従った認証要求（Access-Request）を送信する（ＳＱ５）。ＰＰＰゲートウェイ装置１０から認証要求を受信したＲＡＤＩＵＳサーバ４０は、上記認証要求が示すユーザ認証情報と、予め登録されているユーザ認証情報とを照合してユーザ認証を行い、認証結果をＰＰＰゲートウェイ装置１０に通知する（ＳＱ６）。

ユーザ認証に成功した場合、ＲＡＤＩＵＳサーバ４０は、認証結果通知（Access Accept）に記述されるＲＡＤＩＵＳアトリビュートによって、要求元クライアント端末２０に付与すべき各種の権限をＰＰＰゲートウェイ装置１０に通知できる。また、Framed-IP-Addressアトリビュートによって、クライアント２０で使用すべきＩＰアドレスを通知することもできる。本実施例では、上記認証結果通知（Access Accept）に、クライアントからの受信フレームの転送先ドメインを示すアトリビュートを定義し、ＰＰＰゲートウェイ装置１０が、上記転送先ドメインに従って、クライアント端末２０からの受信フレームを適切なＬ２ＳＷ３０に転送制御できるようにする。

ＰＰＰゲートウェイ装置１０は、ＲＡＤＩＵＳサーバ４０からユーザ認証成功の通知を受信すると、要求元クライアント端末２０からの受信フレームの転送先となるコア回線側リンクを決定し、後述するＰＰＰユーザ管理テーブルに新たなエントリを登録する（ＳＱ７）。この後、ＰＰＰゲートウェイ装置１０は、要求元クライアント２０に対して、ＰＰＰプロトコルにおける認証結果（認証成功）を通知する（ＳＱ８）。クライアント端末２０が上記認証成功通知を受信することによって、ユーザ認証手順が完了する。

ユーザ認証に成功したクライアント端末２０は、ＰＰＰリンクレイヤ上にＩＰレイヤを確立するため、ＰＰＰゲートウェイ装置１０に対して、PPP IPCP Configuration-Requestを送信する（ＳＱ９）。通常の場合、PPP IPCP Configuration-Requestでは、リクエスト送信元装置が自分のＩＰアドレスを相手装置に通知しているが、本実施例では、ＰＰＰゲートウェイ装置１０からクライアント端末２０にＩＰアドレスを付与するようにしているため、ＰＰＰゲートウェイ装置１０は、上記PPP IPCP Configuration-Requestの受信を契機として、クライアント端末２０に付与すべきＩＰアドレスの取得手順を開始する。

前述したＲＡＤＩＵＳサーバ４０からの認証結果通知（Access Accept）でＩＰアドレスが付与されている場合、ＰＰＰゲートウェイ装置１０は、上記認証結果通知が示すＩＰアドレスをPPP IPCP Configuration-nak（ＳＱ１２）によって、要求元クライアント端末２０に通知すればよい。ここでは、ＩＰアドレスをＲＡＤＩＵＳサーバ４０からではなく、レイヤ２ネットワークで運用されるＤＨＣＰサーバ５０から取得する場合について説明する。

ＤＨＣＰサーバ５０は、端末ＭＡＣアドレスでＤＨＣＰクライアントを識別している。そこで、ＰＰＰゲートウェイ装置１０は、ＰＰＰｏＥ接続中に学習しておいたクライアント端末２０のＭＡＣアドレスを送信元ＭＡＣアドレスに適用して、ＤＨＣＰサーバ５０にアドレス要求を送信する（ＳＱ１０）。上記アドレス要求は、ＳＱ７で決定したコア回線側リンク（レイヤ２イーサネットリンク）に送信される。ＰＰＰゲートウェイ装置１０は、ＤＨＣＰサーバ５０からのアドレス通知（ＳＱ１１）によって、クライアント端末２０のＩＰアドレスを取得すると、このＩＰアドレスをPPP IPCP Configuration-nak（ＳＱ１２）によって、要求元クライアント端末２０に通知する。

PPP IPCP Configuration-nakによって、使用すべきＩＰアドレスを通知されたクライアント端末２０は、このＩＰアドレスを送信元ＩＰアドレスとして、ＰＰＰゲートウェイ装置１０に再度PPP IPCP Configuration-Requestを送信する。このとき、ＰＰＰゲートウェイ装置１０も、ゲートウェイＩＰアドレスを送信元ＩＰアドレスとするPPP IPCP Configuration-Requestでクライアント端末２０に送信する（ＳＱ１３）。ＰＰＰゲートウェイ装置１０とクライアント端末２０の双方が、互いに相手装置から受信したPPP IPCP Configuration-Requestに対する応答メッセージPPP IPCP Configuration-ackを送信することによって（ＳＱ１４）、ＩＰＣＰネゴシエーションが完了する。

ＩＰＣＰネゴシエーションが完了した時、ＰＰＰゲートウェイ装置１０は、クライアント端末２０とインターネットＮＷとの通信を可能とするため、クライアント端末２０からの受信フレームの転送に使用するコア回線Ｌｃ上のリンク（レイヤ２イーサネットリンク）を決定し、フレーム転送制御テーブルに転送制御情報として設定する（ＳＱ１５）。これにより、図２に示したプロトコルスタックによるＬａｙｅｒ２フレームの通信（ＳＱ１６）が可能となる。

ＤＨＣＰサーバ５０は、各ユーザ端末に付与したＩＰアドレスに生存時間を割り当て、生存時間切れとなったＩＰアドレスは自動的に無効にするアドレス管理を行っている。従って、ＩＰアドレスを付与された端末は、アドレスの生存時間が尽きる前に、ＤＨＣＰサーバ５０にアドレスリース期間の延長を申請する必要がある。本実施例では、クライアント端末２０に代わって、ＰＰＰゲートウェイ装置１０が、ＤＨＣＰサーバ５０にＩＰアドレスの割当てを要求しているため、クライアント端末２０のＰＰＰリンクが存続している間は、ＰＰＰゲートウェイ装置１０からＤＨＣＰサーバ５０に、一定の時間間隔でＩＰアドレスのリース延長を要求する（ＳＱ１７）。

クライアント端末２０は、インターネットＮＷとの通信を終了する時、ＰＰＰゲートウェイ装置１０にリンク切断要求メッセージPPP LCP Terminate-Requestを送信する（ＳＱ１８）。ＰＰＰゲートウェイ装置１０は、上記PPP LCP Terminate-Requestを受信すると、ＤＨＣＰサーバ５０に、クライアント端末２０に付与されたＩＰアドレスの解放を要求（ＳＱ１９）した後、クライアント端末２０に対して、リンク切断要求に対する応答メッセージPPP LCP Terminate-ackを送信して（ＳＱ２０）、ＰＰＰリンクを解放する。この後、ＰＰＰゲートウェイ装置１０は、ＰＰＰｏＥセッションを切断し（ＳＱ２１）、クライアント端末２０との通信を完了する。

図４は、ＰＰＰゲートウェイ装置１０のハードウェア構成の１例を示す。
ＰＰＰゲートウェイ装置１０は、複数の回線インタフェース１１（１１−１〜１１−ｎ）と、これらの回線インタフェースに内部バス１２で接続されたフレーム処理プロセッサ１３と、フレーム処理プロセッサ１３に内部バス１７で接続されたＣＰＵ１４、メモリ１５およびＩ／Ｏ部１６からなる。メモリ１５には、図５で後述するように、フレーム処理プロセッサ１３とＣＰＵ１４で実行される各種のソフトウェアが格納され、フレーム転送制御に必要な各種のテーブルが形成される。

回線インタフェース１１（１１−１〜１１−ｎ）は、図１に示したアクセス回線Ｌａ（Ｌａ−１〜Ｌａ−ｍ）、コア回線Ｌｃ（Ｌｃ−１、Ｌｃ−２）、ＲＡＤＩＵＳサーバ４０との接続回線の何れかに接続されている。回線インタフェース１１がこれらの物理回線から受信したフレームは、内部バス１２を介して、フレーム処理プロセッサ１３に読み込まれる。

フレーム処理プロセッサ１３は、受信フレームの種類を判定し、受信フレームが、図３で説明したＰＰＰｏＥ、ＰＰＰ、ＤＨＣＰの制御メッセージの場合は、これをＣＰＵ１４に渡す。受信フレームが、クライアント端末２０またはＬ２ＳＷ３０にフォワーディングすべきユーザパケットフレーム、すなわち、ＰＰＰリンクとレイヤ２イーサネットリンクとの間の転送条件に合致するフレームの場合、フレーム処理プロセッサ１３は、ＣＰＵ１４が予めフレーム転送制御テーブルに定義したスイッチング条件に従って、受信フレームのヘッダ変換を実行し、適切な回線インタフェース１１から物理回線に送信する。ＣＰＵ１４が生成したＰＰＰｏＥ、ＰＰＰ、ＤＨＣＰの制御メッセージは、フレーム処理プロセッサ１３を介して、所定の回線インタフェース１１に出力される。

図５は、ＰＰＰゲートウェイ装置１０のソフトウェア構成の１例を示す。ここでは、ＣＰＵ１４が実行するソフトウェア（プログラム）と、フレーム処理プロセッサ１３が実行するソフトウェアを総合的に図示してある。また、プログラム以外に、ＣＰＵ１４によって管理され、その一部がフレーム処理プロセッサ１３によって参照されるテーブルが破線で示してある。

ＣＰＵ１４で実行されるＯＳ１００の上に、フレーム処理プロセッサ１３との通信を制御するためのネットワーク処理ルーチン１０１がある。ネットワーク処理ルーチン１０１の上位には、各種のプロトコルアプリケーションが用意されている。ここでは、プロトコルアプリケーションとして、ＰＰＰプロトコルを制御するＰＰＰ制御モジュール１０２、ＲＡＤＩＵＳサーバ４０と交信するためのＲＡＤＩＵＳ（クライアント）モジュール１０３は、ＤＨＣＰサーバ５０と交信するためのＤＨＣＰ（クライアント）モジュール１０４と、保守インタフェースモジュール１０６が示してある。保守インタフェースモジュール１０６は、Ｉ／Ｏ部１６におけるコマンドラインインタフェース、あるいはＳＮＭＰなどの保守通信をサポートするものである。
これらのプロトコルモジュール間の連携は、セッション制御モジュール１０５によって制御されている。セッション制御モジュール１０５は、各クライアント端末２０の接続状態を管理するＰＰＰユーザ管理テーブル２５０、ドメイン情報テーブル２６０、フレーム転送制御テーブル２７０のテーブルエントリを管理する。

フレーム処理ルーチン２００は、フレーム処理プロセッサ１３によって実行される。フレーム処理ルーチン２００は、後述するように、フレーム転送制御テーブル２７０に定義されたスイッチング条件（フレーム転送制御情報）に従って、アクセス回線上のＰＰＰリンクと、コア回線上のレイヤ２イーサネットリンクとの間のフレーム変換を行う。

保守インタフェースモジュール１０６の上位には、保守制御モジュール１０８が用意されている。保守制御モジュール１０８は、保守インタフェースモジュール１０６、装置管理部モジュール１０７、その他の機能部への保守用パラメータの設定、これらのモジュールからの保守情報の収集、ＰＰＰゲートウェイ装置１０内で発生した各種イベントの外部管理システムへの通知などの制御動作を行う。

図６は、クライアント端末２０の接続状態を管理するためのＰＰＰユーザ管理テーブル２５０を示す。
ＰＰＰユーザ管理テーブル２５０は、アクセス回線Ｌａ上に設定されたＰＰＰリンクと対応する複数のテーブルエントリからなる。各テーブルエントリは、セッション番号２５１、アクセスインタフェース（ＩＮＦ）番号２５２、クライアントＭＡＣアドレス２５３、クライアントＩＰアドレス２５４、ＤＨＣＰ状態２５５、ドメイン名２５６を示している。

セッション番号２５１は、アクセス回線Ｌａ上に設定されたＰＰＰリンクの識別番号であり、ＰＰＰｏＥを使用する場合は、ＰＰＰｏＥセッション番号であってもよい。ＰＰＰゲートウェイ１０に接続された全てのリンクを識別できるように、ＰＰＰリンクにはユニークなセッション番号が付与される。

アクセスＩＮＦ番号２５２は、ＰＰＰリンクを収容するインタフェース番号であり、「物理リンク番号＋論理リンク番号」のように階層化して表現される。ここで、物理リンク番号は、ＰＰＰリンクが形成されたアクセス回線Ｌａの番号であり、この物理リンク番号によって回線インタフェース１２が特定される。論理リンク番号は、アクセス回線Ｌａに多重化されたレイヤ２リンクの識別番号、イーサネットの場合は、ＶＬＡＮタグ番号を示す。

例えば、図６に示した第２テーブルエントリのアクセスＩＮＦ番号「２．１」は、セッション番号２５１＝「２」のＰＰＰリンクが、物理リンク番号＝２の回線インタフェースに、論理リンク番号＝１の論理リンクで接続されていることを意味している。但し、各アクセス回線にＰＰＰリンクが１つずつ形成される場合、論理リンク番号は不要となる。

クライアントＭＡＣアドレス２５３は、ＰＰＰｏＥ手順で学習（ＳＱ２）されたクライアント端末２０のＭＡＣアドレスを示す。クライアント端末２０は、このＭＡＣアドレス２５３を送信元ＭＡＣアドレスに適用したイーサネットフレームによって、Ｌ２ＳＷ３０にパケットを送信する。クライアントＩＰアドレス２５４は、クライアント端末２０に割り当てられたＩＰアドレスを示し、ＤＨＣＰ状態２５５は、上記ＰＰＰリンクにおけるＤＨＣＰサーバ５０からのＩＰアドレスの取得状態を示している。ドメイン名２５６は、ＲＡＤＩＵＳサーバ４０からの認証結果（ＳＱ６）によって通知されたクライアント端末２０の所属ドメインの識別情報である。

図７は、ドメイン情報テーブル２６０を示す。
ドメイン情報テーブル２６０は、ドメイン名２６１と、コアインタフェース（ＩＮＦ）番号２６２と、ＤＨＣＰサーバのＩＰアドレス２６３と、Ｌ２ＳＷのＭＡＣアドレス２６４との対応関係を示す複数のテーブルエントリからなる。ＰＰＰゲートウェイ装置１０のフレーム処理プロセッサ１３は、このドメイン情報テーブル２６０を参照することによって、ＰＰＰリンクの接続先となるコア回線側レイヤ２のイーサネットリンク、ＤＨＣＰサーバ、Ｌ２ＳＷを決定できる。

ドメイン名２６１は、ＰＰＰユーザ管理テーブル２５０に登録されたドメイン名２５６と対応している。コアＩＮＦ番号２６２は、ドメイン名２６１に対応するコア回線Ｌｃ側のインタフェース番号を示しており、「物理リンク番号＋論理リンク番号」のように階層化されている。

ＤＨＣＰサーバＩＰアドレス２６３は、各ドメインに属しているＤＨＣＰサーバ５０のＩＰアドレスを示す。図７では、ドメイン名２６１＝「Ｂ」をもつ第２テーブルエントリで、コアＩＮＦ番号２６２が「４．１」、ＤＨＣＰサーバＩＰアドレス２６３が「H.H.H.H」、Ｌ２ＳＷのＭＡＣアドレス２６４が「mac-B」となっている。これは、図６に示したＰＰＰユーザ管理テーブル２５０におけるセッション番号２５１＝「２」のＰＰＰリンク（クライアント端末）が、コア回線Ｌｃ側の物理リンク番号＝４、論理リンク番号＝１のイーサネットリンクを介して、ＭＡＣアドレス「mac-B」のＬ２ＳＷに接続されること、クライアント端末には、ＩＰアドレス「H.H.H.H」を持つＤＨＣＰサーバ５０からＩＰアドレスが付与されることを示している。

図６に示したＰＰＰユーザ管理テーブル２５０では、セッション番号２５１＝「３」をもつ第３テーブルエントリのドメイン名２５６も「Ｂ」となっている。従って、コア回線Ｌｃ側の物理リンク番号＝４、論理リンク番号＝１のイーサネットリンクには、アクセス回線側のセッション番号が「２」、「３」の２つのＰＰＰリンクの送信フレームが、多重化して送出されることになる。

図８は、フレーム転送制御テーブル２７０を示す。
フレーム転送制御テーブル２７０は、フレーム処理プロセッサ１３が実行するイーサネットフレーム転送におけるスイッチング条件を定義したものであり、アクセス回線Ｌａ側のＰＰＰリンクと、コア回線Ｌｃ側のレイヤ２イーサネットリンクとを対応づける複数のテーブルエントリからなっている。フレーム転送制御テーブル２７０は、ＣＰＵ１４（セッション制御モジュール１０５）が、ＰＰＰユーザ管理テーブル２５０とドメイン情報テーブル２６０に基いて生成する。

フレーム転送制御テーブル２７０の各テーブルエントリは、アクセス回線Ｌａ側に確立されたＰＰＰリンクのアクセスＩＮＦ番号２７１およびセッション番号２７２と、クライアントＭＡＣアドレス２７３と、コアＩＮＦ番号２７４と、Ｌ２ＳＷのＭＡＣアドレス２７５と、リンク状態２７６との対応関係を示している。

アクセスＩＮＦ番号２７１、セッション番号２７２、クライアントＭＡＣアドレス２７３は、それぞれＰＰＰユーザ管理テーブル２５０のアクセスＩＮＦ番号２５２、セッション番号２５１、クライアントＭＡＣアドレス２５３と同一であり、コアＩＮＦ番号２７４は、ドメイン情報テーブル２６０のコアＩＮＦ番号２６２と同一である。リンク状態２７６は、ＰＰＰリンクの確立が完了したか否かを示している。リンク状態２７６が、ＰＰＰリンク確立状態となったとき、テーブルエントリで定義されたスイッチング条件が有効となる。例えば、セッション番号＝「２」のテーブルエントリのように、リンク状態２７６がＰＰＰリンク未確立の状態を示している場合、このテーブルエントリで定義されたスイッチング条件は無効であり、フレーム転送制御には適用されない。

フレーム処理プロセッサ１３は、図１０で詳述するフレーム処理ルーチン２００を実行し、上記フレーム転送制御テーブル２７０が示すスイッチング条件に従って、各アクセス回線Ｌａおよびコア回線Ｌｃからの受信フレームのヘッダ変換と転送制御を行う。
例えば、ＰＰＰゲートウェイ装置１０が、アクセスＩＮＦ番号＝「２．２」に該当する回線インタフェース１１−２から、セッション番号＝「３」のＰＰＰフレームを受信したと仮定する。この場合、フレーム処理プロセッサ１３は、フレーム転送制御テーブル２７０から、上記セッション番号に該当する第３テーブルエントリを検索する。フレーム処理プロセッサ１３は受信フレームからＰＰＰｏＥヘッダとＰＰＰヘッダを除去した後、上記テーブルエントリが示す定義内容に従って、受信フレームのイーサネットヘッダの宛先ＭＡＣアドレスをＬ２ＳＷのＭＡＣアドレス「mac-B」に変換し、ＶＬＡＮタグにコアＩＮＦ番号２７４が示す論理リンク番号「１」を設定する。このフレームは、コアＩＮＦ番号２７４の物理リンク番号「４」で特定されるコア回線インタフェース１１−４から送出される。

また、例えば、コアＩＮＦ番号「３」に該当する回線インタフェース１１−３から、宛先ＭＡＣアドレスが「mac-1」のイーサネットフレームを受信した場合、フレーム処理プロセッサ１３は、フレーム転送制御テーブル２７０から、クライアントＭＡＣアドレス２７３が宛先ＭＡＣアドレス「mac-1」に該当する第１テーブルエントリを検索し、該テーブルエントリが示す定義内容に従って、受信フレームをＰＰＰフレームに変換する。この場合、イーサネットヘッダとＩＰパケットとの間に、セッション番号「１」をもつＰＰＰｏＥヘッダとＰＰＰヘッダが付加され、イーサネットヘッダの送信元ＭＡＣアドレスがＰＰＰゲートウェイ装置１０のＭＡＣアドレスに書き替えられる。ＰＰＰフレームは、アクセスＩＦ番号「１」をもつ回線インタフェース１１−１からクライアント端末２０に送信される。

図９は、ＰＰＰゲートウェイ装置１０のＣＰＵ１４が実行するリンク確立処理のフローチャートを示す。
ＰＰＰゲートウェイ装置１０のＣＰＵ１４は、クライアント端末２０からの要求に応答して、クライアント端末２０との間でＰＰＰｏＥセッションの確立手順（３０１）を実行する。この時、クライアント端末のＭＡＣアドレスが学習される。これが終わると、ＣＰＵ１４は、クライアント端末２０との間でＰＰＰ ＬＣＰネゴシエーションを行って、ＬＣＰレイヤを確立し（３０２）、その後、ＰＰＰによるユーザ認証手順（３０３）を実行する。ユーザ認証には、ＰＰＰゲートウェイ装置１０が保持するクライアント毎の認証情報を使用する方法と、ＲＡＤＩＵＳサーバ４０と連携する方法の何れであってもよい。

上記ユーザ認証によって、クライアント端末２０が所属するドメイン名、Ｌ２ＳＷのＭＡＣアドレス、ＤＨＣＰサーバアドレスなどのコア回線リンク情報が特定される（３０４）。ＣＰＵ１４は、クライアント端末２０へのＩＰアドレスの付与方法を判定し（３０５）、ＩＰアドレスをＤＨＣＰサーバ５０から取得する場合は、上記ユーザ認証で特定されたＤＨＣＰサーバ４０にＩＰアドレス通知を要求する（３０７）。ＤＨＣＰサーバ４０を利用しない場合は、ＣＰＵ１４は、ＰＰＰゲートウェイ装置１０内に用意されたＩＰアドレスプールから空きアドレスを取得する（３０６）。

クライアント端末に付与すべきＩＰアドレスが決定すると、ＣＰＵ１４は、クライアント端末２０との間で、ＰＰＰにおけるＩＰＣＰネゴシエーションを実行して、ＩＰレイヤを確立する（３０８）。その後、前述したＰＰＰユーザ管理テーブル２５０、ドメイン情報テーブル２６０、フレーム転送制御テーブル２７０に新たなテーブルエントリを登録する（３０９）ことによって、クライアント端末とＬ２ＳＷ３０との間でのデータフレームのフォワーディングが可能な状態にする。

図１０は、ＰＰＰゲートウェイ装置１０のフレーム処理プロセッサ１３が実行するフレーム処理ルーチン２００のフローチャートを示す。
フレーム処理プロセッサ１３は、回線インタフェース１１（１１−１〜１１−ｎ）を巡回的にアクセスし、各回線インタフェースから受け取った受信フレームをフレーム処理ルーチン２００に従って処理する。

フレーム処理プロセッサ１３は、受信フレームのメッセージ種別から、受信フレームが、図３で説明したＰＰＰｏＥ、ＰＰＰ等における制御メッセージを含むものか否かを判定する（２０１）。受信フレームが制御メッセージを含む場合は、これをＣＰＵ１４に転送して（２３０）、このルーチンを終了する。受信フレームが制御メッセージ用でなかった場合、フレーム処理プロセッサ１３は、例えば、各回線インタフェース番号と接続先種別との関係を示す回線管理テーブルを参照することによって、受信フレームがアクセス回線Ｌａからの受信メッセージか、コア回線からの受信フレームかを判定する（２０２）。

受信フレームがアクセス回線Ｌａ−ｊからの受信メッセージの場合、受信フレームは、図１１（Ａ）に示すように、イーサネットヘッダＨ１０、ＰＰＰｏＥヘッダＨ２０、ＰＰＰヘッダＨ３０、ＩＰヘッダＨ４０、ＩＰペイロードＤからなり、イーサネットヘッダＨ１０に、宛先ＭＡＣアドレスＤＡ、送信元ＭＡＣアドレスＳＡ、その他の情報を含む。宛先ＭＡＣアドレスＤＡには、ＰＰＰゲートウェイ装置１０のＭＡＣアドレス、送信元ＭＡＣアドレスＳＡには、クライアント端末２０のＭＡＣアドレスが設定されている。

この場合、フレーム処理プロセッサ１３は、受信フレームのＰＰＰｏＥヘッダＨ２０からセッション番号を抽出し、フレーム転送制御テーブル２７０から、受信メッセージのセッション番号に該当するテーブルエントリを検索し、リンク状態２７６からセッションが既に確立済みか否かを判定する（２１０）。

フレーム転送制御テーブル２７０に、受信メッセージのセッション番号に該当するテーブルエントリが未登録の場合、あるいは、該当するテーブルエントリのリンク状態２７６がセッション未確立の状態を示していた場合、フレーム処理プロセッサ１３は、フレームを廃棄して（２４０）、このルーチンを終了する。

フレーム転送制御テーブル２７０から、受信メッセージのセッション番号に該当する有効なテーブルエントリが見つかった場合、フレーム処理プロセッサ１３は、受信フレームからイーサネットヘッダＨ１０、ＰＰＰｏＥヘッダＨ２０、ＰＰＰヘッダＨ３０を除去し（２１１）、フレーム転送制御テーブルから検索されたテーブルエントリの内容に従って新たなイーサネットヘッダを作成して、コア側回線インタフェースから送信すべきレイヤ２イーサネットリンク用のフレームを生成する（２１２）。

レイヤ２イーサネットリンク用のフレームは、例えば、図１１の（Ｂ）に示すように、受信フレームから抽出されたＩＰパケット部（ＩＰヘッダＨ４０とＩＰペイロードＤ）と、新たなイーサネットヘッダＨ１０とからなり、イーサネットヘッダＨ１０は、宛先ＭＡＣアドレスＤＡとしてＬ２ＳＷのＭＡＣアドレス、送信元ＭＡＣアドレスＳＡとしてクライアント端末２０のＭＡＣアドレスを含み、ＶＬＡＮタグとしてコア回線上の論理リンク番号を含む。ここで、Ｌ２ＳＷのＭＡＣアドレスには、検索されたテーブルエントリのＬ２ＳＷ ＭＡＣアドレス２７５が適用され、ＶＬＡＮタグには、上記テーブルエントリのコアＩＮＦ番号２７４が示す論理リンク番号が適用される。

フレーム処理プロセッサ１３は、上記フレームを上記テーブルエントリのコアＩＮＦ番号２７４が示す物理リンク番号ｋと対応した回線インタフェース１１−ｋに転送し（２１３）、このルーチンを終了する。

ステップ２０２で、受信フレームがコア回線Ｌｃ−ｊからのものと判定された場合、受信フレームは、図１２の（Ａ）に示すように、イーサネットヘッダＨ１０、ＩＰヘッダＨ４０、ＩＰペイロードＤからなり、イーサネットヘッダＨ１０の宛先ＭＡＣアドレスＤＡは、クライアント端末２０のＭＡＣアドレス、送信元ＭＡＣアドレスＳＡは、Ｌ２ＳＷのＭＡＣアドレス、ＶＬＡＮタグは、コア回線上の論理リンク番号を示している。
この場合、フレーム処理プロセッサ１３は、フレーム転送制御テーブル２７０から、クライアントＭＡＣアドレス２７３が受信フレームの宛先ＭＡＣアドレスＤＡと一致するテーブルエントリを検索し、アクセスＩＮＦ番号２７１とセッション番号２７２の値を特定する。

通常、Ｌ２ＳＷを適用したネットワークでは、学習済みのＭＡＣアドレスを管理テーブルから検索できなかった場合、Floodingが行われるが、本実施例のＰＰＰゲートウェイ装置１０では、Ｌ２ＳＷに接続されるクライアント端末は、そのＭＡＣアドレスがフレーム転送制御テーブル２７０に既に登録済みとなっていることを前提としているため、フレーム転送制御テーブル２７０に、受信メッセージの宛先ＭＡＣアドレスＤＡに該当するテーブルエントリが未登録の場合、フレーム処理プロセッサ１３は、受信フレームを廃棄して（２４０）、このルーチンを終了する。

フレーム転送制御テーブル２７０から、宛先ＭＡＣアドレスに該当するテーブルエントリが見つかった場合、フレーム処理プロセッサ１３は、検索されたテーブルエントリが示すセッション番号２７２を適用して、ＰＰＰｏＥヘッダＨ２０とＰＰＰヘッダＨ３０を生成し、これを受信フレームのＩＰパケットに付加する（２２１）。フレーム処理プロセッサ１３は、更に、宛先ＭＡＣアドレスとしてクライアント端末２０のＭＡＣアドレス、送信元ＭＡＣアドレスＳＡとしてＰＰＰゲートウェイ装置１０のＭＡＣアドレスを含む新たなイーサネットヘッダを作成する。フレーム処理プロセッサ１３は、このイーサネットヘッダをＰＰＰｏＥパケットに付加し、図１２の（Ｂ）に示すＰＰＰリンク用のフレームを生成して（２２２）、該フレームを上記検索エントリのアクセスＩＮＦ番号２７１が示す物理リンク番号と対応した回線インタフェースから送信して（２２３）、このルーチンを終了する。

以上の実施例によれば、ＰＰＰゲートウェイ装置１０が、クライアント端末との間にＰＰＰリンクを確立する過程で、フレーム転送制御テーブルにセッション番号と対応した新たなスイッチング条件を自動的に設定することができ、このフレーム転送制御テーブルを参照することによって、アクセス回線側のＰＰＰフレームと、コア回線側のレイヤ２イーサネットフレームとの相互変換を行うことができるため、ＰＰＰクライアント端末とレイヤ２のイーサネットリンクとの接続が可能となる。

本発明によるＰＰＰゲートウェイ装置１０が適用されるネットワークの概要を示す図。 クライアント端末２０とインターネット（サーバ６０）間のプロトコルスタックを示す図。 クライアント端末２０とインターネットＮＷとの接続シーケンスを示す図。 本発明によるＰＰＰゲートウェイ装置１０のハードウェア構成の１例を示す図。 ＰＰＰゲートウェイ装置１０のソフトウェア構成の１例を示す図。 ＰＰＰゲートウェイ装置１０が備えるＰＰＰユーザ管理テーブル２５０を示す図。 ＰＰＰゲートウェイ装置１０が備えるドメイン情報テーブル２６０を示す図。 ＰＰＰゲートウェイ装置１０が備えるフレーム転送制御テーブル２７０を示す図。 ＰＰＰゲートウェイ装置１０が実行するリンク確立処理のフローチャート。 ＰＰＰゲートウェイ装置１０が実行するフレーム処理のフローチャート。 ＰＰＰフレームからイーサネットフレームへの変換を示す図。 イーサネットフレームからＰＰＰフレームへの変換を示す図。

符号の説明

ＮＷ：インターネット、１０：ＰＰＰゲートウェイ装置、１１：回線インタフェース、
１３：フレーム処理プロセッサ、１４：ＣＰＵ、１５：メモリ、１６：Ｉ／Ｏ部、
２０：クライアント端末、３０：Ｌ２ＳＷ、４０：ＲＡＤＩＵＳサーバ、５０：ＤＨＣＰサーバ、６０：アプリケーションサーバ、
１００：ＯＳ、１０１：ネットワーク処理ルーチン、１０２：ＰＰＰ制御モジュール、
１０３：ＲＡＤＩＵＳ（クライアント）モジュール、１０４：ＤＨＣＰ（クライアント）モジュール、１０５：セッション制御モジュール、１０６：保守インタフェースモジュール、１０７：装置管理部モジュール、１０８：保守制御モジュール、２００：フレーム処理ルーチン、２５０：ＰＰＰユーザ管理テーブル、２６０：ドメイン情報テーブル、２７０：フレーム転送制御テーブル。

Claims (8)

1. 複数のＰＰＰ（Point to Point Protocol）クライアント端末とレイヤ２フレーム転送装置とを接続するＰＰＰゲートウェイ装置であって、
   クライアント端末と接続されるアクセス回線またはレイヤ２フレーム転送装置と接続されるコア回線の何れかを収容する複数の回線インタフェースと、
   それぞれがＰＰＰセッション番号と、クライアントＭＡＣアドレスと、コア回線側のフレーム定義情報との対応関係を示す複数のテーブルエントリからなるフレーム転送制御テーブルと、
   上記各クライアント端末とレイヤ２フレーム転送装置との間の通信フレームの転送を制御するフレーム処理部とを備え、
   上記フレーム処理部が、上記フレーム転送制御テーブルに基いて、各アクセス回線から受信したＰＰＰフレームをレイヤ２イーサネットフレームに変換した後、何れかのコア回線に転送し、各コア回線から受信した特定クライアントのＭＡＣアドレス宛フレームをＰＰＰフレームに変換した後、何れかのアクセス回線に転送することを特徴とするＰＰＰゲートウェイ装置。
2. 前記フレーム転送制御テーブルの各テーブルエントリが、アクセス回線インタフェース番号を含み、
   前記フレーム処理部が、コア回線からの受信フレームを処理するとき、上記フレーム転送制御テーブルから、クライアントＭＡＣアドレスが上記受信フレームの宛先ＭＡＣアドレスと一致するテーブルエントリを検索し、該テーブルエントリが示すセッション番号に従って受信フレームをＰＰＰフレームに変換し、これを上記テーブルエントリが示すアクセス回線インタフェース番号で特定された回線インタフェースから送信することを特徴とする請求項１に記載のＰＰＰゲートウェイ装置。
3. 前記フレーム転送制御テーブルの各テーブルエントリが、コア回線側のフレーム定義情報として、コア回線インタフェース番号と、フレーム転送装置ＭＡＣアドレスを含み、
   前記フレーム処理部が、アクセス回線からの受信フレームを処理するとき、上記フレーム転送制御テーブルから、セッション番号が上記受信フレームから抽出されたＰＰＰセッション番号と一致するテーブルエントリを検索し、該テーブルエントリが示すフレーム転送装置ＭＡＣアドレスを宛先として、受信フレームをレイヤ２イーサネットフレームに変換し、これを上記テーブルエントリが示すコア回線インタフェース番号で特定された回線インタフェースから送信することを特徴とする請求項１または請求項２に記載のＰＰＰゲートウェイ装置。
4. 前記コア回線インタフェース番号が、物理リンク番号と論理リンク番号からなり、
   前記フレーム処理部が、上記物理リンク番号で特定されたコア回線上に、上記論理リンク番号を識別情報として含むレイヤ２イーサネットフレームを送信することを特徴とする請求項３に記載のＰＰＰゲートウェイ装置。
5. アクセス回線を収容する回線インタフェースで送受信されるＰＰＰフレームが、イーサネットヘッダと、ＰＰＰｏＥヘッダと、ＰＰＰヘッダと、ＩＰパケットからなり、コア回線を収容する回線インタフェースで送受信されるレイヤ２イーサネットフレームが、イーサネットヘッダと、ＩＰパケットからなることを特徴とする請求項１〜請求項４の何れかに記載のＰＰＰゲートウェイ装置。
6. クライアント端末との間でＰＰＰｏＥおよびＰＰＰの通信手順を実行するセッション制御部を有し、
   上記セッション制御部が、ＰＰＰｏＥの接続手順を実行中にクライアント端末のＭＡＣアドレスとＰＰＰセッション番号を特定し、ＰＰＰリンクの確立後に行われるクライアント認証手順の実行中にコア回線側のフレーム定義情報を特定して、前記フレーム転送制御テーブルに新たなＰＰＰセッション番号と対応したテーブルエントリを追加することを特徴とする請求項１〜請求項４の何れかに記載のＰＰＰゲートウェイ装置。
7. ドメイン名と、コア回線インタフェース番号と、フレーム転送装置ＭＡＣアドレスとの対応関係を定義したドメイン情報テーブルを有し、
   前記セッション制御部が、前記クライアント認証手順の実行中に、認証サーバから通知されたクライアント端末の所属ドメイン名に基いて、上記ドメイン情報テーブルからコア回線インタフェース番号とフレーム転送装置ＭＡＣアドレスを特定し、該コア回線インタフェース番号とフレーム転送装置ＭＡＣアドレスをコア回線側のフレーム定義情報として、前記フレーム転送制御テーブルに新たなテーブルエントリを追加することを特徴とする請求項６に記載のＰＰＰゲートウェイ装置。
8. 前記ドメイン情報テーブルの各テーブルエントリが、ドメイン名と対応するＤＨＣＰサーバのＩＰアドレスを含み、
   前記セッション制御部が、上記ドメイン情報テーブルで指定されたＤＨＣＰサーバから、クライアント端末に割り当てるべきＩＰアドレスを取得することを特徴とする請求項７に記載のＰＰＰゲートウェイ装置。
   

Images