JP3757863B2 - アクセスネットワーク装置 - Google Patents
アクセスネットワーク装置 Download PDFInfo
- Publication number
- JP3757863B2 JP3757863B2 JP2001393109A JP2001393109A JP3757863B2 JP 3757863 B2 JP3757863 B2 JP 3757863B2 JP 2001393109 A JP2001393109 A JP 2001393109A JP 2001393109 A JP2001393109 A JP 2001393109A JP 3757863 B2 JP3757863 B2 JP 3757863B2
- Authority
- JP
- Japan
- Prior art keywords
- access network
- terminal
- mac address
- network device
- session
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
ユーザ端末に対してISP(Internet Service Provider)網あるいは特定のプライベート網までの通信路を提供するアクセスネットワーク装置に関する。
【０００２】
【従来の技術】
従来、ADSL(Asynchronous Digital Subscriber Line)などのアクセスネットワークと契約している一般ユーザが、ISP網あるいは企業などのプライベート網を通信開始時に指定してPPP(Point-to-Point Protocol)を用いた通信を行う場合は、ユーザ端末がADSLなどの上のPPPoE(PPP over Ethernet)セッションをアクセスサーバとの間でまず確立する。その後、アクセスサーバはユーザ端末から受信するPPPのユーザ認証情報に基づき接続先のISPや企業を選択し、ユーザはアクセスサーバとISPとの間のVPN(Virtual Private Network)トンネルを経由して、PPPによる通信を実現している。
【０００３】
この際のVPNトンネルとしては、例えばL2TP(Layer 2 Tunneling Protocol)が用いられている。L2TPは、本来、電話を介してPPPダイヤルアップ接続を受け付けたリモートアクセスサーバが、IP(Internet Protocol)網を経由して目的のプライベート網のゲートウエイ装置にPPPフレームをトンネリングすることを目的に開発されたプロトコルであり、それが公衆電話網内設備として設けられたリモートアクセスサーバからのトンネリングにも適用されている。
【０００４】
【発明が解決しようとする課題】
上記従来技術は、アクセスサーバが、契約しているユーザが使用する端末から受信するPPPのユーザ認証情報に基づき接続先のISPや企業を選択する、という仕組みのために、ユーザ端末は、アクセスサーバとの間にPPPoEセッションを確立し、PPPのサブプロトコルであるLCP(Link Control Protocol)のネゴシエーション、及び認証情報の送信を行っている。そのために、アクセスサーバとISPとの間は、PPPフレームをトンネリングする必要があった。
【０００５】
上記従来技術はL2TPが有するプロトコルスタックの深さ、即ちユーザIPパケットをPPP、L2TP、UDP(User Datagram Protocol)、IPでカプセル化することによる、アクセスサーバ及びISP/企業のゲートウエイ装置におけるカプセル/デカプセル処理負荷が大きい点について配慮がされておらず、そのため転送スループットが小さく、転送遅延が大きくなる問題があった。
【０００６】
【課題を解決するための手段】
本発明は、ユーザ端末からの送信情報に基づいてアクセスサーバが接続先網を選択する機能を損なうことなく、アクセスサーバ - 接続先ゲートウエイ装置間のカプセル化レベルを小さくし、転送スループットを大きく、転送遅延を小さくする技術を提供する。
【０００７】
本発明は、PPPoEを適用する場合に、PPPoEの接続手順によるアクセスサーバ -接続先ゲートウエイ装置間のトラフィック増加を抑える技術を提供する。
【０００８】
本発明は、アクセスサーバでPPPを終端しない場合でも、アクセスサーバでユーザを認識しユーザ毎の接続サービスを実現する技術を提供する。
【０００９】
本発明は、同一接続先ネットワークに属する接続先ゲートウエイ装置が複数存在する場合に、それらのトラフィック負荷を均等にし接続先ネットワークの同時接続ユーザ数を増加させる技術を提供する。
【００１０】
本発明は、既存設備のアクセスサーバを置き換えることなく、IPv6ネットワークへのアクセスを可能にする技術を提供する。
【００１１】
具体的には、本発明は、アクセスサーバに、接続先ネットワークのゲートウエイ装置とMAC(Media Access Control)フレームの送受信を行うためのMACフレーム送受信処理部と、上記接続先ネットワークのゲートウエイ装置のMACアドレスと該接続先ネットワークの識別情報を対応付ける接続先ネットワーク情報記憶処理部を設ける。
【００１２】
端末が接続先ネットワークのMACアドレスを問い合わせるために該接続先ネットワークの識別情報をアクセスサーバに送信すると、アクセスサーバは応答すべきMACアドレスを接続先ネットワーク情報記憶処理部で特定し、端末に応答する。これにより、ISP側ネットワークへの問い合わせのブロードキャストフレームの送信を削減できる。
【００１３】
また、本発明は、アクセスサーバに、端末が発行した、利用者が接続を望むISP名が設定してあるMACアドレス問い合わせパケット(PADI)を受け取り、当該ISP名を設定したPADI、または端末が発行した上記MACアドレス問い合わせパケット(PADI)と同一パケットをISP側ネットワークに送信する処理部を設ける。
【００１４】
上記接続先ネットワーク情報記憶処理部において、まだ対応付けができていない接続先ネットワークの識別情報を端末から受信した場合は、ISP側ネットワークに問い合わせを行い、その応答をもって対応付けを行う。
【００１５】
また、上記接続先ネットワーク情報記憶部に存在しない接続先ネットワーク識別情報を、接続先ネットワークのゲートウエイ装置が接続していると思われる回線に送出し、該当する接続先ネットワークのゲートウエイ装置からの応答を待つための応答待ち時間計測部を設け、接続先ネットワーク識別情報を上記回線に送出後、あらかじめ定めた規定時間内であってかつ応答受信前に、同一の接続先ネットワーク識別情報を端末から受信した場合は、上記回線に対する再度の識別情報の送出は行わない。
【００１６】
また、アクセスサーバでPPPを終端しない場合でも、アクセスサーバでユーザを認識しユーザ毎の接続サービスを実現するために、端末と上記接続先ネットワークのゲートウエイ装置で送受信されるPPP認証フレームを監視するPPP認証フレーム監視部と、上記PPP認証フレーム監視部で取得したユーザ情報とPPPoEセッションIDとの対応付けを記憶するセッションユーザ記憶部を設ける。
【００１７】
また、ユーザ情報対応にセッション制御パラメータを管理するユーザプロファイル管理部を設け、該ユーザプロファイル管理部に記憶する制御パラメータに基づいてセッション制御を行う。
【００１８】
また、同一接続先ネットワークに属する接続先ゲートウエイ装置が複数存在する場合に、それらのトラフィック負荷を均等にし接続先ネットワークの同時接続ユーザ数を増加させるために、接続先ネットワークのゲートウエイ装置毎にトラフィック量を計測するためのトラフィック量計測部と、複数のゲートウエイ装置を同一グループとして認識するためのゲートウエイグループ管理部を設け、端末からの接続要求があった場合に、同一グループ内でトラフィック量が少ない接続先ネットワークのゲートウエイ装置を選択する。
【００１９】
【発明の実施の形態】
以下、本発明の実施例を説明する。
【００２０】
（システム構成）
図1はユーザがユーザ側装置(PCという)1200を使用して、ISP1203またはインターネット1205にアクセスするためのネットワーク構成である。
【００２１】
TE100は、本実施例によるアクセスネットワーク装置(以下、Access Gateway、はAGという)101からみたユーザ端末（以下、TE、Terminal Equipmentという)である。PC1200とTE100とは、Ethernet（Ethernetは富士ゼロックス社の登録商標である）、RS232C、USB(Universal Serial Bus)などのインタフェースで接続される。PC1200とTE100とが一体型の場合もある。
【００２２】
TE100はアクセスネットワークを介してAG101と通信する。アクセスネットワークとしてはADSL1206、FTTH(Fiber to The Home)1207、ケーブルテレビ網1208などがある。
【００２３】
ADSL1206の場合、TE100はDSLMODEM（Digital Subscriber Line modem、DSLMDMという）1201に接続し、DSLMDM1201はメタルケーブルを介してDSLAM(Digital Subscriber Line Access Multiplexer)1202に接続し、DSLAM1202はAG101に接続する。AG101は中継ネットワークを介して複数のISP1203のゲートウエイ装置ISPGW102に接続する。ISP1203はインターネット1205に対してもゲートウエイ装置ISPGW1204を持つ。AG101は企業等のプライベート網PN1214とも、ゲートウエイ装置PNGW1213を介して接続できる。
【００２４】
アクセスネットワークがFTTH1207の場合は、TE100はONU(Optical Network Unit)1209、OLT(Optical Line Terminal)1210を介してAG101と接続する。
【００２５】
アクセスネットワークがケーブルテレビ網1208の場合はケーブルモデムCM(Cable Modem)1211、ケーブルモデム終端装置CMTS(Cable Modem Termination System)1212を介してAG101と接続する。アクセスネットワークとAG101とのインタフェースとしてはATM、Ethernetなどがある。
【００２６】
図2(a)にアクセスネットワークがADSLの場合の従来のプロトコルスタックを示す。
【００２７】
図2(a)では、PC1200とTE100とはEthernetで接続されており、ローカル網を形成している。TE100はNAT機能を有し、PC1200が送信したIPパケットの送信元IPアドレスをAG101から割り当てられたIPアドレスに変換する。TE100はPPPリンクを終端するが、そのリンクの対向する終端はL2TPでトンネリングされた先の接続先ISPのゲートウエイ装置ISPGW102である。TE100においてIPアドレス変換されたパケットはPPPフレーミングされたあと、PPPoEヘッダが付加され、MACフレームとしてDSLMDM1201に送信される。DSLMDM1201は受信したMACフレームをATMセル化し、DSLAM1202に送信する。本図ではDSLAM1202とAG101のインタフェースはATMとしているので、ATMセルはAG101にてもとのMACフレームに復元される。
【００２８】
AG101はPPPoEヘッダに基づいて内部のPPPフレームをL2TPセッションに乗せかえる。L2TPカプセル化されたPPPフレームはさらにUDPヘッダ、IPヘッダが付加された後、ISPGW102に送信される。ISPGW102では受信パケットからPPPフレームを取り出し、PPPプロトコル処理を行って内部のユーザIPパケットを取り出す。
【００２９】
AG101とISPGW102のインタフェースはEthernet以外にも、ATM、POS(Packet Over Sonet)等があるがIP以上のレイヤには影響しない。
【００３０】
TE100がISPへのアクセスを開始する場合、TE100は、ISPGW102ではなく、AG101との間でPPPoEセッションを確立する。そして、その上でPPPのサブプロトコルであるLCP(Link Control Protocol)のネゴシエーション、及び認証情報の送信を行う。
【００３１】
AG101は、受信した認証情報に基づいて接続先ISPのゲートウエイ装置を選択し、そのIPアドレスに対しL2TPトンネル/セッションの確立を行う。
【００３２】
ISPGW102はPPPのサブプロトコルであるIPCP(Internet Protocol Control Protocol)のネゴシエーションによりTE100に対しIPアドレスを割り当て、これによりPC1200はTE100、ISPGW102を介して目的のISPにアクセスできるようになる。
【００３３】
AG101は、L2TPセッションが切断するまでTE100から送信されるPPPフレームはISPGW102に転送、ISPGW102から送信されるPPPフレームはTE100に転送する。
【００３４】
このように、従来は、AG101がTE100から受信するPPPのユーザ認証情報に基づき接続先のISPGW102を選択している。そのために、PPPoEセッションをTE100とAG101との間で確立する必要があった。さらに、PPPによる通信をISPGW102とTE100の間で行うためには、AG101とISPGW102との間でPPPフレームをトンネリングする必要があった。
【００３５】
（実施例1）
本実施例では、TE100とAG101との間だけではなく、AG101とISPGW102の間のトンネリングプロトコルとしてもPPPoEを採用する。図2(b)にプロトコルスタックを示す。なお、ISPGW102は、PPPoEに対応しているものとする。
【００３６】
また、本実施例において、中継ネットワークは、IP網である必要はなく、MACフレームの転送機能を持つものとする。
【００３７】
EthernetのMACレイヤの下にATMあるいはPOSのレイヤを図示しているが、これは例えばギガビットイーサの場合には存在しない。
EthernetのMACレイヤ以上のプロトコルを図2(a)と比較すると、図2(a)ではIP、UDP、L2TPの3つであるのに対し、図2(b)ではPPPoEのみである。これはAG101、ISPGW102におけるプロトコル処理が図2(a)と比べて軽いことを示している。
【００３８】
（AGの構成例）
図3に、本実施例を実現するAG101の構成例を示す。
【００３９】
AG101は物理回線収容カード(Line Interface、以下LIFという)1100、上位レイヤ処理カード(High Layer Module、以下HLYR-MDLという)1103、スイッチSW1108、装置制御カード(Controler、以下CTLという)1109からなる。
【００４０】
まず、AG101外部からの信号はLIF1100の物理レイヤ(Physical Layer、以下PHYという)チップ1101で整形されたディジタルな電気信号となり、下位レイヤプロトコル処理部(Low Protocol、以下LOWPROTという)1102に入力される。LOWPROT1102では、回線種別がATMやPOSの場合にそれらのプロトコル処理を行った後、上位プロトコルのMACフレームをHLYR-MDL1103に送信する。HLYR-MDL1103では受信したMACフレームの転送処理をMACレイヤ処理部(MAC frame Forwarding、以下MACFWDという)1107で行う。MACFWD1107で管理するアドレステーブルを図5に示す。
【００４１】
図5に示したアドレステーブル1000は、AG101が有する回線に接続している外部装置のMACアドレス1001とその回線ID1002とMACアドレスがISPかTEかを識別するISPフラグ1003からなる。回線ID1002は、物理回線がEthernetの場合は物理回線毎に付与し、ATMの場合はVC毎に付与する識別子である。MACFWD1107がMACフレームを受信すると、アドレステーブル1000を参照し、フレームの宛先MACアドレスから送出先の回線IDを特定し、それに基づいてSW1108を介して目的のHLYR-MDL1103に転送する。転送先のHLYR-MDL1103でも同様にアドレステーブル1000を参照し、回線IDから送出先となるLIF1100、物理ポートを特定し、LOWPROT1102、PHY1101を介してAG101外に送信する。ISPフラグ1003はPPPoEパケットのブロードキャストを行う場合の対象回線を識別するのに用い、詳しくは後述する。
【００４２】
図3において、MACFWD1107は高機能プロトコル処理部(Proccessing unit、以下PROCという)1104と接続している。PROC1104はPPPoEの制御パケットのうち特定のものを受信し、セッション制御、フレームのカプセル化方法をMACFWD1107に指示する。PROC1104が受信を期待するパケットはMACFWD1107が識別してPROC1104に転送する。PROC1104は上記処理を行うCPU1106とDB1105を有する。DB1105はTE100が接続要求の際に送信してくるISPの識別子と、その識別子に対応づけられた接続先ゲートウエイ装置のMACアドレスを管理するキャッシュテーブル900を保持する。
【００４３】
図4にキャッシュテーブル900を示す。キャッシュテーブル900はISPの識別子であるServiceName901と、ゲートウエイ装置のMACアドレス902と、エントリの残り有効時間903と、MACアドレス問い合わせパケット（PPPoE Active Discovery Initiation(PADI)パケット）の送信を抑止する送信ガードタイム904からなる。PROC1104のCPU1106はキャッシュテーブル900に基づいてPPPoEの制御パケット受信処理を行う。CTL1109はAG101全体の装置制御を行う。処理実行部としてのCPU1111と、制御に必要な情報を保持するDB1110を有する。
【００４４】
（実施例1-1）
実施例1において、AG101がPPPoEのブリッジとして動作する実施例を示す。
【００４５】
図6、図9、図10に、本実施例のメッセージシーケンスを示す。本実施例では、TE100はAG101をMACレイヤでの対向ノードとは認識せず、接続先ISP1（102）のゲートウエイ装置を対向ノードとして認識する。一方、ISP1（102）からは、同一セグメントにTE100とAG101が接続しているように見える。
【００４６】
図6はAG101がキャッシュテーブル900に保持していないISPに対する接続をTE100が要求した場合の接続シーケンスである。概要としては、TE100が接続先ISP1（102）のMACアドレスを取得するフローがPADI103、PADO(PPPoE Active Discovery Offer)108の送受信であり、続いて実際のPPPoEセッションを確立するフローがPADR(PPPoE Active Discovery Request)110、PADS(PPPoE Active Discovery Session-confirmation)111の送受信であり、その後、PPPoEセッション上でPPPのネゴシエーション112を行う。
【００４７】
まず、PPPoEパケットとTAG3109のフォーマットを説明し、次に、図6を詳細に説明する。
【００４８】
図7にPPPoEパケットのフォーマットを示す。PPPoEパケット3100はEtherタイプ3103の値が0x8863あるいは0x8864のMACフレームである(0xは16進数を示す)。宛先MACアドレス3101はPPPoEのパケットタイプがPADIの場合はブロードキャストアドレス、それ以外は宛先装置のユニキャストアドレスである。本実施例においては、PADOの送信元MACアドレス3102には、本来のPPPoEパケットの送信元アドレスではなく、ISPのゲートウエイ装置のアドレスに設定する。
【００４９】
Ver3104にはPPPoEのバージョンを設定する。type3105には1を設定する。code3106はPPPoEパケットのタイプを示し、この値によりPADI、PADO、PADR、PADS、PADT(PPPoE Active Discovery Terminate)の各種パケットが識別できる。セッションID3107はカプセル化するPPPフレームが属するPPPセッションを識別するためのIDである。Length3108はPPPoEペイロード長を示す。PPPoEペイロードは、Etherタイプ3103の値が0x8863の場合、すなわち制御パケットの場合はTAG3109であり、Etherタイプ3103の値が0x8864の場合、すなわちPPPフレームカプセル化パケットの場合はPPPフレーム3110である。PPPoEの制御パケットの場合、TAG3109は複数個含まれる場合がある。
【００５０】
チェックサム3115はMACフレームフォーマットとして規定されているチェックサムである。PPPフレーム3110のフォーマットとしては、プロトコル3111の内容がIPを示しているか、PPP制御フレームを示しているかによって異なる。前者の場合、プロトコル3111の後ろにはユーザIPパケット3114が設定される。後者の場合は、プロトコル3111に示されたPPPの各種サブプロトコル毎に定義されているメッセージ種別を示すコード3112と、その他情報3113が設定される。
【００５１】
図8にTAG3109のフォーマットを示す。TAG3109はTAGタイプ3200、TAGLength3201、TAGValue3202からなる。PADI103に設定するISP名はServiceNameTAG（TAGタイプ3200の値は0x0101）のTAGValueフィールドに設定する。
【００５２】
次に、図6を説明する。
【００５３】
TE100はPPPoEのPADIパケット103をブロードキャストのMACアドレス宛に送信する。PADI103には、PC1200の利用者が接続を望むISP名としてISP1が設定してある。
【００５４】
AG101がPADI103を受信すると、PADI103内に設定されているISP名（この場合はISP1）がキャッシュテーブル900に登録されているかチェックする（ステップ104）。
【００５５】
未登録の場合、キャッシュテーブル900に新しいエントリとしてServiceName901がISP1、残り有効時間903が0、送信ガードタイム904が例えば数秒のものを登録する（ステップ105、106）。
【００５６】
その後AG101はTE100から受信したPADI103と同一のパケットをPADI107としてAG101外にブロードキャストするが、このときアドレステーブル1000内のISPフラグ1003がISPと示されている回線に対してのみ送出する。これにより、ブロードキャストメッセージであるPADIをTE側へ無駄に送信することが無くなる。なお、ISPフラグ1003は、ネットワークを構築する際、保守者がコマンド操作で意識的に設定する。
【００５７】
ISP1（102）がPADI107を受信すると、PADI107に示されたISP名が自分と一致することを認識して、PADIの送信元MACアドレス、すなわちTE100に対してPADO108を送信する。これにより、ISPGW102が選択されたことになる。
【００５８】
AG101はPADOを受信すると宛先MACアドレスでアドレステーブル1000を検索し、TE100に転送するとともに、キャッシュテーブル900のMACaddr902にISP1（102）のMACアドレスAiを、残り有効時間903に例えば3600を、送信ガードタイム904に0を設定する。
【００５９】
PADO108を受信したTE100はAG101を介してISP1（102）に対しPADR110を送信し、ISP1はTE100にPADS111を送信する。これによって、TE100とISP1（102）との間にPPPoEセッションを確立する。
【００６０】
その後TE100とISP1（102）の間でPPPネゴシエーション112を実施することにより、IPパケット通信113が可能となる。
【００６１】
なお、ユーザ認証をAG101が行わないので、AG101では一見ユーザ管理が出来ないように見えるが、TE100に接続し各家庭に設置するDSLMDM1201とAG101の間にあらかじめ設定するATMのVPI/VCIに基づき、どのサービス加入者がアクセスしているかといった管理は可能である。
【００６２】
このように、上記シーケンスに依れば、PPPoEのMACアドレス問い合わせフェーズにおいて、アクセスサーバがISP網のゲートウエイ装置のMACアドレスをキャッシュテーブルに格納することができ、以後、他の端末からのそのISPに対する問い合わせに対しては、図9で説明するようにアクセスサーバがゲートウエイ装置にかわって応答できるので、アクセスサーバ-ISPゲートウエイ装置間のトラフィック量を小さくする効果がある。
【００６３】
次に、図9を用いて、その他の状況に於けるシーケンスを説明する。
【００６４】
図9において、AG101がISPのゲートウエイ装置のMACアドレスを問い合わせている最中に、そのISPに対する接続をTE100が要求した場合のシーケンスを説明する。TE100がISP1（102）を指定してPADI103をAG101に送信すると、AG101はステップ104にてキャッシュテーブル900内にISP1（102）のエントリがあるか検索する。キャッシュテーブル900にエントリがある場合は、残り有効時間903の値が正か否かを判定し（ステップ200）、
正でない場合は、（それにもかかわらずエントリが存在するということは）すでに同一のISP1（102）に対して図6で示したAG101からのPADI107が送信された後ということになるので、今回あらたにTE100から受信したPADI103は廃棄する（ステップ201）。
【００６５】
TE100が、AG101がISP1（102）に対しPADI107を送信するきっかけとなった端末と異なる端末の場合でも、AG101から同一ISP1へのPADI送信は冗長であるので抑止する。
【００６６】
図9において、AG101がキャッシュテーブル900にMACアドレスを保持しているISPに対する接続要求をTE100が行った場合のシーケンスを説明する。TE100がPADI103を送信すると、AG101はステップ104にてキャッシュ登録済みか判定し、登録済みの場合は残り有効時間903が正の値であるか判定する（ステップ200）。
【００６７】
正の値である場合はキャッシュテーブル900に登録されているISP1（102）のMACアドレスは有効と認識して、ISP側にPADI103を送信することなく、TE100に対してPADO300を送信する。これにより、無駄なブロードキャストメッセージを送らずに済み、ネットワークトラフィックを増やすということが無くなる。このパケットの送信元アドレスはキャッシュテーブル900内のMACaddr902である。PADO300を受信したTE100は以下図6と同様のシーケンスを経てISP1（102）とのIPパケット通信が可能となる。
【００６８】
TE100からの切断シーケンスでは、TE100が送信元MACアドレスをAt、送信先MACアドレスをAiとしたPADTを送信すると、AG101はそれをISP1（102）に転送する。ISP1（102）ではそれを受信し、TE100とのPPPリンク及びPPPoEセッションの切断処理を実施する。
【００６９】
ISP1（102）からの切断シーケンスでは、ISP1（102）が送信元MACアドレスをAi、送信先MACアドレスをAtとしたPADTを送信するとAG101はそれをTE100に転送する。TE100ではそれを受信し、ISP1（102）とのPPPリンク及びPPPoEセッションの切断処理を実施する。
【００７０】
図10はAG101が有するキャッシュテーブル900のエントリの残り有効時間903が規定値以下になった場合にAG101が送信元となってISP1（102）のMACアドレスを問い合わせるシーケンスである。
【００７１】
AG101は問い合わせが必要になった場合、ステップ106にてキャッシュテーブル900の送信ガードタイム904に例えば数秒を設定し、ブロードキャストMACアドレス宛にPADI601を送信する。実際に送出する回線としては、アドレステーブル1000にてISPフラグ1003がISPとなっているもの全てとする方法と、残り有効時間903が正の値である間はMACaddr902で特定される回線のみとする方法がある。なお、このパケットの送信元MACアドレスはAG101のアドレスである。
【００７２】
ISP1（102）がPADI601を受信すると、その送信元MACアドレス宛にPADO602を送信する。
【００７３】
AG101はPADO602を受信すると、ステップ109にてキャッシュテーブル900の残り有効時間903とMACaddr902を設定し、さらに送信ガードタイム904をクリアする。
【００７４】
本シーケンスにより、TE100からのPADIを受信しなくともAG101が定期的にISPのMACアドレスを確認でき、TE100からPADIを受信した際に速やかにPADOを返送することが可能になる。
【００７５】
以上のように本実施例によれば、接続端末のMACアドレスがISPに伝わるので、MACアドレスに基づいた制御（フィルタリング、優先制御）などをISPが独自に行うことができる。
【００７６】
（実施例1-1-1）
本実施例は、実施例1-1において、パケット受信をトリガとして図6、図9、図10のシーケンスを実施するAG101の処理を説明するものである。図11にその処理フローを示す。
【００７７】
本処理は図3のPROC1104及びMACFWD1107で実施する。パケット受信待ち700の状態において、PADI受信（分岐701）、PADO/PADS受信（分岐703）については、PROC1104で処理するため、MACFWD1107はこれらのパケットについては無条件にPROC1104に転送する。PADR/PADT/その他のMACフレームについては通常のLANスイッチの処理でよいのでPROC1104とは無関係にMACFWD1107で実行する。
【００７８】
まずPADI受信（分岐701）の場合、PROC1104はDB1105内に格納するキャッシュテーブル900にPADIに設定されているISP1に該当するエントリがあるかチェックする（ステップ104）。
【００７９】
エントリが無かった場合、エントリを追加し（ステップ105）、
送信ガードタイム904を設定し（ステップ106）、
受信したPADIパケットをMACFWD1107に転送する。MACFWD1107ではパケットがPADIであることを認識してアドレステーブル1000のISPフラグ1003がISPとなっている回線に対して本パケットを送出する（ステップ107）。
【００８０】
ステップ104にてキャッシュテーブル900にISP1のエントリが存在した場合、残り有効時間903が正の値かをチェックする（ステップ200）。
【００８１】
正の値の場合はキャッシュテーブル900のMACaddr902を送信元MACアドレスとしたPADOパケットを、PADIパケットの送信元アドレス宛に送信する。PROC1104からMACFWD1107に転送されたPADOパケットはアドレステーブル1000に基づいて特定の回線から送出される（ステップ300）。
【００８２】
ステップ200において残り有効時間903が正の値で無かった場合は受信パケットを廃棄する（ステップ201）。
【００８３】
PADO/PADS受信（分岐703）の場合、PROC1104はステップ705にてキャッシュテーブル900内にISP1のエントリがあることをチェックし、エントリがない場合は新規作成する（ステップ105）。
【００８４】
ステップ706にて残り有効時間903、MACaddr902を設定し、ステップ707にて送信ガードタイム904を0クリアする。ステップ705にてキャッシュテーブル900にISP1のエントリがあった場合はステップ706に進む。ステップ707の後、受信パケットがAG101のMACアドレス宛か否かの判定を行う（ステップ708）。
【００８５】
AG101宛でなければ、MACFWD1107にパケットを転送し、アドレステーブル1000に基づいた回線から送出する（ステップ709）。
【００８６】
ステップ708にてAG101宛であった場合は処理は終了する。PADR/PADT/その他のMACフレーム受信（分岐702）の場合はMACFWD1107がアドレステーブル1000に基づいて通常のMACフレーム転送処理を行う（ステップ704）。
【００８７】
（実施例1-1-2）
本実施例は、実施例1-1において、周期起動をトリガとして図6、図9、図10のシーケンスを実施するAG101の処理を説明するものである。図12にその処理フローを示す。
【００８８】
周期起動待ち800の状態から起動がかかると、PROC1104はキャッシュテーブル900内の全てのISPに関するエントリについて、個々に以下の処理を行う。
【００８９】
送信ガードタイム904の値が正か否かをチェックする（ステップ801）。
【００９０】
正の場合は値を減算し（ステップ805）、
その結果が正か否かの判定を行う（ステップ806）。
【００９１】
正でない場合はAG101がISPに送信したPADIに対する応答のPADOが規定時間内に戻ってこなかったことになるのでキャッシュテーブル900からエントリを削除する（ステップ807）。
【００９２】
ステップ806にてガードタイムの減算結果が正の場合は、残り有効時間903が正の値かチェックし（ステップ808）、
正の値であれば値を減算する（ステップ809）。
【００９３】
正の値でなければそのISPのエントリに関する処理を終了する。ステップ801にて送信ガードタイム904が正の値でない場合、すなわちISPに対してMACアドレスの問い合わせを行っていない場合、ステップ802にて残り有効時間903の値が正か否かを判定する。正の場合は値を減算し（ステップ803）、
結果が規定値nより大きいか判定する（ステップ804）。
【００９４】
ここでnはエントリ削除のどれくらい前からISPへのMACアドレス問い合わせを開始するかを決定する値であり、あらかじめ定義しておく。残り有効時間903がnより大きい場合はまだ問い合わせが不要であるので、そのエントリに対する処理は終了する。ステップ804にて残り有効時間903がn以下であった場合は送信ガードタイム904を設定して（ステップ600）、
MACaddr902宛にPADIパケットを送信する（ステップ601）。
【００９５】
PROC1104はPADIパケットをMACFWD1107に転送し、MACFWD1107はアドレステーブル1000を参照してISPフラグ1003がISPとなっている全ての回線からパケットを送出する。ステップ802にて残り有効時間903が正の値でなければステップ106に進み、PADI送信処理を行う。
【００９６】
（実施例1-2）
実施例1において、AG101がTE側インタフェースとISP側インタフェースの両方にMACアドレスを有し、TE101 - AG101間と、AG101 - ISPGW102間に別々のPPPoEセッションを確立する場合の実施例を示す。
【００９７】
図13から図23を用いて本実施例を説明する。
【００９８】
図13はAG101がキャッシュテーブル900に保持していないISPに対する接続をTE100が要求した場合の接続シーケンスである。
【００９９】
TE100がPADI103をAG101に送信すると、AG101はキャッシュテーブル900を参照してISP1が登録済みかチェックする（ステップ104）。
【０１００】
未登録の場合、新規にエントリを追加し（ステップ105）、
送信ガードタイム904を例えば数秒に設定する（ステップ106）。
【０１０１】
さらに本実施例ではどのTEに対しPADO送信しなくてはならないかを管理するPADIテーブルを設定する（ステップ1800）。
【０１０２】
図14にPADIテーブルを示す。PADIテーブル2600はMACアドレス問い合わせ中のISPの識別子であるServiceName2601と、PADI送信元すなわち問い合わせ要求を行ったTEのアドレスTEaddr2602と、AG101がISPからのPADOを待つ残り時間のPADO待ち時間2603からなる。本テーブルはPROC1104のDB1105で保持する。
【０１０３】
図13においてステップ1800ではPADIに設定されているISPの識別子ISP1をServiceName2601に、送信元アドレスをTEaddr2602に、PADO待ち時間2603には例えば数秒を設定する。その後、送信元MACアドレスがAG101のPADI1801をISP1（102）に送信する。ISP1（102）はPADI1801を受信すると、送信元MACアドレスがISP1（102）のPADO1802をAG101に送信する。AG101がPADO1802を受信すると、キャッシュテーブル900の残り有効時間903にこのエントリの有効時間を、MACaddr902にISP1（102）のMACアドレスを、送信ガードタイム904に0を登録する（ステップ110）。
【０１０４】
その後AG101はPADIテーブル2600を参照してTE100宛のPADO1803を送信し、PADIテーブル2600の該当エントリを削除する（ステップ1804）。
【０１０５】
PADO1803を受信したTE100はPADO1803の送信元アドレスであるAG101宛にPADR1805を送信する。AG101はPADR1805を受信すると、どのTEに対しPADSを送信しなくてはならないかを管理するPADRテーブルを設定する（ステップ1806）。
【０１０６】
図15にPADRテーブルを示す。PADRテーブル2700は接続要求先ISPの識別子であるServiceName2701と、PADR送信元のTEaddr2702と、接続要求先ISPからのPADSを待つ残り時間を示すPADS待時間2703からなる。本テーブルはPROC1104のDB1105で保持する。
【０１０７】
図13においてAG101はPADRテーブル2700の設定後、ISP1（102）に対してAG101を送信元アドレスとしたPADR1807を送信する。ISP1（102）はPADR1807を受信すると、AG101-ISP1（102）間でセッションを識別するためのセッションIDを割り当て、それを設定したPADS1808をAG101宛に送信する。AG101はTE100に対してTE100-AG101間でセッションを識別するためのセッションIDを割り当て、PADS1808で通知されたセッションIDと共にセッション管理テーブルに登録する。
【０１０８】
図16にセッション管理テーブルを示す。セッション管理テーブル2200はTEaddr2201、AG101からみたTE側セッションID2202、ISPaddr2203、ISP側セッションID2204、セッションを使用するユーザ名2205からなる。ユーザ名2205はPPPネゴシエーション中にTE100とISP1（102）の間で送受信されるPPP制御フレームをAG101がモニタすることにより認識できるものであり、その実施例については後述する。
【０１０９】
このテーブルは、セッション確立後はユーザパケットを１個転送するたびに参照される。したがって、専用LSIで構成することが望ましいMACFWD1107と、ユーザ名に基づいた複雑な処理を行うPROC1104それぞれが、本テーブルを保持することが望ましい。
【０１１０】
本テーブルを装置へ実装する場合は、ユーザ名のエントリの代わりにインデックスを設けたテーブルをMACFWD1107が保持し、そのインデックスとユーザ名を対応付けたテーブルをPROC1104が保持するように構成しても良い。
【０１１１】
MACFWD1107は本テーブルを用いて、TE100から送信されるPPPoEパケットのヘッダを付け替えてISP1（102）に転送する、あるいはその逆の転送を行い、PROC1104は、本テーブルを用いて、ユーザ個別のプロファイル情報とリンクさせてセッションを制御する。
【０１１２】
図13においてAG101はセッション管理テーブル2200を設定（ステップ1809）した後、PADRテーブル2700に基づいてTE100宛にPADS1810を送信し、PADRテーブル2700から送信済みTEに関するエントリを削除する（ステップ1811）。
【０１１３】
TE100がPADS1810を受信した時点でPPPoEセッションが確立し、TE100は、ISP1（102）との間でPPPネゴシエーション112を実施する。これによりIPパケット通信113が可能になる。
【０１１４】
図17はAG101がキャッシュテーブル900にMACアドレスを保持しているISPに対する接続要求をTE100が行った場合のシーケンスである。ステップ200までは図9と同様である。ステップ200においてキャッシュテーブル900の残り有効時間903が正の値の場合は、AG101は送信元アドレスがAG101のPADO1803をTE100に送信する。TE100がPADO1803を受信したあとのシーケンスは図13と同様である。
【０１１５】
TE100からの切断シーケンスを説明する。TE100が、送信元をTE100、送信先をAG101としたPADTをAG101宛に送信すると、AG101はPADT内のセッションID3107をキーとしてセッション管理テーブル2200のTE側セッションID2202を検索、一致したエントリに基づいてPADTのヘッダ内容を変更して送信元をAG101、送信先をISPGW102としたPADTをISP1（102）宛に送信する。さらに、参照したエントリを削除する。
【０１１６】
ISP1（102）からの切断シーケンスを説明する。ISP1（102）が、送信元をISPGW102、送信先をAG101としたPADTをAG101に対して送信するとAG101はPADT内のセッションID3107をキーとして、セッション管理テーブル2200のISP側セッションID2204を検索、一致したエントリに基づいてPADTのヘッダ内容を変更し、送信元をAG101、送信先をTE100としたPADTをTE100宛に送信する。さらに、参照したエントリを削除する。
【０１１７】
（実施例1-2-1）
本実施例は、実施例1-2において、パケット受信をトリガとして図13、図17のシーケンスを実施するAG101の処理を説明するものである。図18、図19にその処理フローを示す。
【０１１８】
本処理は図3のPROC1104及びMACFWD1107で実施する。パケット受信待ち2300の状態において、PADI受信（分岐2301）、PADR受信（分岐2302）、PADO/PADS受信（分岐2303）、PADT受信（図19分岐2401）はPROC1104で処理するため、MACFWD1107が受信時にPROC1104に転送する。PPPフレーム受信（図19分岐2400）はMACFWD1107で処理する。まずPADI受信（分岐2301）の場合、PROC1104はキャッシュテーブル900に接続先ISPのエントリがあるかチェックし（ステップ104）、
ない場合は新規に作成し（ステップ105）ServiceName901と送信ガードタイム904を設定し（ステップ106）、
さらにPADIテーブル2600を設定して（ステップ1800）PADIの送信元アドレスをAGに変えた後MACFWD1107にパケットを転送する。MACFWD1107ではアドレステーブル1000のISPフラグ1003がISPと示される回線に対してPADIを送信する（ステップ1801）。
【０１１９】
ステップ104にてキャッシュテーブル900に対象のISPのエントリがある場合、残り有効時間903が正の値か判定する（ステップ200）。
【０１２０】
正の値の場合は送信元アドレスをAG101としたPADOをTE100に送信する（ステップ1803）。
【０１２１】
正の値でない場合は受信パケットを廃棄する（ステップ201）。
【０１２２】
パケット受信待ち2300状態からPADO/PADS受信（分岐2303）の場合は、キャッシュテーブル900にISP1のエントリが存在するか検索し（ステップ705）、
存在しなかった場合は新規にISP1のエントリを作成し（ステップ105）、
残り有効時間903と、MACaddr902を設定し（ステップ706）、
送信ガードタイム904をクリアする（ステップ707）。
【０１２３】
ステップ705にてISP1に関するエントリが存在する場合は、ステップ706に進む。ステップ707の後、受信パケットの種別を判定する（ステップ2305）。
【０１２４】
受信パケットがPADOの場合はPADIテーブル2600を検索し、応答待ちとなっているTEがあるかチェックする（ステップ2306）。
【０１２５】
応答待ちのものがなければ処理を終了する。応答待ちのものがあればPADIテーブル2600に基づいてTEaddr2602宛にPADOを送信する（ステップ1803）。
【０１２６】
その後PADIテーブル2600から送信済みTEに関するエントリを削除する（ステップ1804）。
【０１２７】
PROC1104がMACFWD1107に転送したPADOパケットは、アドレステーブル1000に基づいて回線に送出される。ステップ2305にて受信パケットがPADSであった場合は、セッション管理テーブル2200に新たなエントリを作成し、PADRテーブル2700のTEaddr2702をセッション管理テーブル2200のTEaddr2201に設定し、受信PADSパケットの送信元MACアドレス3102をISPaddr2203に、セッションID3107をISP側セッションID2204に設定する。そしてAG101が割り当てたセッションIDをTE側セッションID2202に設定する（ステップ1809）。
【０１２８】
本テーブルはMACFWD1107にも設定する。そしてPADRテーブル2700にて応答待ちとなっているTEに対しPADSを送信し（ステップ1810）、
そのTEに関するエントリを削除する（ステップ1811）。
【０１２９】
パケット受信待ち2300状態からPADR受信（分岐2302）の場合は、ステップ2304にてキャッシュテーブル900に接続先ISP1に関するエントリが存在するかチェックし、存在しなければ受信パケットを廃棄する（ステップ201）。
【０１３０】
存在した場合はその情報に基づいてPADRテーブル2700を設定する（ステップ1806）。
【０１３１】
ServiceName2701には受信したPADRパケットに示されたISP1を、TEaddr2702には送信元MACアドレスを、PADS待ち時間2703には例えば数秒を設定する。そしてPADRをISP1に送信する（ステップ1807）。
【０１３２】
パケット受信待ち2300の状態からPPPフレーム受信（分岐2400）の場合は、MACFWD1107にてセッション管理テーブル2200に基づいてパケットの宛先MACアドレス3101、送信元MACアドレス3102、セッションID3107を変更したあと、アドレステーブル1000を参照してパケットを回線に送出する（ステップ2402）。
【０１３３】
パケット受信待ち2300の状態からPADT受信（分岐2401）の場合は、PROC1104にてセッション管理テーブル2200を参照してパケットの宛先MACアドレス3101、送信元MACアドレス3102、セッションID3107を変更して送信する（ステップ2403）。
【０１３４】
その後、PROC1104、MACFWD1107にそれぞれ存在するセッション管理テーブル2200から対象セッションのエントリを削除する（2404）。
【０１３５】
（実施例1-2-2）
本実施例は、実施例1-2において、周期起動をトリガとして図13、図17のシーケンスを実施するAG101の処理を説明するものである。図20にその処理フローを示す。ただし、図12の処理に加えて必要な分のみを示している。周期起動待ち2500の状態から起動がかかると、PADI(PPPoE Active Discovery Initiation)テーブル2600内のPADO(PPPoE Active Discovery Offer)待ち時間2603を減算する（ステップ2501）。
【０１３６】
その結果、正の値でなくなったエントリについてはテーブルから削除する（ステップ2502）。
【０１３７】
PADR(PPPoE Active Discovery Request)テーブル2700についても同様にPADS(PPPoE Active Discovery Session-confirmation)待ち時間2703を減算し（ステップ2503）、
PADS待ち時間が正の値でなくなったエントリを削除する（ステップ2504）。
【０１３８】
（実施例2）
本実施例は、PPPoEセッションをTE100とISPGW102との間で確立し、AG101とISPGW102の間のトンネリングプロトコルとしてL2TPではなくPPPoAとするものである。図2(c)にプロトコルスタックを示す。この場合、PPPの下位レイヤはATMである。
【０１３９】
また、ISPGW102は、PPPoAをサポートしているものとする。
【０１４０】
図2(a)におけるAG101とISPGW102のインタフェースがIPoverEtherではなく、IPoverATMだった場合と比較すると、ATMレイヤより上のプロトコルは図2(a)ではIP、UDP、L2TP、PPPであるのに対し、図2(c)ではPPPのみである。これはAG101、ISPGW102におけるプロトコル処理が図2(a)と比べて軽いことを示している。
【０１４１】
図21は、AG101がTE100とはPPPoEで通信し、ISP1（102）とはPPPoAで通信する場合の実施例のメッセージシーケンスを示す。
【０１４２】
TE100がAG101にPADI103を送信すると、AG101はISPテーブルを参照する。
【０１４３】
図22にISPテーブルを示す。ISPテーブル3000はPROC1104とMACFWD1107の両方で保持し、PROC1104はAG101があらかじめATM回線で接続するISPそれぞれに関し、VCの空き状況を管理するために使用する。また、MACFWD1107は、PPPoEセッションでTEから受信したパケット内のPPPフレームをどのVCに転送すればよいか、あるいはその逆の処理に使用する。
【０１４４】
テーブルは接続先ISPの識別情報ServiceName3001と、接続に使用する物理ポート3002、VPI/VCI(Virtual Path Identifier/Virtual Channel Identifier)3003、そのVCを使用するPPPoEセッション情報としてTEaddr3004とセッションID3005、セッション使用ユーザ名3006からなる。このうち、ServiceName3001、物理ポート3002、VPI/VCI3003はATM回線設定を行った時点で設定する。
【０１４５】
ひとつのVCがひとつのPPPoEセッションに対応し、TE100がAG101に接続してきた時点でTEaddr3004、セッションID3005、ユーザ名3006がテーブルに設定される。各VCが使用中か否かの識別は例えばTEaddr3004の値が0以外か否かで行う。ユーザ名3006はPPPネゴシエーション中にTE100とISP1（102）の間で送受信されるPPP制御フレームをAG101がモニタすることにより認識できるものであり、その実施例については後述する。
【０１４６】
図21においてAG101はPADI103を受信すると、図22を参照し、指定されたISPに接続しているVCに空きがあるかチェックする（ステップ2800）。
【０１４７】
空きが無ければ受信パケットを廃棄する（ステップ2801）。
【０１４８】
空きVCがあった場合はTE100からの接続要求は受け付け可能であるので送信元アドレスとしてAG101を設定したPADO1803をTE100宛に送信する。PADO1803を受信したTE100はPADR1805をAG101に対し送信する。AG101は再度ISPテーブル3000を検索し（ステップ2802）、
空きVCが無ければパケットを廃棄する（ステップ2803）。
【０１４９】
空きVCがある場合、ISPテーブル3000内で選択したVCのエントリに対し、TEaddr3004、セッションID3005を登録する（ステップ2804）。
【０１５０】
その後AG101はPADS1810をTE100に対して送信する。TE100がPADS1810を受信すると、ISP1（102）との間でPPPネゴシエーション112を行い、IPパケット通信113が可能となる。
【０１５１】
TE100からの切断シーケンスを説明する。TE100がPADT2000をAG101に送信すると、AG101はPADTに設定されているセッションID3107をキーにISPテーブル3000を検索し、該当エントリを削除することでVCを空き状態に戻す。
【０１５２】
図23は図21のシーケンスを実現するためのAG101の処理フローである。本処理は図3のPROC1104及びMACFWD1107で実施する。パケット受信待ち4000の状態から、PADI受信（分岐4001）、PADR受信（分岐4002）、PADT受信（分岐4004）はPROC1104で処理し、PPPフレームすなわちPPPoE制御パケット以外の受信（分岐4003）はMACFWD1107で処理する。
【０１５３】
まず、PADI受信（分岐4001）の場合、ISPテーブル3000を検索し、接続要求のあったISP向けのVCに空きがあるかチェックする（ステップ2800）。
【０１５４】
空きVCがあった場合はPADOをTE宛に送信する（ステップ1803）。
【０１５５】
PROC1104はMACFWD1107にパケットを転送し、アドレステーブル1000に基づいて回線に送出する。ステップ2800にて空きがなかった場合は受信パケットを廃棄する（2801）。
【０１５６】
PADR受信（分岐4002）の場合は、ステップ2802にてステップ2800同様ISPテーブル3000を検索する。空きVCがあればISPテーブル3000にAG101が割り当てるセッションID3005と、TEaddr3004を登録する。登録はMACFWD1107が保持するテーブルに対しても行う（ステップ2804）。
【０１５７】
そしてTEに対してPADSを送信する。PROC1104はMACFWD1107にパケットを転送し、MACFWD1107はアドレステーブル1000に基づいて回線に送出する（ステップ1810）。
【０１５８】
ステップ2802にて空きVCがなかった場合は受信パケットを廃棄する（ステップ2803）。
【０１５９】
PADT受信（分岐4004）の場合は、パケット内のセッションID3107で特定されるセッションの情報をISPテーブル3000から削除し、それまで使用していたVCを空きにする。削除はMACFWD1107が保持するテーブルに対しても行う（ステップ2900）。
【０１６０】
PPPフレーム受信（分岐4003）の場合は、MACFWD1107が保持するISPテーブル3000を参照してPPPフレームのカプセル/デカプセル処理を行い、TE100とISP1（102）のPPP通信を実現する（ステップ4005）。
【０１６１】
（実施例3）
本実施例では、TE100とISP1（102）の間で行うPPPネゴシエーションにおいてセッションのユーザの認証シーケンスを示す。
【０１６２】
図24は、図6、図13、または図21の各実施例におけるPPPネゴシエーションのフェーズを詳細に説明する図である。
【０１６３】
まず、TE100とISP1（102）はPPPのサブレイヤであるLCPのネゴシエーション3300を実施する。
【０１６４】
その後、ISP1（102）はユーザ認証を行うための認証乱数を有するCHAP(Challenge Handshake Authentication Protocol) Challengeメッセージ3301をTE100に送信する。
【０１６５】
TE100はユーザ名と乱数に対して行った演算結果をCHAP Responseメッセージ3302に設定して、AG101経由でISP1（102）に送信する。
【０１６６】
AG101は当該メッセージを認識するとユーザ名を取得し、セッションユーザ情報テーブル3900（図25）のユーザ名3904（図6に示す実施例1-1の場合）、またはセッション管理テーブル2200（図16）のユーザ名2205（図13に示す実施例1-2の場合）、またはISPテーブル3000（図22）のユーザ名3006（図21に示す実施例2の場合）に登録する（ステップ3303）。
【０１６７】
なお、セッションユーザ情報テーブル3900のTEaddr3901、セッションID3902、ISPaddr3903にはCHAP Responseメッセージ3302をカプセル化しているPPPoEパケットの送信元MACアドレス3102、セッションID3107、宛先MACアドレス3101をそれぞれ設定する。本テーブルはPROC1104のDB1105で管理する。
【０１６８】
ISP1（102）は認証が成功した場合はCHAP Successメッセージ3304をTE100に対して送信する。AG101はこのCHAP Success3304を受信し、ユーザが確定したとき、上記のいずれかのテーブルに設定したユーザ名が正しいと判断して、ユーザ毎の固有の制御を開始する。例えばPROC1104はMACFWD1107に対象セッションの統計情報カウントを指示する(ステップ3305)。
【０１６９】
TE100がCHAP Success3304を受信すると、TE100はPPPのサブレイヤであるIPCPのネゴシエーション3306を行い、IPパケット通信113が可能となる。一方PPPセッションを終了するとき、すなわちLCP Term-req(LCP Terminate-Request)メッセージ3308がTE100-ISP1（102）間で送受信されるとき、AG101は本メッセージを認識してユーザ固有制御を終了する（ステップ3309）。
【０１７０】
LCP Term-req3308を受信したISP1（102）はLCP Term-ack3310をTE100に送信し、PPPoEセッション切断のフェーズに進む。
【０１７１】
ステップ3309において、ユーザ毎の詳細な通信量が取得できる。例えばMACFWD1107から送信フレーム数、受信フレーム数を読出し、PROC1104自体で測定していた通信時間、ユーザ名とあわせてCTL1109に送信する。CTL1109は、内部のDB1110あるいはAG101外部のDB3500にこれらの情報を登録する。こうすることで、ユーザ毎の詳細な通信量が取得でき、課金等に利用することが可能となる。
【０１７２】
ユーザ毎の固有制御の具体例としては、統計情報取得がある。図28に統計情報テーブルを示す。統計情報テーブル3700は図3のCTL1109もしくは図27に示すAG101外のDB3500で管理する。本テーブルは、情報を登録した時刻3701、ユーザ名3702、ユーザの通信時間3703、送信フレーム数3704、受信フレーム数3705からなる。
【０１７３】
本実施例では認証プロトコルとしてCHAPを例に示したが、PAP(PPP Authentication Protocol)でも同様に行える。これらCHAP/PAPメッセージの識別は、PPPフレームフォーマット3110中のプロトコル3111でCHAP/PAPが、コード3112で例えばCHAPの場合はChallenge/Response/Successが識別できる。
【０１７４】
ユーザ毎の固有の制御の他の具体例としては、パケット転送優先度の制御がある。図26に優先度テーブルを示す。
【０１７５】
優先度テーブル3600はユーザ毎にあらかじめ割り当てた優先レベルを格納しているテーブルであり、図3のCTL1109内のDB1110で保持するか、または図27に示すAG101外部のDB3500に保持する。AG101がCHAP Success3304を受信しユーザが確定したとき、PROC1104はCTL1109にユーザ名を送信する。CTL1109は内部のDB1110あるいはAG101外部のDB3500にある優先度テーブル3600を検索し、ユーザ名3601に対応した優先レベル3602を特定し、それをPROC1104に送信する。PROC1104はMACFWD1107のキュー制御に指示を出す。こうすることで、優先レベルの高いユーザが送受信するパケットはMACFWD内で優先的に転送されることが可能になる。
【０１７６】
図29は図24のシーケンスを実現するための処理フローである。パケット受信待ち3400の状態からPPPフレーム受信（分岐3401）の場合、MACFWD1107でパケットの転送処理を行うと共に（ステップ3403）、
PPPフレーム内容がCHAP Response/PAP Auth Req(PAP Authenticate-Request)受信（分岐3404）及びCHAPSuccess/PAP Auth Ack受信（分岐3405）の場合はPPPoEパケットをPROC1104に転送する。CHAP Response/PAP Auth Req受信（分岐3404）の場合、PPPフレーム内容からユーザ名を取得し、セッションユーザ情報テーブル（図25）のユーザ名3904（図6の実施例の場合）、またはセッション管理テーブル2200のユーザ名2205（図13の実施例の場合）、またはISPテーブル3000のユーザ名3006（図21の実施例の場合）に登録する（3303）。CHAP Success/PAP Auth Ack受信（分岐3405）の場合は制御内容に応じてCTL1109に対しユーザ情報のDBを検索(ステップ3406)し、ユーザ毎の固有の制御を開始する（ステップ3407）。
【０１７７】
パケット受信待ち3400の状態からPADT受信（分岐3402）の場合は、パケット転送をMACFWD1107で行い（ステップ3403）、
PROC1104にてユーザ固有制御の終了処理を実施する（ステップ3309）。
【０１７８】
本実施例によれば、PPPセッションのユーザを認識することができるので、ユーザ個別のサービスを提供できるという効果がある。
【０１７９】
上記サービスとして、特定のユーザのパケットを優先的に転送することが可能になるという効果がある。また、ユーザ毎のトラフィック情報を取得できるので、細かな課金制御に利用できるという効果がある。
【０１８０】
（実施例4）
同一ISPに複数のゲートウエイ装置が存在する場合にゲートウエイ装置間の負荷を平均化する実施例を示す。
【０１８１】
図30は、AG101において、同一ISPの複数のゲートウエイ装置それぞれのトラヒック量を管理するためにキャッシュテーブル900を拡張した拡張キャッシュテーブルを示している。拡張キャッシュテーブル3800はキャッシュテーブル900に単位時間トラヒック3806を追加した構成になっている。
【０１８２】
図6または図10のキャッシュテーブルを登録するステップ109のタイミングで、PROC1104はMACFWD1107にMACaddr3802毎のトラヒック計測を指示し、周期的に情報を読み出して単位時間トラヒック3806に設定、更新する。この情報を用いて、図9のステップ104にてTE100に通知するISPのMACアドレスの候補が複数存在する場合、単位時間トラヒック3806の最も小さいものをPADOパケットの送信元アドレスに設定してTE100に通知する。これにより、同一ISPのゲートウエイ装置間でトラヒックを平均化することができるので、そのISPに同時に接続可能なユーザ数を増やすことができるなど、ISP全体として効率よくユーザを収容することが可能になる。
【０１８３】
（実施例５）
以上、上述した各実施例を応用することにより、以下に示すように、既存のアクセスネットワーク装置を変更することなく、IPv4網とIPv6網いずれの中継ネットワークにも接続できるようになる。
【０１８４】
既存のアクセスネットワーク装置AG1300が、IPv4用PPPに対応し、IPv6用PPPには対応していない場合、IPv4網からIPv6網への分岐を実現するにはAG1300を変更する必要がある。
【０１８５】
そこで、図31に示すようにPPPoEで通信している既存設備間たとえばDSLAM1202-AG1300の間に、上述した実施例に基づくAG101を追加する。AG101はDSLAM1202、既存AG1300の両方に対してPPPoEのインタフェースで接続できるため、DSLAM1202、既存AG1300を変更することなく、AG101を追加することができる。
【０１８６】
【発明の効果】
本発明によれば、アクセスサーバからISP網までのトンネリングに係わる処理負荷が小さくなり、パケット転送遅延を小さく、パケット転送速度を大きくできる。
【図面の簡単な説明】
【図１】本発明のアクセスネットワーク装置を適用するネットワーク構成図である。
【図２】従来のネットワークと、各実施例によるプロトコルスタックを示す図である。
【図３】アクセスネットワーク装置の構成図である。
【図４】アクセスネットワーク装置がブリッジとして動作する実施例の、ISPのMACアドレスを管理するキャッシュテーブルである。
【図５】アクセスネットワーク装置がPPPoEのブリッジとして動作する実施例の、MACアドレステーブルである。
【図６】アクセスネットワーク装置がブリッジとして動作する実施例の、端末がISPに接続する際に該アクセスネットワーク装置が接続先ISPのMACアドレスをキャッシュしていない場合のシーケンスである。
【図７】 PPPoEパケットのフォーマットである。
【図８】 PPPoEのTAGフォーマットである。
【図９】アクセスネットワーク装置がブリッジとして動作する実施例の、端末がISPに接続する際に該アクセスネットワーク装置が接続先ISPのMACアドレスを問い合わせ中の場合のシーケンスである。
【図１０】アクセスネットワーク装置がブリッジとして動作する実施例の、アクセスネットワーク装置起動でISPのMACアドレスを問い合わせるシーケンスである。
【図１１】アクセスネットワーク装置がブリッジとして動作する実施例の、パケット受信起動による処理フローである。
【図１２】アクセスネットワーク装置がブリッジとして動作する実施例の、周期起動による処理フローである。
【図１３】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、端末がISPに接続する際に該アクセスネットワーク装置が接続先ISPのMACアドレスをキャッシュしていない場合のシーケンスである。
【図１４】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、TEからのPADI受信を管理するPADIテーブルである。
【図１５】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、TEからのPADR受信を管理するPADRテーブルである。
【図１６】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、セッション管理テーブルである。
【図１７】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、端末がISPに接続する際に該アクセスネットワーク装置が接続先ISPのMACアドレスをキャッシュしている場合のシーケンスである。
【図１８】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、パケット受信起動による処理フローである。
【図１９】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、パケット受信起動による処理フローである。
【図２０】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、周期起動による処理フローである。
【図２１】アクセスネットワーク装置がTE100とはPPPoEで通信し、ISP1（102）とはPPPoAで通信する場合の実施例の、接続シーケンスである。
【図２２】アクセスネットワーク装置がTE100とはPPPoEで通信し、ISP1（102）とはPPPoAで通信する場合の実施例の、VCを管理するISPテーブルである。
【図２３】アクセスネットワーク装置がTE100とはPPPoEで通信し、ISP1（102）とはPPPoAで通信する場合の実施例の、処理フローである。
【図２４】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例のシーケンスである。
【図２５】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の、セッションユーザ情報テーブルである。
【図２６】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の、ユーザ固有制御としてパケット転送優先度を制御する場合の優先度テーブルである。
【図２７】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の、ユーザ情報を外部のDBで管理する場合のネットワーク構成である。
【図２８】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の、ユーザ固有制御としてトラフィック統計情報を取得する場合の統計情報テーブルである。
【図２９】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の処理フローである。
【図３０】アクセスネットワーク装置の、接続先の同一ISPに複数のゲートウエイ装置が存在する場合にゲートウエイ装置間の負荷を平均化する実施例の、ゲートウエイ装置それぞれのトラヒック量を管理する拡張キャッシュテーブルである。
【図３１】アクセスネットワーク装置を既存アクセスネットワークに追加する場合のプロトコルスタックである。
【符号の説明】
100…ユーザ端末、101…アクセスネットワーク装置、102…ISP、900…キャッシュテーブル、2200…セッション管理テーブル、2600…PADIテーブル、2700…PADRテーブル、3000…ISPテーブル、3800…拡張キャッシュテーブル
【発明の属する技術分野】
ユーザ端末に対してISP(Internet Service Provider)網あるいは特定のプライベート網までの通信路を提供するアクセスネットワーク装置に関する。
【０００２】
【従来の技術】
従来、ADSL(Asynchronous Digital Subscriber Line)などのアクセスネットワークと契約している一般ユーザが、ISP網あるいは企業などのプライベート網を通信開始時に指定してPPP(Point-to-Point Protocol)を用いた通信を行う場合は、ユーザ端末がADSLなどの上のPPPoE(PPP over Ethernet)セッションをアクセスサーバとの間でまず確立する。その後、アクセスサーバはユーザ端末から受信するPPPのユーザ認証情報に基づき接続先のISPや企業を選択し、ユーザはアクセスサーバとISPとの間のVPN(Virtual Private Network)トンネルを経由して、PPPによる通信を実現している。
【０００３】
この際のVPNトンネルとしては、例えばL2TP(Layer 2 Tunneling Protocol)が用いられている。L2TPは、本来、電話を介してPPPダイヤルアップ接続を受け付けたリモートアクセスサーバが、IP(Internet Protocol)網を経由して目的のプライベート網のゲートウエイ装置にPPPフレームをトンネリングすることを目的に開発されたプロトコルであり、それが公衆電話網内設備として設けられたリモートアクセスサーバからのトンネリングにも適用されている。
【０００４】
【発明が解決しようとする課題】
上記従来技術は、アクセスサーバが、契約しているユーザが使用する端末から受信するPPPのユーザ認証情報に基づき接続先のISPや企業を選択する、という仕組みのために、ユーザ端末は、アクセスサーバとの間にPPPoEセッションを確立し、PPPのサブプロトコルであるLCP(Link Control Protocol)のネゴシエーション、及び認証情報の送信を行っている。そのために、アクセスサーバとISPとの間は、PPPフレームをトンネリングする必要があった。
【０００５】
上記従来技術はL2TPが有するプロトコルスタックの深さ、即ちユーザIPパケットをPPP、L2TP、UDP(User Datagram Protocol)、IPでカプセル化することによる、アクセスサーバ及びISP/企業のゲートウエイ装置におけるカプセル/デカプセル処理負荷が大きい点について配慮がされておらず、そのため転送スループットが小さく、転送遅延が大きくなる問題があった。
【０００６】
【課題を解決するための手段】
本発明は、ユーザ端末からの送信情報に基づいてアクセスサーバが接続先網を選択する機能を損なうことなく、アクセスサーバ - 接続先ゲートウエイ装置間のカプセル化レベルを小さくし、転送スループットを大きく、転送遅延を小さくする技術を提供する。
【０００７】
本発明は、PPPoEを適用する場合に、PPPoEの接続手順によるアクセスサーバ -接続先ゲートウエイ装置間のトラフィック増加を抑える技術を提供する。
【０００８】
本発明は、アクセスサーバでPPPを終端しない場合でも、アクセスサーバでユーザを認識しユーザ毎の接続サービスを実現する技術を提供する。
【０００９】
本発明は、同一接続先ネットワークに属する接続先ゲートウエイ装置が複数存在する場合に、それらのトラフィック負荷を均等にし接続先ネットワークの同時接続ユーザ数を増加させる技術を提供する。
【００１０】
本発明は、既存設備のアクセスサーバを置き換えることなく、IPv6ネットワークへのアクセスを可能にする技術を提供する。
【００１１】
具体的には、本発明は、アクセスサーバに、接続先ネットワークのゲートウエイ装置とMAC(Media Access Control)フレームの送受信を行うためのMACフレーム送受信処理部と、上記接続先ネットワークのゲートウエイ装置のMACアドレスと該接続先ネットワークの識別情報を対応付ける接続先ネットワーク情報記憶処理部を設ける。
【００１２】
端末が接続先ネットワークのMACアドレスを問い合わせるために該接続先ネットワークの識別情報をアクセスサーバに送信すると、アクセスサーバは応答すべきMACアドレスを接続先ネットワーク情報記憶処理部で特定し、端末に応答する。これにより、ISP側ネットワークへの問い合わせのブロードキャストフレームの送信を削減できる。
【００１３】
また、本発明は、アクセスサーバに、端末が発行した、利用者が接続を望むISP名が設定してあるMACアドレス問い合わせパケット(PADI)を受け取り、当該ISP名を設定したPADI、または端末が発行した上記MACアドレス問い合わせパケット(PADI)と同一パケットをISP側ネットワークに送信する処理部を設ける。
【００１４】
上記接続先ネットワーク情報記憶処理部において、まだ対応付けができていない接続先ネットワークの識別情報を端末から受信した場合は、ISP側ネットワークに問い合わせを行い、その応答をもって対応付けを行う。
【００１５】
また、上記接続先ネットワーク情報記憶部に存在しない接続先ネットワーク識別情報を、接続先ネットワークのゲートウエイ装置が接続していると思われる回線に送出し、該当する接続先ネットワークのゲートウエイ装置からの応答を待つための応答待ち時間計測部を設け、接続先ネットワーク識別情報を上記回線に送出後、あらかじめ定めた規定時間内であってかつ応答受信前に、同一の接続先ネットワーク識別情報を端末から受信した場合は、上記回線に対する再度の識別情報の送出は行わない。
【００１６】
また、アクセスサーバでPPPを終端しない場合でも、アクセスサーバでユーザを認識しユーザ毎の接続サービスを実現するために、端末と上記接続先ネットワークのゲートウエイ装置で送受信されるPPP認証フレームを監視するPPP認証フレーム監視部と、上記PPP認証フレーム監視部で取得したユーザ情報とPPPoEセッションIDとの対応付けを記憶するセッションユーザ記憶部を設ける。
【００１７】
また、ユーザ情報対応にセッション制御パラメータを管理するユーザプロファイル管理部を設け、該ユーザプロファイル管理部に記憶する制御パラメータに基づいてセッション制御を行う。
【００１８】
また、同一接続先ネットワークに属する接続先ゲートウエイ装置が複数存在する場合に、それらのトラフィック負荷を均等にし接続先ネットワークの同時接続ユーザ数を増加させるために、接続先ネットワークのゲートウエイ装置毎にトラフィック量を計測するためのトラフィック量計測部と、複数のゲートウエイ装置を同一グループとして認識するためのゲートウエイグループ管理部を設け、端末からの接続要求があった場合に、同一グループ内でトラフィック量が少ない接続先ネットワークのゲートウエイ装置を選択する。
【００１９】
【発明の実施の形態】
以下、本発明の実施例を説明する。
【００２０】
（システム構成）
図1はユーザがユーザ側装置(PCという)1200を使用して、ISP1203またはインターネット1205にアクセスするためのネットワーク構成である。
【００２１】
TE100は、本実施例によるアクセスネットワーク装置(以下、Access Gateway、はAGという)101からみたユーザ端末（以下、TE、Terminal Equipmentという)である。PC1200とTE100とは、Ethernet（Ethernetは富士ゼロックス社の登録商標である）、RS232C、USB(Universal Serial Bus)などのインタフェースで接続される。PC1200とTE100とが一体型の場合もある。
【００２２】
TE100はアクセスネットワークを介してAG101と通信する。アクセスネットワークとしてはADSL1206、FTTH(Fiber to The Home)1207、ケーブルテレビ網1208などがある。
【００２３】
ADSL1206の場合、TE100はDSLMODEM（Digital Subscriber Line modem、DSLMDMという）1201に接続し、DSLMDM1201はメタルケーブルを介してDSLAM(Digital Subscriber Line Access Multiplexer)1202に接続し、DSLAM1202はAG101に接続する。AG101は中継ネットワークを介して複数のISP1203のゲートウエイ装置ISPGW102に接続する。ISP1203はインターネット1205に対してもゲートウエイ装置ISPGW1204を持つ。AG101は企業等のプライベート網PN1214とも、ゲートウエイ装置PNGW1213を介して接続できる。
【００２４】
アクセスネットワークがFTTH1207の場合は、TE100はONU(Optical Network Unit)1209、OLT(Optical Line Terminal)1210を介してAG101と接続する。
【００２５】
アクセスネットワークがケーブルテレビ網1208の場合はケーブルモデムCM(Cable Modem)1211、ケーブルモデム終端装置CMTS(Cable Modem Termination System)1212を介してAG101と接続する。アクセスネットワークとAG101とのインタフェースとしてはATM、Ethernetなどがある。
【００２６】
図2(a)にアクセスネットワークがADSLの場合の従来のプロトコルスタックを示す。
【００２７】
図2(a)では、PC1200とTE100とはEthernetで接続されており、ローカル網を形成している。TE100はNAT機能を有し、PC1200が送信したIPパケットの送信元IPアドレスをAG101から割り当てられたIPアドレスに変換する。TE100はPPPリンクを終端するが、そのリンクの対向する終端はL2TPでトンネリングされた先の接続先ISPのゲートウエイ装置ISPGW102である。TE100においてIPアドレス変換されたパケットはPPPフレーミングされたあと、PPPoEヘッダが付加され、MACフレームとしてDSLMDM1201に送信される。DSLMDM1201は受信したMACフレームをATMセル化し、DSLAM1202に送信する。本図ではDSLAM1202とAG101のインタフェースはATMとしているので、ATMセルはAG101にてもとのMACフレームに復元される。
【００２８】
AG101はPPPoEヘッダに基づいて内部のPPPフレームをL2TPセッションに乗せかえる。L2TPカプセル化されたPPPフレームはさらにUDPヘッダ、IPヘッダが付加された後、ISPGW102に送信される。ISPGW102では受信パケットからPPPフレームを取り出し、PPPプロトコル処理を行って内部のユーザIPパケットを取り出す。
【００２９】
AG101とISPGW102のインタフェースはEthernet以外にも、ATM、POS(Packet Over Sonet)等があるがIP以上のレイヤには影響しない。
【００３０】
TE100がISPへのアクセスを開始する場合、TE100は、ISPGW102ではなく、AG101との間でPPPoEセッションを確立する。そして、その上でPPPのサブプロトコルであるLCP(Link Control Protocol)のネゴシエーション、及び認証情報の送信を行う。
【００３１】
AG101は、受信した認証情報に基づいて接続先ISPのゲートウエイ装置を選択し、そのIPアドレスに対しL2TPトンネル/セッションの確立を行う。
【００３２】
ISPGW102はPPPのサブプロトコルであるIPCP(Internet Protocol Control Protocol)のネゴシエーションによりTE100に対しIPアドレスを割り当て、これによりPC1200はTE100、ISPGW102を介して目的のISPにアクセスできるようになる。
【００３３】
AG101は、L2TPセッションが切断するまでTE100から送信されるPPPフレームはISPGW102に転送、ISPGW102から送信されるPPPフレームはTE100に転送する。
【００３４】
このように、従来は、AG101がTE100から受信するPPPのユーザ認証情報に基づき接続先のISPGW102を選択している。そのために、PPPoEセッションをTE100とAG101との間で確立する必要があった。さらに、PPPによる通信をISPGW102とTE100の間で行うためには、AG101とISPGW102との間でPPPフレームをトンネリングする必要があった。
【００３５】
（実施例1）
本実施例では、TE100とAG101との間だけではなく、AG101とISPGW102の間のトンネリングプロトコルとしてもPPPoEを採用する。図2(b)にプロトコルスタックを示す。なお、ISPGW102は、PPPoEに対応しているものとする。
【００３６】
また、本実施例において、中継ネットワークは、IP網である必要はなく、MACフレームの転送機能を持つものとする。
【００３７】
EthernetのMACレイヤの下にATMあるいはPOSのレイヤを図示しているが、これは例えばギガビットイーサの場合には存在しない。
EthernetのMACレイヤ以上のプロトコルを図2(a)と比較すると、図2(a)ではIP、UDP、L2TPの3つであるのに対し、図2(b)ではPPPoEのみである。これはAG101、ISPGW102におけるプロトコル処理が図2(a)と比べて軽いことを示している。
【００３８】
（AGの構成例）
図3に、本実施例を実現するAG101の構成例を示す。
【００３９】
AG101は物理回線収容カード(Line Interface、以下LIFという)1100、上位レイヤ処理カード(High Layer Module、以下HLYR-MDLという)1103、スイッチSW1108、装置制御カード(Controler、以下CTLという)1109からなる。
【００４０】
まず、AG101外部からの信号はLIF1100の物理レイヤ(Physical Layer、以下PHYという)チップ1101で整形されたディジタルな電気信号となり、下位レイヤプロトコル処理部(Low Protocol、以下LOWPROTという)1102に入力される。LOWPROT1102では、回線種別がATMやPOSの場合にそれらのプロトコル処理を行った後、上位プロトコルのMACフレームをHLYR-MDL1103に送信する。HLYR-MDL1103では受信したMACフレームの転送処理をMACレイヤ処理部(MAC frame Forwarding、以下MACFWDという)1107で行う。MACFWD1107で管理するアドレステーブルを図5に示す。
【００４１】
図5に示したアドレステーブル1000は、AG101が有する回線に接続している外部装置のMACアドレス1001とその回線ID1002とMACアドレスがISPかTEかを識別するISPフラグ1003からなる。回線ID1002は、物理回線がEthernetの場合は物理回線毎に付与し、ATMの場合はVC毎に付与する識別子である。MACFWD1107がMACフレームを受信すると、アドレステーブル1000を参照し、フレームの宛先MACアドレスから送出先の回線IDを特定し、それに基づいてSW1108を介して目的のHLYR-MDL1103に転送する。転送先のHLYR-MDL1103でも同様にアドレステーブル1000を参照し、回線IDから送出先となるLIF1100、物理ポートを特定し、LOWPROT1102、PHY1101を介してAG101外に送信する。ISPフラグ1003はPPPoEパケットのブロードキャストを行う場合の対象回線を識別するのに用い、詳しくは後述する。
【００４２】
図3において、MACFWD1107は高機能プロトコル処理部(Proccessing unit、以下PROCという)1104と接続している。PROC1104はPPPoEの制御パケットのうち特定のものを受信し、セッション制御、フレームのカプセル化方法をMACFWD1107に指示する。PROC1104が受信を期待するパケットはMACFWD1107が識別してPROC1104に転送する。PROC1104は上記処理を行うCPU1106とDB1105を有する。DB1105はTE100が接続要求の際に送信してくるISPの識別子と、その識別子に対応づけられた接続先ゲートウエイ装置のMACアドレスを管理するキャッシュテーブル900を保持する。
【００４３】
図4にキャッシュテーブル900を示す。キャッシュテーブル900はISPの識別子であるServiceName901と、ゲートウエイ装置のMACアドレス902と、エントリの残り有効時間903と、MACアドレス問い合わせパケット（PPPoE Active Discovery Initiation(PADI)パケット）の送信を抑止する送信ガードタイム904からなる。PROC1104のCPU1106はキャッシュテーブル900に基づいてPPPoEの制御パケット受信処理を行う。CTL1109はAG101全体の装置制御を行う。処理実行部としてのCPU1111と、制御に必要な情報を保持するDB1110を有する。
【００４４】
（実施例1-1）
実施例1において、AG101がPPPoEのブリッジとして動作する実施例を示す。
【００４５】
図6、図9、図10に、本実施例のメッセージシーケンスを示す。本実施例では、TE100はAG101をMACレイヤでの対向ノードとは認識せず、接続先ISP1（102）のゲートウエイ装置を対向ノードとして認識する。一方、ISP1（102）からは、同一セグメントにTE100とAG101が接続しているように見える。
【００４６】
図6はAG101がキャッシュテーブル900に保持していないISPに対する接続をTE100が要求した場合の接続シーケンスである。概要としては、TE100が接続先ISP1（102）のMACアドレスを取得するフローがPADI103、PADO(PPPoE Active Discovery Offer)108の送受信であり、続いて実際のPPPoEセッションを確立するフローがPADR(PPPoE Active Discovery Request)110、PADS(PPPoE Active Discovery Session-confirmation)111の送受信であり、その後、PPPoEセッション上でPPPのネゴシエーション112を行う。
【００４７】
まず、PPPoEパケットとTAG3109のフォーマットを説明し、次に、図6を詳細に説明する。
【００４８】
図7にPPPoEパケットのフォーマットを示す。PPPoEパケット3100はEtherタイプ3103の値が0x8863あるいは0x8864のMACフレームである(0xは16進数を示す)。宛先MACアドレス3101はPPPoEのパケットタイプがPADIの場合はブロードキャストアドレス、それ以外は宛先装置のユニキャストアドレスである。本実施例においては、PADOの送信元MACアドレス3102には、本来のPPPoEパケットの送信元アドレスではなく、ISPのゲートウエイ装置のアドレスに設定する。
【００４９】
Ver3104にはPPPoEのバージョンを設定する。type3105には1を設定する。code3106はPPPoEパケットのタイプを示し、この値によりPADI、PADO、PADR、PADS、PADT(PPPoE Active Discovery Terminate)の各種パケットが識別できる。セッションID3107はカプセル化するPPPフレームが属するPPPセッションを識別するためのIDである。Length3108はPPPoEペイロード長を示す。PPPoEペイロードは、Etherタイプ3103の値が0x8863の場合、すなわち制御パケットの場合はTAG3109であり、Etherタイプ3103の値が0x8864の場合、すなわちPPPフレームカプセル化パケットの場合はPPPフレーム3110である。PPPoEの制御パケットの場合、TAG3109は複数個含まれる場合がある。
【００５０】
チェックサム3115はMACフレームフォーマットとして規定されているチェックサムである。PPPフレーム3110のフォーマットとしては、プロトコル3111の内容がIPを示しているか、PPP制御フレームを示しているかによって異なる。前者の場合、プロトコル3111の後ろにはユーザIPパケット3114が設定される。後者の場合は、プロトコル3111に示されたPPPの各種サブプロトコル毎に定義されているメッセージ種別を示すコード3112と、その他情報3113が設定される。
【００５１】
図8にTAG3109のフォーマットを示す。TAG3109はTAGタイプ3200、TAGLength3201、TAGValue3202からなる。PADI103に設定するISP名はServiceNameTAG（TAGタイプ3200の値は0x0101）のTAGValueフィールドに設定する。
【００５２】
次に、図6を説明する。
【００５３】
TE100はPPPoEのPADIパケット103をブロードキャストのMACアドレス宛に送信する。PADI103には、PC1200の利用者が接続を望むISP名としてISP1が設定してある。
【００５４】
AG101がPADI103を受信すると、PADI103内に設定されているISP名（この場合はISP1）がキャッシュテーブル900に登録されているかチェックする（ステップ104）。
【００５５】
未登録の場合、キャッシュテーブル900に新しいエントリとしてServiceName901がISP1、残り有効時間903が0、送信ガードタイム904が例えば数秒のものを登録する（ステップ105、106）。
【００５６】
その後AG101はTE100から受信したPADI103と同一のパケットをPADI107としてAG101外にブロードキャストするが、このときアドレステーブル1000内のISPフラグ1003がISPと示されている回線に対してのみ送出する。これにより、ブロードキャストメッセージであるPADIをTE側へ無駄に送信することが無くなる。なお、ISPフラグ1003は、ネットワークを構築する際、保守者がコマンド操作で意識的に設定する。
【００５７】
ISP1（102）がPADI107を受信すると、PADI107に示されたISP名が自分と一致することを認識して、PADIの送信元MACアドレス、すなわちTE100に対してPADO108を送信する。これにより、ISPGW102が選択されたことになる。
【００５８】
AG101はPADOを受信すると宛先MACアドレスでアドレステーブル1000を検索し、TE100に転送するとともに、キャッシュテーブル900のMACaddr902にISP1（102）のMACアドレスAiを、残り有効時間903に例えば3600を、送信ガードタイム904に0を設定する。
【００５９】
PADO108を受信したTE100はAG101を介してISP1（102）に対しPADR110を送信し、ISP1はTE100にPADS111を送信する。これによって、TE100とISP1（102）との間にPPPoEセッションを確立する。
【００６０】
その後TE100とISP1（102）の間でPPPネゴシエーション112を実施することにより、IPパケット通信113が可能となる。
【００６１】
なお、ユーザ認証をAG101が行わないので、AG101では一見ユーザ管理が出来ないように見えるが、TE100に接続し各家庭に設置するDSLMDM1201とAG101の間にあらかじめ設定するATMのVPI/VCIに基づき、どのサービス加入者がアクセスしているかといった管理は可能である。
【００６２】
このように、上記シーケンスに依れば、PPPoEのMACアドレス問い合わせフェーズにおいて、アクセスサーバがISP網のゲートウエイ装置のMACアドレスをキャッシュテーブルに格納することができ、以後、他の端末からのそのISPに対する問い合わせに対しては、図9で説明するようにアクセスサーバがゲートウエイ装置にかわって応答できるので、アクセスサーバ-ISPゲートウエイ装置間のトラフィック量を小さくする効果がある。
【００６３】
次に、図9を用いて、その他の状況に於けるシーケンスを説明する。
【００６４】
図9において、AG101がISPのゲートウエイ装置のMACアドレスを問い合わせている最中に、そのISPに対する接続をTE100が要求した場合のシーケンスを説明する。TE100がISP1（102）を指定してPADI103をAG101に送信すると、AG101はステップ104にてキャッシュテーブル900内にISP1（102）のエントリがあるか検索する。キャッシュテーブル900にエントリがある場合は、残り有効時間903の値が正か否かを判定し（ステップ200）、
正でない場合は、（それにもかかわらずエントリが存在するということは）すでに同一のISP1（102）に対して図6で示したAG101からのPADI107が送信された後ということになるので、今回あらたにTE100から受信したPADI103は廃棄する（ステップ201）。
【００６５】
TE100が、AG101がISP1（102）に対しPADI107を送信するきっかけとなった端末と異なる端末の場合でも、AG101から同一ISP1へのPADI送信は冗長であるので抑止する。
【００６６】
図9において、AG101がキャッシュテーブル900にMACアドレスを保持しているISPに対する接続要求をTE100が行った場合のシーケンスを説明する。TE100がPADI103を送信すると、AG101はステップ104にてキャッシュ登録済みか判定し、登録済みの場合は残り有効時間903が正の値であるか判定する（ステップ200）。
【００６７】
正の値である場合はキャッシュテーブル900に登録されているISP1（102）のMACアドレスは有効と認識して、ISP側にPADI103を送信することなく、TE100に対してPADO300を送信する。これにより、無駄なブロードキャストメッセージを送らずに済み、ネットワークトラフィックを増やすということが無くなる。このパケットの送信元アドレスはキャッシュテーブル900内のMACaddr902である。PADO300を受信したTE100は以下図6と同様のシーケンスを経てISP1（102）とのIPパケット通信が可能となる。
【００６８】
TE100からの切断シーケンスでは、TE100が送信元MACアドレスをAt、送信先MACアドレスをAiとしたPADTを送信すると、AG101はそれをISP1（102）に転送する。ISP1（102）ではそれを受信し、TE100とのPPPリンク及びPPPoEセッションの切断処理を実施する。
【００６９】
ISP1（102）からの切断シーケンスでは、ISP1（102）が送信元MACアドレスをAi、送信先MACアドレスをAtとしたPADTを送信するとAG101はそれをTE100に転送する。TE100ではそれを受信し、ISP1（102）とのPPPリンク及びPPPoEセッションの切断処理を実施する。
【００７０】
図10はAG101が有するキャッシュテーブル900のエントリの残り有効時間903が規定値以下になった場合にAG101が送信元となってISP1（102）のMACアドレスを問い合わせるシーケンスである。
【００７１】
AG101は問い合わせが必要になった場合、ステップ106にてキャッシュテーブル900の送信ガードタイム904に例えば数秒を設定し、ブロードキャストMACアドレス宛にPADI601を送信する。実際に送出する回線としては、アドレステーブル1000にてISPフラグ1003がISPとなっているもの全てとする方法と、残り有効時間903が正の値である間はMACaddr902で特定される回線のみとする方法がある。なお、このパケットの送信元MACアドレスはAG101のアドレスである。
【００７２】
ISP1（102）がPADI601を受信すると、その送信元MACアドレス宛にPADO602を送信する。
【００７３】
AG101はPADO602を受信すると、ステップ109にてキャッシュテーブル900の残り有効時間903とMACaddr902を設定し、さらに送信ガードタイム904をクリアする。
【００７４】
本シーケンスにより、TE100からのPADIを受信しなくともAG101が定期的にISPのMACアドレスを確認でき、TE100からPADIを受信した際に速やかにPADOを返送することが可能になる。
【００７５】
以上のように本実施例によれば、接続端末のMACアドレスがISPに伝わるので、MACアドレスに基づいた制御（フィルタリング、優先制御）などをISPが独自に行うことができる。
【００７６】
（実施例1-1-1）
本実施例は、実施例1-1において、パケット受信をトリガとして図6、図9、図10のシーケンスを実施するAG101の処理を説明するものである。図11にその処理フローを示す。
【００７７】
本処理は図3のPROC1104及びMACFWD1107で実施する。パケット受信待ち700の状態において、PADI受信（分岐701）、PADO/PADS受信（分岐703）については、PROC1104で処理するため、MACFWD1107はこれらのパケットについては無条件にPROC1104に転送する。PADR/PADT/その他のMACフレームについては通常のLANスイッチの処理でよいのでPROC1104とは無関係にMACFWD1107で実行する。
【００７８】
まずPADI受信（分岐701）の場合、PROC1104はDB1105内に格納するキャッシュテーブル900にPADIに設定されているISP1に該当するエントリがあるかチェックする（ステップ104）。
【００７９】
エントリが無かった場合、エントリを追加し（ステップ105）、
送信ガードタイム904を設定し（ステップ106）、
受信したPADIパケットをMACFWD1107に転送する。MACFWD1107ではパケットがPADIであることを認識してアドレステーブル1000のISPフラグ1003がISPとなっている回線に対して本パケットを送出する（ステップ107）。
【００８０】
ステップ104にてキャッシュテーブル900にISP1のエントリが存在した場合、残り有効時間903が正の値かをチェックする（ステップ200）。
【００８１】
正の値の場合はキャッシュテーブル900のMACaddr902を送信元MACアドレスとしたPADOパケットを、PADIパケットの送信元アドレス宛に送信する。PROC1104からMACFWD1107に転送されたPADOパケットはアドレステーブル1000に基づいて特定の回線から送出される（ステップ300）。
【００８２】
ステップ200において残り有効時間903が正の値で無かった場合は受信パケットを廃棄する（ステップ201）。
【００８３】
PADO/PADS受信（分岐703）の場合、PROC1104はステップ705にてキャッシュテーブル900内にISP1のエントリがあることをチェックし、エントリがない場合は新規作成する（ステップ105）。
【００８４】
ステップ706にて残り有効時間903、MACaddr902を設定し、ステップ707にて送信ガードタイム904を0クリアする。ステップ705にてキャッシュテーブル900にISP1のエントリがあった場合はステップ706に進む。ステップ707の後、受信パケットがAG101のMACアドレス宛か否かの判定を行う（ステップ708）。
【００８５】
AG101宛でなければ、MACFWD1107にパケットを転送し、アドレステーブル1000に基づいた回線から送出する（ステップ709）。
【００８６】
ステップ708にてAG101宛であった場合は処理は終了する。PADR/PADT/その他のMACフレーム受信（分岐702）の場合はMACFWD1107がアドレステーブル1000に基づいて通常のMACフレーム転送処理を行う（ステップ704）。
【００８７】
（実施例1-1-2）
本実施例は、実施例1-1において、周期起動をトリガとして図6、図9、図10のシーケンスを実施するAG101の処理を説明するものである。図12にその処理フローを示す。
【００８８】
周期起動待ち800の状態から起動がかかると、PROC1104はキャッシュテーブル900内の全てのISPに関するエントリについて、個々に以下の処理を行う。
【００８９】
送信ガードタイム904の値が正か否かをチェックする（ステップ801）。
【００９０】
正の場合は値を減算し（ステップ805）、
その結果が正か否かの判定を行う（ステップ806）。
【００９１】
正でない場合はAG101がISPに送信したPADIに対する応答のPADOが規定時間内に戻ってこなかったことになるのでキャッシュテーブル900からエントリを削除する（ステップ807）。
【００９２】
ステップ806にてガードタイムの減算結果が正の場合は、残り有効時間903が正の値かチェックし（ステップ808）、
正の値であれば値を減算する（ステップ809）。
【００９３】
正の値でなければそのISPのエントリに関する処理を終了する。ステップ801にて送信ガードタイム904が正の値でない場合、すなわちISPに対してMACアドレスの問い合わせを行っていない場合、ステップ802にて残り有効時間903の値が正か否かを判定する。正の場合は値を減算し（ステップ803）、
結果が規定値nより大きいか判定する（ステップ804）。
【００９４】
ここでnはエントリ削除のどれくらい前からISPへのMACアドレス問い合わせを開始するかを決定する値であり、あらかじめ定義しておく。残り有効時間903がnより大きい場合はまだ問い合わせが不要であるので、そのエントリに対する処理は終了する。ステップ804にて残り有効時間903がn以下であった場合は送信ガードタイム904を設定して（ステップ600）、
MACaddr902宛にPADIパケットを送信する（ステップ601）。
【００９５】
PROC1104はPADIパケットをMACFWD1107に転送し、MACFWD1107はアドレステーブル1000を参照してISPフラグ1003がISPとなっている全ての回線からパケットを送出する。ステップ802にて残り有効時間903が正の値でなければステップ106に進み、PADI送信処理を行う。
【００９６】
（実施例1-2）
実施例1において、AG101がTE側インタフェースとISP側インタフェースの両方にMACアドレスを有し、TE101 - AG101間と、AG101 - ISPGW102間に別々のPPPoEセッションを確立する場合の実施例を示す。
【００９７】
図13から図23を用いて本実施例を説明する。
【００９８】
図13はAG101がキャッシュテーブル900に保持していないISPに対する接続をTE100が要求した場合の接続シーケンスである。
【００９９】
TE100がPADI103をAG101に送信すると、AG101はキャッシュテーブル900を参照してISP1が登録済みかチェックする（ステップ104）。
【０１００】
未登録の場合、新規にエントリを追加し（ステップ105）、
送信ガードタイム904を例えば数秒に設定する（ステップ106）。
【０１０１】
さらに本実施例ではどのTEに対しPADO送信しなくてはならないかを管理するPADIテーブルを設定する（ステップ1800）。
【０１０２】
図14にPADIテーブルを示す。PADIテーブル2600はMACアドレス問い合わせ中のISPの識別子であるServiceName2601と、PADI送信元すなわち問い合わせ要求を行ったTEのアドレスTEaddr2602と、AG101がISPからのPADOを待つ残り時間のPADO待ち時間2603からなる。本テーブルはPROC1104のDB1105で保持する。
【０１０３】
図13においてステップ1800ではPADIに設定されているISPの識別子ISP1をServiceName2601に、送信元アドレスをTEaddr2602に、PADO待ち時間2603には例えば数秒を設定する。その後、送信元MACアドレスがAG101のPADI1801をISP1（102）に送信する。ISP1（102）はPADI1801を受信すると、送信元MACアドレスがISP1（102）のPADO1802をAG101に送信する。AG101がPADO1802を受信すると、キャッシュテーブル900の残り有効時間903にこのエントリの有効時間を、MACaddr902にISP1（102）のMACアドレスを、送信ガードタイム904に0を登録する（ステップ110）。
【０１０４】
その後AG101はPADIテーブル2600を参照してTE100宛のPADO1803を送信し、PADIテーブル2600の該当エントリを削除する（ステップ1804）。
【０１０５】
PADO1803を受信したTE100はPADO1803の送信元アドレスであるAG101宛にPADR1805を送信する。AG101はPADR1805を受信すると、どのTEに対しPADSを送信しなくてはならないかを管理するPADRテーブルを設定する（ステップ1806）。
【０１０６】
図15にPADRテーブルを示す。PADRテーブル2700は接続要求先ISPの識別子であるServiceName2701と、PADR送信元のTEaddr2702と、接続要求先ISPからのPADSを待つ残り時間を示すPADS待時間2703からなる。本テーブルはPROC1104のDB1105で保持する。
【０１０７】
図13においてAG101はPADRテーブル2700の設定後、ISP1（102）に対してAG101を送信元アドレスとしたPADR1807を送信する。ISP1（102）はPADR1807を受信すると、AG101-ISP1（102）間でセッションを識別するためのセッションIDを割り当て、それを設定したPADS1808をAG101宛に送信する。AG101はTE100に対してTE100-AG101間でセッションを識別するためのセッションIDを割り当て、PADS1808で通知されたセッションIDと共にセッション管理テーブルに登録する。
【０１０８】
図16にセッション管理テーブルを示す。セッション管理テーブル2200はTEaddr2201、AG101からみたTE側セッションID2202、ISPaddr2203、ISP側セッションID2204、セッションを使用するユーザ名2205からなる。ユーザ名2205はPPPネゴシエーション中にTE100とISP1（102）の間で送受信されるPPP制御フレームをAG101がモニタすることにより認識できるものであり、その実施例については後述する。
【０１０９】
このテーブルは、セッション確立後はユーザパケットを１個転送するたびに参照される。したがって、専用LSIで構成することが望ましいMACFWD1107と、ユーザ名に基づいた複雑な処理を行うPROC1104それぞれが、本テーブルを保持することが望ましい。
【０１１０】
本テーブルを装置へ実装する場合は、ユーザ名のエントリの代わりにインデックスを設けたテーブルをMACFWD1107が保持し、そのインデックスとユーザ名を対応付けたテーブルをPROC1104が保持するように構成しても良い。
【０１１１】
MACFWD1107は本テーブルを用いて、TE100から送信されるPPPoEパケットのヘッダを付け替えてISP1（102）に転送する、あるいはその逆の転送を行い、PROC1104は、本テーブルを用いて、ユーザ個別のプロファイル情報とリンクさせてセッションを制御する。
【０１１２】
図13においてAG101はセッション管理テーブル2200を設定（ステップ1809）した後、PADRテーブル2700に基づいてTE100宛にPADS1810を送信し、PADRテーブル2700から送信済みTEに関するエントリを削除する（ステップ1811）。
【０１１３】
TE100がPADS1810を受信した時点でPPPoEセッションが確立し、TE100は、ISP1（102）との間でPPPネゴシエーション112を実施する。これによりIPパケット通信113が可能になる。
【０１１４】
図17はAG101がキャッシュテーブル900にMACアドレスを保持しているISPに対する接続要求をTE100が行った場合のシーケンスである。ステップ200までは図9と同様である。ステップ200においてキャッシュテーブル900の残り有効時間903が正の値の場合は、AG101は送信元アドレスがAG101のPADO1803をTE100に送信する。TE100がPADO1803を受信したあとのシーケンスは図13と同様である。
【０１１５】
TE100からの切断シーケンスを説明する。TE100が、送信元をTE100、送信先をAG101としたPADTをAG101宛に送信すると、AG101はPADT内のセッションID3107をキーとしてセッション管理テーブル2200のTE側セッションID2202を検索、一致したエントリに基づいてPADTのヘッダ内容を変更して送信元をAG101、送信先をISPGW102としたPADTをISP1（102）宛に送信する。さらに、参照したエントリを削除する。
【０１１６】
ISP1（102）からの切断シーケンスを説明する。ISP1（102）が、送信元をISPGW102、送信先をAG101としたPADTをAG101に対して送信するとAG101はPADT内のセッションID3107をキーとして、セッション管理テーブル2200のISP側セッションID2204を検索、一致したエントリに基づいてPADTのヘッダ内容を変更し、送信元をAG101、送信先をTE100としたPADTをTE100宛に送信する。さらに、参照したエントリを削除する。
【０１１７】
（実施例1-2-1）
本実施例は、実施例1-2において、パケット受信をトリガとして図13、図17のシーケンスを実施するAG101の処理を説明するものである。図18、図19にその処理フローを示す。
【０１１８】
本処理は図3のPROC1104及びMACFWD1107で実施する。パケット受信待ち2300の状態において、PADI受信（分岐2301）、PADR受信（分岐2302）、PADO/PADS受信（分岐2303）、PADT受信（図19分岐2401）はPROC1104で処理するため、MACFWD1107が受信時にPROC1104に転送する。PPPフレーム受信（図19分岐2400）はMACFWD1107で処理する。まずPADI受信（分岐2301）の場合、PROC1104はキャッシュテーブル900に接続先ISPのエントリがあるかチェックし（ステップ104）、
ない場合は新規に作成し（ステップ105）ServiceName901と送信ガードタイム904を設定し（ステップ106）、
さらにPADIテーブル2600を設定して（ステップ1800）PADIの送信元アドレスをAGに変えた後MACFWD1107にパケットを転送する。MACFWD1107ではアドレステーブル1000のISPフラグ1003がISPと示される回線に対してPADIを送信する（ステップ1801）。
【０１１９】
ステップ104にてキャッシュテーブル900に対象のISPのエントリがある場合、残り有効時間903が正の値か判定する（ステップ200）。
【０１２０】
正の値の場合は送信元アドレスをAG101としたPADOをTE100に送信する（ステップ1803）。
【０１２１】
正の値でない場合は受信パケットを廃棄する（ステップ201）。
【０１２２】
パケット受信待ち2300状態からPADO/PADS受信（分岐2303）の場合は、キャッシュテーブル900にISP1のエントリが存在するか検索し（ステップ705）、
存在しなかった場合は新規にISP1のエントリを作成し（ステップ105）、
残り有効時間903と、MACaddr902を設定し（ステップ706）、
送信ガードタイム904をクリアする（ステップ707）。
【０１２３】
ステップ705にてISP1に関するエントリが存在する場合は、ステップ706に進む。ステップ707の後、受信パケットの種別を判定する（ステップ2305）。
【０１２４】
受信パケットがPADOの場合はPADIテーブル2600を検索し、応答待ちとなっているTEがあるかチェックする（ステップ2306）。
【０１２５】
応答待ちのものがなければ処理を終了する。応答待ちのものがあればPADIテーブル2600に基づいてTEaddr2602宛にPADOを送信する（ステップ1803）。
【０１２６】
その後PADIテーブル2600から送信済みTEに関するエントリを削除する（ステップ1804）。
【０１２７】
PROC1104がMACFWD1107に転送したPADOパケットは、アドレステーブル1000に基づいて回線に送出される。ステップ2305にて受信パケットがPADSであった場合は、セッション管理テーブル2200に新たなエントリを作成し、PADRテーブル2700のTEaddr2702をセッション管理テーブル2200のTEaddr2201に設定し、受信PADSパケットの送信元MACアドレス3102をISPaddr2203に、セッションID3107をISP側セッションID2204に設定する。そしてAG101が割り当てたセッションIDをTE側セッションID2202に設定する（ステップ1809）。
【０１２８】
本テーブルはMACFWD1107にも設定する。そしてPADRテーブル2700にて応答待ちとなっているTEに対しPADSを送信し（ステップ1810）、
そのTEに関するエントリを削除する（ステップ1811）。
【０１２９】
パケット受信待ち2300状態からPADR受信（分岐2302）の場合は、ステップ2304にてキャッシュテーブル900に接続先ISP1に関するエントリが存在するかチェックし、存在しなければ受信パケットを廃棄する（ステップ201）。
【０１３０】
存在した場合はその情報に基づいてPADRテーブル2700を設定する（ステップ1806）。
【０１３１】
ServiceName2701には受信したPADRパケットに示されたISP1を、TEaddr2702には送信元MACアドレスを、PADS待ち時間2703には例えば数秒を設定する。そしてPADRをISP1に送信する（ステップ1807）。
【０１３２】
パケット受信待ち2300の状態からPPPフレーム受信（分岐2400）の場合は、MACFWD1107にてセッション管理テーブル2200に基づいてパケットの宛先MACアドレス3101、送信元MACアドレス3102、セッションID3107を変更したあと、アドレステーブル1000を参照してパケットを回線に送出する（ステップ2402）。
【０１３３】
パケット受信待ち2300の状態からPADT受信（分岐2401）の場合は、PROC1104にてセッション管理テーブル2200を参照してパケットの宛先MACアドレス3101、送信元MACアドレス3102、セッションID3107を変更して送信する（ステップ2403）。
【０１３４】
その後、PROC1104、MACFWD1107にそれぞれ存在するセッション管理テーブル2200から対象セッションのエントリを削除する（2404）。
【０１３５】
（実施例1-2-2）
本実施例は、実施例1-2において、周期起動をトリガとして図13、図17のシーケンスを実施するAG101の処理を説明するものである。図20にその処理フローを示す。ただし、図12の処理に加えて必要な分のみを示している。周期起動待ち2500の状態から起動がかかると、PADI(PPPoE Active Discovery Initiation)テーブル2600内のPADO(PPPoE Active Discovery Offer)待ち時間2603を減算する（ステップ2501）。
【０１３６】
その結果、正の値でなくなったエントリについてはテーブルから削除する（ステップ2502）。
【０１３７】
PADR(PPPoE Active Discovery Request)テーブル2700についても同様にPADS(PPPoE Active Discovery Session-confirmation)待ち時間2703を減算し（ステップ2503）、
PADS待ち時間が正の値でなくなったエントリを削除する（ステップ2504）。
【０１３８】
（実施例2）
本実施例は、PPPoEセッションをTE100とISPGW102との間で確立し、AG101とISPGW102の間のトンネリングプロトコルとしてL2TPではなくPPPoAとするものである。図2(c)にプロトコルスタックを示す。この場合、PPPの下位レイヤはATMである。
【０１３９】
また、ISPGW102は、PPPoAをサポートしているものとする。
【０１４０】
図2(a)におけるAG101とISPGW102のインタフェースがIPoverEtherではなく、IPoverATMだった場合と比較すると、ATMレイヤより上のプロトコルは図2(a)ではIP、UDP、L2TP、PPPであるのに対し、図2(c)ではPPPのみである。これはAG101、ISPGW102におけるプロトコル処理が図2(a)と比べて軽いことを示している。
【０１４１】
図21は、AG101がTE100とはPPPoEで通信し、ISP1（102）とはPPPoAで通信する場合の実施例のメッセージシーケンスを示す。
【０１４２】
TE100がAG101にPADI103を送信すると、AG101はISPテーブルを参照する。
【０１４３】
図22にISPテーブルを示す。ISPテーブル3000はPROC1104とMACFWD1107の両方で保持し、PROC1104はAG101があらかじめATM回線で接続するISPそれぞれに関し、VCの空き状況を管理するために使用する。また、MACFWD1107は、PPPoEセッションでTEから受信したパケット内のPPPフレームをどのVCに転送すればよいか、あるいはその逆の処理に使用する。
【０１４４】
テーブルは接続先ISPの識別情報ServiceName3001と、接続に使用する物理ポート3002、VPI/VCI(Virtual Path Identifier/Virtual Channel Identifier)3003、そのVCを使用するPPPoEセッション情報としてTEaddr3004とセッションID3005、セッション使用ユーザ名3006からなる。このうち、ServiceName3001、物理ポート3002、VPI/VCI3003はATM回線設定を行った時点で設定する。
【０１４５】
ひとつのVCがひとつのPPPoEセッションに対応し、TE100がAG101に接続してきた時点でTEaddr3004、セッションID3005、ユーザ名3006がテーブルに設定される。各VCが使用中か否かの識別は例えばTEaddr3004の値が0以外か否かで行う。ユーザ名3006はPPPネゴシエーション中にTE100とISP1（102）の間で送受信されるPPP制御フレームをAG101がモニタすることにより認識できるものであり、その実施例については後述する。
【０１４６】
図21においてAG101はPADI103を受信すると、図22を参照し、指定されたISPに接続しているVCに空きがあるかチェックする（ステップ2800）。
【０１４７】
空きが無ければ受信パケットを廃棄する（ステップ2801）。
【０１４８】
空きVCがあった場合はTE100からの接続要求は受け付け可能であるので送信元アドレスとしてAG101を設定したPADO1803をTE100宛に送信する。PADO1803を受信したTE100はPADR1805をAG101に対し送信する。AG101は再度ISPテーブル3000を検索し（ステップ2802）、
空きVCが無ければパケットを廃棄する（ステップ2803）。
【０１４９】
空きVCがある場合、ISPテーブル3000内で選択したVCのエントリに対し、TEaddr3004、セッションID3005を登録する（ステップ2804）。
【０１５０】
その後AG101はPADS1810をTE100に対して送信する。TE100がPADS1810を受信すると、ISP1（102）との間でPPPネゴシエーション112を行い、IPパケット通信113が可能となる。
【０１５１】
TE100からの切断シーケンスを説明する。TE100がPADT2000をAG101に送信すると、AG101はPADTに設定されているセッションID3107をキーにISPテーブル3000を検索し、該当エントリを削除することでVCを空き状態に戻す。
【０１５２】
図23は図21のシーケンスを実現するためのAG101の処理フローである。本処理は図3のPROC1104及びMACFWD1107で実施する。パケット受信待ち4000の状態から、PADI受信（分岐4001）、PADR受信（分岐4002）、PADT受信（分岐4004）はPROC1104で処理し、PPPフレームすなわちPPPoE制御パケット以外の受信（分岐4003）はMACFWD1107で処理する。
【０１５３】
まず、PADI受信（分岐4001）の場合、ISPテーブル3000を検索し、接続要求のあったISP向けのVCに空きがあるかチェックする（ステップ2800）。
【０１５４】
空きVCがあった場合はPADOをTE宛に送信する（ステップ1803）。
【０１５５】
PROC1104はMACFWD1107にパケットを転送し、アドレステーブル1000に基づいて回線に送出する。ステップ2800にて空きがなかった場合は受信パケットを廃棄する（2801）。
【０１５６】
PADR受信（分岐4002）の場合は、ステップ2802にてステップ2800同様ISPテーブル3000を検索する。空きVCがあればISPテーブル3000にAG101が割り当てるセッションID3005と、TEaddr3004を登録する。登録はMACFWD1107が保持するテーブルに対しても行う（ステップ2804）。
【０１５７】
そしてTEに対してPADSを送信する。PROC1104はMACFWD1107にパケットを転送し、MACFWD1107はアドレステーブル1000に基づいて回線に送出する（ステップ1810）。
【０１５８】
ステップ2802にて空きVCがなかった場合は受信パケットを廃棄する（ステップ2803）。
【０１５９】
PADT受信（分岐4004）の場合は、パケット内のセッションID3107で特定されるセッションの情報をISPテーブル3000から削除し、それまで使用していたVCを空きにする。削除はMACFWD1107が保持するテーブルに対しても行う（ステップ2900）。
【０１６０】
PPPフレーム受信（分岐4003）の場合は、MACFWD1107が保持するISPテーブル3000を参照してPPPフレームのカプセル/デカプセル処理を行い、TE100とISP1（102）のPPP通信を実現する（ステップ4005）。
【０１６１】
（実施例3）
本実施例では、TE100とISP1（102）の間で行うPPPネゴシエーションにおいてセッションのユーザの認証シーケンスを示す。
【０１６２】
図24は、図6、図13、または図21の各実施例におけるPPPネゴシエーションのフェーズを詳細に説明する図である。
【０１６３】
まず、TE100とISP1（102）はPPPのサブレイヤであるLCPのネゴシエーション3300を実施する。
【０１６４】
その後、ISP1（102）はユーザ認証を行うための認証乱数を有するCHAP(Challenge Handshake Authentication Protocol) Challengeメッセージ3301をTE100に送信する。
【０１６５】
TE100はユーザ名と乱数に対して行った演算結果をCHAP Responseメッセージ3302に設定して、AG101経由でISP1（102）に送信する。
【０１６６】
AG101は当該メッセージを認識するとユーザ名を取得し、セッションユーザ情報テーブル3900（図25）のユーザ名3904（図6に示す実施例1-1の場合）、またはセッション管理テーブル2200（図16）のユーザ名2205（図13に示す実施例1-2の場合）、またはISPテーブル3000（図22）のユーザ名3006（図21に示す実施例2の場合）に登録する（ステップ3303）。
【０１６７】
なお、セッションユーザ情報テーブル3900のTEaddr3901、セッションID3902、ISPaddr3903にはCHAP Responseメッセージ3302をカプセル化しているPPPoEパケットの送信元MACアドレス3102、セッションID3107、宛先MACアドレス3101をそれぞれ設定する。本テーブルはPROC1104のDB1105で管理する。
【０１６８】
ISP1（102）は認証が成功した場合はCHAP Successメッセージ3304をTE100に対して送信する。AG101はこのCHAP Success3304を受信し、ユーザが確定したとき、上記のいずれかのテーブルに設定したユーザ名が正しいと判断して、ユーザ毎の固有の制御を開始する。例えばPROC1104はMACFWD1107に対象セッションの統計情報カウントを指示する(ステップ3305)。
【０１６９】
TE100がCHAP Success3304を受信すると、TE100はPPPのサブレイヤであるIPCPのネゴシエーション3306を行い、IPパケット通信113が可能となる。一方PPPセッションを終了するとき、すなわちLCP Term-req(LCP Terminate-Request)メッセージ3308がTE100-ISP1（102）間で送受信されるとき、AG101は本メッセージを認識してユーザ固有制御を終了する（ステップ3309）。
【０１７０】
LCP Term-req3308を受信したISP1（102）はLCP Term-ack3310をTE100に送信し、PPPoEセッション切断のフェーズに進む。
【０１７１】
ステップ3309において、ユーザ毎の詳細な通信量が取得できる。例えばMACFWD1107から送信フレーム数、受信フレーム数を読出し、PROC1104自体で測定していた通信時間、ユーザ名とあわせてCTL1109に送信する。CTL1109は、内部のDB1110あるいはAG101外部のDB3500にこれらの情報を登録する。こうすることで、ユーザ毎の詳細な通信量が取得でき、課金等に利用することが可能となる。
【０１７２】
ユーザ毎の固有制御の具体例としては、統計情報取得がある。図28に統計情報テーブルを示す。統計情報テーブル3700は図3のCTL1109もしくは図27に示すAG101外のDB3500で管理する。本テーブルは、情報を登録した時刻3701、ユーザ名3702、ユーザの通信時間3703、送信フレーム数3704、受信フレーム数3705からなる。
【０１７３】
本実施例では認証プロトコルとしてCHAPを例に示したが、PAP(PPP Authentication Protocol)でも同様に行える。これらCHAP/PAPメッセージの識別は、PPPフレームフォーマット3110中のプロトコル3111でCHAP/PAPが、コード3112で例えばCHAPの場合はChallenge/Response/Successが識別できる。
【０１７４】
ユーザ毎の固有の制御の他の具体例としては、パケット転送優先度の制御がある。図26に優先度テーブルを示す。
【０１７５】
優先度テーブル3600はユーザ毎にあらかじめ割り当てた優先レベルを格納しているテーブルであり、図3のCTL1109内のDB1110で保持するか、または図27に示すAG101外部のDB3500に保持する。AG101がCHAP Success3304を受信しユーザが確定したとき、PROC1104はCTL1109にユーザ名を送信する。CTL1109は内部のDB1110あるいはAG101外部のDB3500にある優先度テーブル3600を検索し、ユーザ名3601に対応した優先レベル3602を特定し、それをPROC1104に送信する。PROC1104はMACFWD1107のキュー制御に指示を出す。こうすることで、優先レベルの高いユーザが送受信するパケットはMACFWD内で優先的に転送されることが可能になる。
【０１７６】
図29は図24のシーケンスを実現するための処理フローである。パケット受信待ち3400の状態からPPPフレーム受信（分岐3401）の場合、MACFWD1107でパケットの転送処理を行うと共に（ステップ3403）、
PPPフレーム内容がCHAP Response/PAP Auth Req(PAP Authenticate-Request)受信（分岐3404）及びCHAPSuccess/PAP Auth Ack受信（分岐3405）の場合はPPPoEパケットをPROC1104に転送する。CHAP Response/PAP Auth Req受信（分岐3404）の場合、PPPフレーム内容からユーザ名を取得し、セッションユーザ情報テーブル（図25）のユーザ名3904（図6の実施例の場合）、またはセッション管理テーブル2200のユーザ名2205（図13の実施例の場合）、またはISPテーブル3000のユーザ名3006（図21の実施例の場合）に登録する（3303）。CHAP Success/PAP Auth Ack受信（分岐3405）の場合は制御内容に応じてCTL1109に対しユーザ情報のDBを検索(ステップ3406)し、ユーザ毎の固有の制御を開始する（ステップ3407）。
【０１７７】
パケット受信待ち3400の状態からPADT受信（分岐3402）の場合は、パケット転送をMACFWD1107で行い（ステップ3403）、
PROC1104にてユーザ固有制御の終了処理を実施する（ステップ3309）。
【０１７８】
本実施例によれば、PPPセッションのユーザを認識することができるので、ユーザ個別のサービスを提供できるという効果がある。
【０１７９】
上記サービスとして、特定のユーザのパケットを優先的に転送することが可能になるという効果がある。また、ユーザ毎のトラフィック情報を取得できるので、細かな課金制御に利用できるという効果がある。
【０１８０】
（実施例4）
同一ISPに複数のゲートウエイ装置が存在する場合にゲートウエイ装置間の負荷を平均化する実施例を示す。
【０１８１】
図30は、AG101において、同一ISPの複数のゲートウエイ装置それぞれのトラヒック量を管理するためにキャッシュテーブル900を拡張した拡張キャッシュテーブルを示している。拡張キャッシュテーブル3800はキャッシュテーブル900に単位時間トラヒック3806を追加した構成になっている。
【０１８２】
図6または図10のキャッシュテーブルを登録するステップ109のタイミングで、PROC1104はMACFWD1107にMACaddr3802毎のトラヒック計測を指示し、周期的に情報を読み出して単位時間トラヒック3806に設定、更新する。この情報を用いて、図9のステップ104にてTE100に通知するISPのMACアドレスの候補が複数存在する場合、単位時間トラヒック3806の最も小さいものをPADOパケットの送信元アドレスに設定してTE100に通知する。これにより、同一ISPのゲートウエイ装置間でトラヒックを平均化することができるので、そのISPに同時に接続可能なユーザ数を増やすことができるなど、ISP全体として効率よくユーザを収容することが可能になる。
【０１８３】
（実施例５）
以上、上述した各実施例を応用することにより、以下に示すように、既存のアクセスネットワーク装置を変更することなく、IPv4網とIPv6網いずれの中継ネットワークにも接続できるようになる。
【０１８４】
既存のアクセスネットワーク装置AG1300が、IPv4用PPPに対応し、IPv6用PPPには対応していない場合、IPv4網からIPv6網への分岐を実現するにはAG1300を変更する必要がある。
【０１８５】
そこで、図31に示すようにPPPoEで通信している既存設備間たとえばDSLAM1202-AG1300の間に、上述した実施例に基づくAG101を追加する。AG101はDSLAM1202、既存AG1300の両方に対してPPPoEのインタフェースで接続できるため、DSLAM1202、既存AG1300を変更することなく、AG101を追加することができる。
【０１８６】
【発明の効果】
本発明によれば、アクセスサーバからISP網までのトンネリングに係わる処理負荷が小さくなり、パケット転送遅延を小さく、パケット転送速度を大きくできる。
【図面の簡単な説明】
【図１】本発明のアクセスネットワーク装置を適用するネットワーク構成図である。
【図２】従来のネットワークと、各実施例によるプロトコルスタックを示す図である。
【図３】アクセスネットワーク装置の構成図である。
【図４】アクセスネットワーク装置がブリッジとして動作する実施例の、ISPのMACアドレスを管理するキャッシュテーブルである。
【図５】アクセスネットワーク装置がPPPoEのブリッジとして動作する実施例の、MACアドレステーブルである。
【図６】アクセスネットワーク装置がブリッジとして動作する実施例の、端末がISPに接続する際に該アクセスネットワーク装置が接続先ISPのMACアドレスをキャッシュしていない場合のシーケンスである。
【図７】 PPPoEパケットのフォーマットである。
【図８】 PPPoEのTAGフォーマットである。
【図９】アクセスネットワーク装置がブリッジとして動作する実施例の、端末がISPに接続する際に該アクセスネットワーク装置が接続先ISPのMACアドレスを問い合わせ中の場合のシーケンスである。
【図１０】アクセスネットワーク装置がブリッジとして動作する実施例の、アクセスネットワーク装置起動でISPのMACアドレスを問い合わせるシーケンスである。
【図１１】アクセスネットワーク装置がブリッジとして動作する実施例の、パケット受信起動による処理フローである。
【図１２】アクセスネットワーク装置がブリッジとして動作する実施例の、周期起動による処理フローである。
【図１３】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、端末がISPに接続する際に該アクセスネットワーク装置が接続先ISPのMACアドレスをキャッシュしていない場合のシーケンスである。
【図１４】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、TEからのPADI受信を管理するPADIテーブルである。
【図１５】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、TEからのPADR受信を管理するPADRテーブルである。
【図１６】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、セッション管理テーブルである。
【図１７】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、端末がISPに接続する際に該アクセスネットワーク装置が接続先ISPのMACアドレスをキャッシュしている場合のシーケンスである。
【図１８】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、パケット受信起動による処理フローである。
【図１９】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、パケット受信起動による処理フローである。
【図２０】アクセスネットワーク装置がTE側インタフェースとISP側インタフェースの両側にMACアドレスを有し、MACフレームを常に終端する場合の実施例の、周期起動による処理フローである。
【図２１】アクセスネットワーク装置がTE100とはPPPoEで通信し、ISP1（102）とはPPPoAで通信する場合の実施例の、接続シーケンスである。
【図２２】アクセスネットワーク装置がTE100とはPPPoEで通信し、ISP1（102）とはPPPoAで通信する場合の実施例の、VCを管理するISPテーブルである。
【図２３】アクセスネットワーク装置がTE100とはPPPoEで通信し、ISP1（102）とはPPPoAで通信する場合の実施例の、処理フローである。
【図２４】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例のシーケンスである。
【図２５】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の、セッションユーザ情報テーブルである。
【図２６】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の、ユーザ固有制御としてパケット転送優先度を制御する場合の優先度テーブルである。
【図２７】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の、ユーザ情報を外部のDBで管理する場合のネットワーク構成である。
【図２８】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の、ユーザ固有制御としてトラフィック統計情報を取得する場合の統計情報テーブルである。
【図２９】アクセスネットワーク装置がTE100とISPの間で行うPPPネゴシエーションにおいてセッションのユーザを特定する実施例の処理フローである。
【図３０】アクセスネットワーク装置の、接続先の同一ISPに複数のゲートウエイ装置が存在する場合にゲートウエイ装置間の負荷を平均化する実施例の、ゲートウエイ装置それぞれのトラヒック量を管理する拡張キャッシュテーブルである。
【図３１】アクセスネットワーク装置を既存アクセスネットワークに追加する場合のプロトコルスタックである。
【符号の説明】
100…ユーザ端末、101…アクセスネットワーク装置、102…ISP、900…キャッシュテーブル、2200…セッション管理テーブル、2600…PADIテーブル、2700…PADRテーブル、3000…ISPテーブル、3800…拡張キャッシュテーブル
Claims (15)
- 端末と端末側ネットワークを介して接続し、複数の接続先ネットワークのゲートウエイ装置と中継ネットワークを介して接続し、該端末からの送信情報に基づき接続先ネットワークを選択して、前記端末と前記選択した接続先ネットワークとの通信を可能にするアクセスネットワーク装置であって、
前記端末との間でMACフレームの送受信を行うための端末側MACフレーム送受信手段と、
前記接続先ネットワークのゲートウエイ装置との間でMACフレームの送受信を行うためのゲートウエイ側MACフレーム送受信手段と、
前記接続先ネットワークのゲートウエイ装置のMACアドレスと、該接続先ネットワークの識別情報を対応付ける接続先ネットワーク情報記憶手段と、
前記端末からの、前記接続先ネットワークと通信するための送信先MACアドレス問い合わせに応答して、MACアドレスを端末に通知する手段と前記端末に通知した前記MACアドレスを用いた前記端末による通信を前記ゲートウエイ装置へ中継する手段と、を備えるアクセスネットワーク装置。 - 請求項１に記載のアクセスネットワーク装置において、
前記MACアドレスを端末に通知する手段は、送信元情報として前記ゲートウエイ装置を設定した、前記MACアドレス問い合わせに対する応答を前記端末に送信するアクセスネットワーク装置。 - 請求項１に記載のアクセスネットワーク装置において、
前記MACアドレスを端末に通知する手段は、送信元情報として前記アクセスネットワーク装置を設定した、前記MACアドレス問い合わせに対する応答を前記端末に送信するアクセスネットワーク装置。 - 請求項１に記載のアクセスネットワーク装置において、さらに、
前記接続先ネットワーク情報記憶手段に前記識別情報が記憶されていない場合は、前記中継ネットワークへ前記ゲートウエイ装置のMACアドレスの問い合わせを発行し、前記接続先ネットワークのゲートウエイ装置が応答した当該ゲートウエイ装置のMACアドレスを取得し、前記情報記憶手段に格納する手段を備えるアクセスネットワーク装置。 - 請求項４に記載のアクセスネットワーク装置において、
前記MACアドレスを端末に通知する手段は、送信元情報として前記端末を設定した前記ゲートウエイ装置のMACアドレスの問い合わせを発行し、受信した前記応答を端末に転送するアクセスネットワーク装置。 - 請求項４に記載のアクセスネットワーク装置において、
前記MACアドレスを端末に通知する手段は、送信元情報として当該アクセスネットワーク装置を設定した前記ゲートウエイ装置のMACアドレスの問い合わせを発行し、前記応答を受信したのち、当該アクセスネットワーク装置からの応答を返すアクセスネットワーク装置。 - 請求項1に記載のアクセスネットワーク装置であって、
前記端末とPPPoEプロトコル通信を行うための端末側PPPoE通信手段と、
前記接続先ネットワークのゲートウエイ装置とPPPoEプロトコル通信を行うためのゲートウエイ側PPPoE通信手段と、
前記端末と前記ゲートウエイ装置間のPPPoEセッションを中継する手段を備えるアクセスネットワーク装置。 - 請求項1に記載のアクセスネットワーク装置であって、
前記端末とPPPoEプロトコル通信を行うための端末側PPPoE通信手段と、
前記接続先ネットワークのゲートウエイ装置とPPPoEプロトコル通信を行うためのゲートウエイ側PPPoE通信手段と、
前記端末間とのPPPoEセッションと前記接続先ネットワーク間とのPPPoEセッションとを対応付けるセッション接続管理手段とを備えるアクセスネットワーク装置。 - 請求項４に記載のアクセスネットワーク装置であって、
前記MACアドレスを端末に通知する手段から発行された、前記ゲートウエイ装置のMACアドレスの問い合わせに対する、応答待ち時間計測手段を設け、
前記MACアドレスを端末に通知する手段は、前記問い合わせ発行後、所定の時間内でかつ前記応答の受信前に、同一の前記接続先ネットワークのゲートウエイ装置のMACアドレス問い合わせをさらに受信した場合は、当該MACアドレス問い合わせに対する前記中継ネットワークへの前記問い合わせの発行を行わないアクセスネットワーク装置。 - 請求項７または請求項８に記載のアクセスネットワーク装置であって、
前記端末と選択した前記接続先ネットワークのゲートウエイ装置との間で送受信されるPPP認証フレームを監視するPPP認証フレーム監視手段と、
前記PPP認証フレーム監視手段で取得したユーザ情報とPPPoEセッションIDとの対応付けを記憶するセッションユーザ記憶手段を備えるアクセスネットワーク装置。 - 請求項１０に記載のアクセスネットワーク装置であって、
前記ユーザ情報毎にセッション制御パラメータを管理するユーザプロファイル管理手段と、
該ユーザプロファイル管理手段が管理する制御パラメータに基づいてセッション制御を行う手段を備えるアクセスネットワーク装置。 - 請求項１０に記載のアクセスネットワーク装置において、
当該アクセスネットワーク装置に接続する、ユーザ情報毎にセッション制御パラメータを管理するユーザプロファイル管理装置に対し、セッション制御パラメータを問い合わせる制御情報問合せ手段と、
前記問い合わせた結果に基づいてセッション制御を行う手段を備えるアクセスネットワーク装置。 - 請求項１０に記載のアクセスネットワーク装置であって、
ユーザ情報毎にセッションの統計情報を記憶する統計情報管理手段を備えるアクセスネットワーク装置。 - 請求項１０に記載のアクセスネットワーク装置において、
当該アクセスネットワーク装置に接続する、ユーザ情報毎にセッションの統計情報を記憶する統計情報管理手段に対し、統計情報を転送する統計情報転送手段を備えるアクセスネットワーク装置。 - 請求項１ないし請求項１４いずれか一に記載のアクセスネットワーク装置であって、
前記接続先ネットワークが備える複数のゲートウエイ装置毎へのトラフィック量を計測するためのトラフィック量計測手段と、
前記複数のゲートウエイ装置をグループとして認識し、前記計測に基づいて各々のトラフィック量を管理するゲートウエイグループ管理手段を設け、
前記接続先ネットワークへの接続要求に対して、前記グループ内のゲートウエイ装置の内、前記管理されたトラフィック量基づきゲートウエイ装置を選択する手段を備えるアクセスネットワーク装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001393109A JP3757863B2 (ja) | 2001-12-26 | 2001-12-26 | アクセスネットワーク装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001393109A JP3757863B2 (ja) | 2001-12-26 | 2001-12-26 | アクセスネットワーク装置 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003198580A JP2003198580A (ja) | 2003-07-11 |
| JP2003198580A5 JP2003198580A5 (ja) | 2005-02-03 |
| JP3757863B2 true JP3757863B2 (ja) | 2006-03-22 |
Family
ID=27600176
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001393109A Expired - Fee Related JP3757863B2 (ja) | 2001-12-26 | 2001-12-26 | アクセスネットワーク装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3757863B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4655903B2 (ja) * | 2004-12-08 | 2011-03-23 | 株式会社日立製作所 | パケット転送装置 |
| JP2006229352A (ja) * | 2005-02-15 | 2006-08-31 | Sii Network Systems Kk | ハンドオーバーを行うための通信機器、およびネットワーク |
| US7761553B2 (en) * | 2005-11-29 | 2010-07-20 | Telefonaktiebolaget L M Ericsson (Publ) | Method and arrangement in an access system |
| JP4732974B2 (ja) * | 2006-07-27 | 2011-07-27 | 株式会社日立製作所 | パケット転送制御方法およびパケット転送装置 |
| JP2010514290A (ja) * | 2006-12-21 | 2010-04-30 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | メディアアクセス制御アドレスを変換するためのネットワーク装置及び方法 |
| JP2008199420A (ja) * | 2007-02-14 | 2008-08-28 | Furukawa Electric Co Ltd:The | ゲートウェイ装置および認証処理方法 |
| JP2009267917A (ja) * | 2008-04-28 | 2009-11-12 | Hitachi Communication Technologies Ltd | パケット転送装置およびパケット転送方法 |
| JP5009257B2 (ja) * | 2008-08-28 | 2012-08-22 | 株式会社日立製作所 | 中継装置、中継方法 |
| US20120230689A1 (en) * | 2009-09-29 | 2012-09-13 | Luca Baldini | Passive Optical Network Apparatus and Methods |
-
2001
- 2001-12-26 JP JP2001393109A patent/JP3757863B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003198580A (ja) | 2003-07-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7733859B2 (en) | Apparatus and method for packet forwarding in layer 2 network | |
| JP3920305B1 (ja) | パケット転送装置 | |
| US7603470B2 (en) | System and method for provisioning broadband service in a PPPoE network using a configuration domain name | |
| CN101090366B (zh) | 具备网关选择功能的信息包传送装置 | |
| US7154912B2 (en) | System and method for provisioning broadband service in a PPPoE network using a list of stored domain names | |
| US6977906B2 (en) | System and method for provisioning broadband service in a PPPoE network using a random username | |
| US7512688B2 (en) | PPPoE network system that can distribute connection requests from PPPoE client terminals to specific PPPoE servers | |
| CN104125191B (zh) | 基于以太网的点对点协议的处理方法、设备和系统 | |
| US7039049B1 (en) | Method and apparatus for PPPoE bridging in a routing CMTS | |
| US20040105444A1 (en) | Auto-configuration of broadband service for one of a plurality of network communication protocols | |
| JP2003060675A (ja) | 通信方法、通信システム、ユーザ端末装置及び通信接続プログラム | |
| EP1748603B1 (en) | A transmission method for message in layer 2 and an access device | |
| US20070195804A1 (en) | Ppp gateway apparatus for connecting ppp clients to l2sw | |
| US7228358B1 (en) | Methods, apparatus and data structures for imposing a policy or policies on the selection of a line by a number of terminals in a network | |
| JP3692083B2 (ja) | ダイヤルアップ機能付き通信装置 | |
| JP3757863B2 (ja) | アクセスネットワーク装置 | |
| US20100287287A1 (en) | Network Apparatus and Method for Translating Media Access Control Addresses | |
| US20080046974A1 (en) | Method and System Enabling a Client to Access Services Provided by a Service Provider | |
| JP4621259B2 (ja) | パケット転送制御方法 | |
| JP4143663B2 (ja) | ネットワークシステム | |
| WO2007107076A1 (fr) | Procédé et dispositif d'accès utilisateur à large bande | |
| EP1981217A1 (en) | Method for forwarding data packets in an access network and device | |
| KR20080065325A (ko) | 동일 링크에 연결된 복수의 단말간 2계층 통신이이루어지지 않는 가입자액세스 장치에 있어서 단말간통신을 가능하게 하는 통신장치 및 방법 | |
| JP2003078538A (ja) | 情報転送機能切替方式 | |
| JP3173499B2 (ja) | 複数ｉｐアドレスをサポートするａｔｍ装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040302 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040302 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051125 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051206 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051219 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090113 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090113 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090113 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100113 Year of fee payment: 4 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100113 Year of fee payment: 4 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100113 Year of fee payment: 4 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100113 Year of fee payment: 4 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100113 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110113 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110113 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120113 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130113 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |