JP2003143236A - ゲートウェイ装置 - Google Patents
ゲートウェイ装置Info
- Publication number
- JP2003143236A JP2003143236A JP2001332775A JP2001332775A JP2003143236A JP 2003143236 A JP2003143236 A JP 2003143236A JP 2001332775 A JP2001332775 A JP 2001332775A JP 2001332775 A JP2001332775 A JP 2001332775A JP 2003143236 A JP2003143236 A JP 2003143236A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- cache server
- ppp
- web
- user terminal
- 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.)
- Granted
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
におけるWebトラフィックを軽減できるLAC用ゲー
トウェイ装置を提供する。 【解決手段】 複数のISPネットワーク108を収容
するアクセス網105に接続され、ユーザ端末から受信
したPPPフレームを上記アクセス網上に設定されたL
2TPコネクションを介して上記ISPネットワークに
転送するLAC機能を備えたゲートウェイ装置104
が、Webキャッシュサーバと接続するためのキャッシ
ュサーバインタフェース112と、ユーザ端末から受信
したPPPフレーム列の中からペイロード部にWebコ
ンテンツの要求メッセージを含むPPPフレームを選択
し、該PPPフレームが示す要求メッセージを上記キャ
ッシュサーバインタフェースを介して上記キャッシュサ
ーバに転送するパケット転送制御装置(81A〜81
C、87)を備える。
Description
と接続されるゲートウェイ装置に関し、更に詳しくは、
インターネットに接続された複数のISP(Internet Se
rvice Provider)ネットワークを1つのアクセス網で結
合し、ユーザ端末が上記アクセス網と上記何れかのIS
Pネットワークを介してインターネットをアクセスする
ISP選択型IPネットワークに適用されるLAC(L2
TP Access Concentrator)機能を備えたゲートウェイ装
置に関する。
をWebアクセス・トラヒックが占める時代を迎え、ユ
ーザ端末からのWebアクセスの高速化と、ユーザ端末
とWebサーバとを接続するネットワーク上でのトラフ
ィック削減とを狙って、Webキャッシング技術が盛ん
に研究されている。
が収容されるアクセスネットワークにWebキャッシュ
サーバ(またはWebキャッシングサーバ)を設置し、
Webサーバが提供するコンテンツデータの一部をWe
bキャッシュサーバにキャッシュデータとして保持して
おき、Webサーバに代わって、Webキャッシュサー
バからユーザ端末にコンテンツデータを配信することに
よって、ユーザ端末からのWebアクセスの高速化と、
Webサーバが接続されたコアネットワーク上でのトラ
フィックの削減を可能とする。
ワーク分野では、各ISPがそれぞれのサービス地域に
分散して独自にアクセスポイントを設置していたが、最
近の傾向として、複数のISPネットワークを通信キャ
リアが管理する地域IP網(または広域IP網)に接続
しておき、該地域IP網上に上記複数のISPに共通す
るアクセスポイントとなるゲートウェイ装置を配置する
ことによって、各アクセスポイントに接続されたユーザ
端末を上記何れかのISPネットワークに接続するIS
P選択型IPネットワークが有望となってきている。
セスネットワークとなる地域IP網とユーザ端末とのを
接続点に、LAC(L2TP Access Concentrator)と呼ば
れるゲートウェイ装置を設置し、地域IP網と各ISP
ネットワークとの接続点に、LNS(L2TP Network Ser
ver)と呼ばれるゲートウェイ装置が設置される。We
bをアクセスするユーザ端末は、LACとの間にPPP
コネクションを設定する。上記PPPコネクションは、
LAC機能によって、LACとLNSとの間に設定され
たL2TPコネクションを介して、各ユーザが指定した
ISPネットワークに接続される。
に、ユーザ端末でユーザIDと接続先ISPの識別子を
入力すると、上記ユーザ端末と接続されたLACが、上
記ISP識別子に基づいて接続先ISPと対応するLN
Sを特定し、ユーザ端末とLACと間に設定されたPP
Pコネクションを上記LACとLNS間に設定されたL
2TPコネクションを介して特定のLNSまで延長す
る。各LNSでは、ユーザIDに従って端末ユーザを認
証し、ユーザ端末とISPとの接続の可否を判定する。
尚、L2TPによるPPPコネクションの延長と、LA
CおよびLNSがもつ機能については、IETFドラフ
トRFC2661に示されている。
IPネットワークにおいては、LACと各LNSとを接
続するアクセスネットワーク(地域IP網または広域I
P網)における通信コストを削減するために、LACと
各LNSとの間のトラヒックをできるだけ軽減したいと
いうニーズがある。アクセスネットワーク上でトラヒッ
クを削減するためには、例えば、従来のネットワークで
各LNSに接続されていたWebキャッシュサーバをL
AC側に移し、アクセスネットワークの入口でWebキ
ャッシュサーバが各ユーザ端末のWebアクセスに応答
するネットワーク構成が考えられる。
クセスネットワークでは、ユーザ端末から送出された各
IPパケットが、予め設定されたPPPコネクションに
沿ってコネクションエンドまで転送されてしまうため、
PPPコネクションの途中で特定のIPパケットを分岐
することができない。すなわち、LACとして動作する
従来のゲートウェイ装置は、ユーザ端末から送出された
IPパケットを含む受信PPPフレームを単にPPPコ
ネクションに沿ってアクセス網側に中継するだけであ
り、IPレベルでのパケット処理機能を備えていない。
このため、従来技術では、アクセスネットワークの入口
でWebアクセス要求をWebキャッシュサーバに振り
分け、Webキャッシュサーバから応答させることがで
きなかった。
ワークのアクセス網におけるWebトラフィックを軽減
できるLAC用ゲートウェイ装置を提供することにあ
る。本発明の他の目的は、PPPコネクションからWe
bトラフィック用のIPパケットを取り出して、Web
キャッシュサーバに転送する機能を備えたLAC用ゲー
トウェイ装置を提供することにある。
に、本発明は、インターネットに接続された少なくとも
1つのISP(Internet Service Provider)ネットワ
ークを収容するアクセス網に接続され、ユーザ端末から
受信したPPP(Point to Point Protocol)フレーム
を上記アクセス網上に設定されたL2TP(Layer2 Tun
neling Protocol)コネクションを介して上記ISPネ
ットワークに転送するLAC(L2TP Access Concentrat
or)機能を備えたゲートウェイ装置において、上記イン
ターネットに接続されたWebサーバによって提供され
るコンテンツデータの一部をキャッシュデータとして保
持するキャッシュサーバとパケット通信するためのキャ
ッシュサーバインタフェースと、ユーザ端末から受信し
たPPPフレーム列の中からペイロード部にWebコン
テンツの要求メッセージを含むPPPフレームを選択
し、該PPPフレームが示す要求メッセージを上記キャ
ッシュサーバインタフェースを介して上記キャッシュサ
ーバに転送し、上記キャッシュサーバインタフェースを
介して上記キャッシュサーバから受信した応答メッセー
ジをWebコンテンツ要求元のユーザ端末にPPPフレ
ーム形式で転送するパケット転送制御手段とを備えたこ
とを特徴とする。
れた複数のISPネットワークを収容するアクセス網に
接続され、ユーザ端末から受信したPPPフレームを上
記アクセス網上に設定されたL2TPコネクションを介
して上記ユーザ端末のユーザが加入しているISPと対
応した上記何れかのISPネットワークに転送するLA
C機能を備えたゲートウェイ装置において、上記インタ
ーネットに接続されたWebサーバによって提供される
コンテンツデータの一部をキャッシュデータとして保持
するキャッシュサーバとパケット通信するためのキャッ
シュサーバインタフェースと、加入先ISPが異なる複
数のユーザ端末から受信した複数のPPPフレームの中
からペイロード部にWebコンテンツの要求メッセージ
を含むPPPフレームを選択し、該PPPフレームが示
す要求メッセージを上記キャッシュサーバインタフェー
スを介して上記キャッシュサーバに転送し、上記キャッ
シュサーバインタフェースを介して上記キャッシュサー
バから受信した応答メッセージを含むIPパケットをP
PPフレーム形式でWebコンテンツ要求元のユーザ端
末に転送するパケット転送制御手段とを備えたことを特
徴とする。
制御手段が、ユーザ端末から受信した各PPPフレーム
に含まれるIPヘッダの宛先アドレスと前記キャッシュ
サーバに割り当てられた特定のIPアドレスとの関係を
チェックすることによって、Webコンテンツ要求メッ
セージを含むPPPフレームを識別する。
送制御手段が、ユーザ端末から受信した各PPPフレー
ムに含まれるIPパケットの上位プロトコルをチェック
することによって、Webコンテンツ要求メッセージを
含むPPPフレームを識別する。例えば、各PPPフレ
ームに含まれるIPパケットのTCP(TransmissionCo
ntrol Protocol)またはUDP(Use Datagram Protoco
l)におけるポート番号をチェックし、ポート番号がH
TTP(Hyper Text Transfer Protocol)を示す「8
0」となっている受信PPPフレームをWebコンテン
ツ要求メッセージ用のPPPフレームと判定する。本発
明のその他の目的と特徴は、以下に述べる発明の実施形
態の説明から明らかになる。
面を参照して説明する。本発明の第1の実施例は、LA
Cと各LNSとの間のパケット通信がL2TPによって
行われるISP選択型IPネットワークシステムにおい
て、LACとして機能するゲートウェイ装置にWebキ
ャッシュサーバを接続しておき、ユーザ端末から送信さ
れたWebトラフィック用のIPパケットを上記ゲート
ウェイ装置からWebキャッシュサーバにプロキシ設定
方式によって転送するようにしたことを特徴とする。
トウェイ装置を適用したISP選択型IPネットワーク
システムの1例を示す。LAC(本発明のゲートウェイ
装置)104は、例えば、電話網、ADSL、CATV
等のアクセス回線102−1〜102−mを介して複数
のユーザ端末101−1〜101−mと接続され、地域
IP網(または広域IP網)105を介して複数のLN
S107−1〜107−nと接続されている。
れISPネットワーク108−1〜108−nと接続さ
れ、ISPネットワーク108−1〜108−nは、ル
ータ109−1〜109−nを介してインターネット1
10に接続されている。ここでは、1つのWebサーバ
111しか示していないが、上記インターネット110
にはメールサーバや他のWebサーバなど、ユーザ端末
からアクセス可能な複数のサーバが接続されている。
−nには、ISP加入ユーザを認証するためのRADI
US(Remote Authentication Dial In User Service)
サーバ120−1〜120−n、ホスト名からIPアド
レスを検索するためのDNS(Domain Name System)サ
ーバ130−1〜130−nや、図示しないDHCP
(Dynamic Host Configuration Protocol)サーバが接
続されている。また、LAC104には、LAN112
を介して、Webキャッシュサーバ113と、ユーザの
一次認証を行うためのRADIUSサーバ114とが接
続されている。
網105に接続されたLAC104とLNS107−1
〜107−nには、それぞれ地域IP網105内でのパ
ケットルーティングに必要なIPアドレス“192.168.0.
128”,“192.168.0.1”〜“192.168.0.n”が割り当てら
れている。また、Webキャッシュサーバ113には、
各ISP(ISPネットワークおよびRADIUSサー
バ)と対応したIPアドレスが割り当てられている。
サーバ113にISPネットワーク108−1〜108
−nと対応した複数のIPアドレス(“210.10.10.1”
〜“210.10.10.n”)を割り当てておき、後述するよう
に、Webキャッシュサーバ113がユーザから要求さ
れたWebコンテンツをWebサーバ111から入手す
るとき、Webサーバ宛に送信するHTTP要求メッセ
ージ(IPパケット)の送信元アドレスを要求元ユーザ
の加入ISPに応じて使い分けるようにしている。尚、
図1では、1つのLAC1104しか示されていない
が、実際の地域IP網105には、それぞれが複数のユ
ーザ端末を収容する多数のLACが接続されている。
型IPネットワークシステムにおいて、ISPネットワ
ーク108−1のプロバイダと契約しているユーザ端末
101−1からインターネット110をアクセスする場
合のコネクションの変遷について説明する。ユーザ端末
101−1は、図2に示すように、アクセス回線102
−1を介して、LAC104との間にPPP(Point to
Point Protocol)コネクション103−1aを設定す
る。PPPコネクション上では、PPPフレーム200
の形式でデータが転送される。
すように、IPパケットが設定される情報フィールド2
05の前に、フラグフィールド201と、アドレスフィ
ールド202と、制御フィールド203と、プロトコル
識別フィールド204からなるPPPヘッダを有し、情
報フィールド205の後に、PADフィールド206
と、FCSフィールド207と、フラグフィールド20
8を含む。
ロトコル識別フィールド204によって識別される。図
5(B)に、上記プロトコルフィールド204に設定さ
れる代表的な識別値204と、プロトコル204Aとの
関係を示す。
et Protocol Control Protocol)が適用され、PPPコ
ネクションの両端ノードでIPアドレスの送受信などの
IPネゴシェーションを行った後、IPパケットが送信
される。また、PPPヘッダによるデータ伝送のオーバ
ヘッドを抑制するために、アドレスフィールド202と
制御フィールド203の圧縮や、プロトコルフィールド
204の圧縮(例えば、プロトコル識別値が00FFh
より小さい場合に限って下位1バイトのみ伝送する)等
のオプションがあり、PPPコネクション上で使用する
オプションは、PPPコネクションの両端ノードでLC
P(Link Control Protocol)によるネゴシエーション
によって決定される。
らPPPフレーム化されたLCP制御データ(リンク設
定要求)を受け取ると、ユーザ端末とオプション設定ネ
ゴシエーションのためのLCP制御データを交信してリ
ンクを確立する。この後、ユーザ端末101−1は、例
えば、PAP(Password Authentication Protocol)、
CHAP(Challenge Handshake Authentication Proto
col)等の認証プロトコルによって、LAC104にユ
ーザ名情報とパスワードを送信する。
IUSサーバ114に転送し、RADIUSサーバ11
4にユーザの一次認証を要求する。RADIUSサーバ
114から認証成功のレスポンスがあった場合、LAC
104は、例えば、ユーザ名情報からユーザ端末101
−1が所属しているISPを識別し、該ISPと対応す
るLNS107−1を特定する。
でL2TP制御メッセージ300を送受信することによ
って、図3に示すように、LAC104とLNS107
−1との間にL2TPコネクション106−1を設定し
た後、ユーザセッションを確立する。これによって、L
2TPコネクション106−1のトンネルIDと、セッ
ションIDが決定される。
06−1を通して、前述したPPPオプション設定のた
めのLCP情報や認証情報(ユーザ名・パスワード)を
LNS107−2に送信する。上記LCP情報によっ
て、LAC104とLNS107−2との間でPPPオ
プションのネゴシエーションが行われる。また、上記認
証情報は、RADIUSサーバ120−1に転送され、
RADIUSサーバ120−1においてユーザ認証が行
われる。以上の手順によって、L2TPコネクション1
06−1上にユーザ端末101−1用のPPPコネクシ
ョン103−1bが設定される。
1−1とLAC104との間のPPPコネクション10
3−1aと、LAC104とLNS107−1との間の
PPPコネクション103−1bに別の符号を与えた
が、実際には、ユーザセッションを確立した時に割り当
てたL2TPコネクション106−1のトンネルIDと
セッションIDをPPPコネクション103−1aと対
応付けて管理することによって、LAC104では、P
PPコネクション103−1bとPPPコネクション1
03−1aとが同一のコネクション識別子で管理され
る。
1−1へのIPアドレスの動的な割り当ては、上記PP
Pコネクション103−1bの設定の後で行われる。こ
れによって、ユーザ端末101−1は、PPPコネクシ
ョン103−1(103−1aと103−1b)とIS
Pネットワーク108−1を介して、インターネット1
10をアクセスできる状態となる。
2、101−mが、それぞれ異なるISPネットワーク
に加入していた場合のPPPコネクションを示す。この
例では、ユーザ端末101−2とLAC104との間の
PPPコネクション103−2aが、L2TPコネクシ
ョン106−2上のPPPコネクション103−2bで
LNS107−2まで延長され、ユーザ端末101−m
とLAC104との間のPPPコネクション103−m
aが、L2TPコネクション106−n上のPPPコネ
クション103−nbでLNS107−nまで延長され
た状態を示している。ユーザ端末用のPPPコネクショ
ン103(103−1b〜103−nb)は、ユーザの
必要に応じて設定され、不要となった時点で解消され
る。
は、LAC104とLAN107−1〜107−nとの
間のL2TPコネクション106−1〜106−n上
に、ユーザ端末用のPPPコネクション103とは別
に、Webキャッシュサーバ113用のPPPコネクシ
ョン116(116−1〜116−n)が設定される。
これらのPPPコネクション116は、Webキャッシ
ュサーバ113の立ち上げ時に設定され、定常的に存在
する。
コンテンツを取得するために各ユーザ端末101(10
1−1〜101−m)がPPPコネクション103(1
03−1a〜103−ma)に送出したHTTP要求メ
ッセージを捕捉してキャッシュサーバ113に転送し、
キャッシュサーバ113から要求元のユーザ端末にHT
TP応答メッセージを返送するようにしたことにある。
キャッシュサーバ113は、ユーザから要求されたWe
bコンテンツがキャッシュデータ中に存在しなかった場
合にのみ、上述したPPPコネクション116(116
−1〜116−n)を使用してWebサーバ111から
Webコンテンツを取得し、これを要求元のユーザ端末
に転送する。
ーバ111との間の直接的な交信が抑制されるため、イ
ンターネット110へのアクセス網となる地域IP網1
05におけるHTTP要求メッセージおよびHTTP応
答メッセージのトラフィック量を大幅に削減できる。
端末101−1で動作しているWebブラウザ・アプリ
ケーションがWebコンテンツを取得する場合のパケッ
ト転送シーケンスについて更に詳しく説明する。最初
に、本発明の理解を容易にするために、図6の(A)、
(B)を参照して、図1に示したLAC104が従来の
ゲートウェイ装置で構成されていた場合のパケット転送
シーケンスについて説明する。ここで、図6の(B)
は、図6の(A)に示した転送パケット中のIPヘッダ
に設定される宛先アドレスDAと送信元アドレスSAと
の関係を示している。
ザ・アプリケーションに、Webサーバ111から入手
すべきコンテンツデータをURL(Uniform Resource I
dentifier)によって指定すると(S1011)、ユー
ザ端末101−1からアクセス回線102−1に、上記
URLを含むWebサーバ111宛のHTTP要求メッ
セージが送出される。上記HTTP要求メッセージは、
Webサーバ111のIPアドレスを宛先アドレス、端
末101−1のIPアドレスを送信元アドレスとするI
PヘッダIP(a)をもつIPパケットにPPPヘッダ
を付加したPPPフレーム601の形式でアクセス回線
102−1に送出される。
から受信したPPPフレーム601をL2TPヘッダと
UDPヘッダと新たなIPヘッダIP(b)をもつIP
パケット602に変換して、LNS107−1に向かう
L2TPコネクション106−1に転送する。IPヘッ
ダIP(b)の宛先アドレスには、LNS107−1の
IPアドレス、送信元アドレスにはLAC104のIP
アドレスが設定されている。
05内をルーティングされてLNS107−1に到達す
る。LNS107−1は、IPパケット602にL2T
Pの終端処理(IPヘッダ、UDPヘッダ、L2TPヘ
ッダの除去)とPPPの終端処理(PPPヘッダの除
去)を施し、IPヘッダIP(a)をもつIPパケット
603の形式に戻してISPネットワーク108−1に
送出する。上記IPパケット603は、ISPネットワ
ーク108−1からルータ109−1を介してインター
ネット110に中継され、Webサーバ111に転送さ
れる。
ット603のデータ部に含まれるHTTP要求メッセー
ジを抽出し、HTTP要求メッセージのURLで指定さ
れたコンテンツデータを検索する。検索結果を含むHT
TP応答メッセージは、要求元であるユーザ端末101
−1のIPアドレスを宛先アドレス、Webサーバ11
1のIPアドレスを送信元アドレスとするIPヘッダI
P(c)をもったIPパケット604として、インター
ネット110に送出され、ルータ109−1、ISPネ
ットワーク108−1を経由してLNS107−1に到
達する。
の宛先アドレスからPPPコネクションを特定し、受信
パケット604をPPPヘッダ、L2TPヘッダ、UD
Pヘッダと、新たなIPヘッダIP(d)とを持つIP
パケット605に変換して、L2TPコネクション10
6−1に送出する。上記IPヘッダIP(d)の宛先ア
ドレスはLAC104のIPアドレス、送信元アドレス
はINS107−1のIPアドレスをなっている。
信したIPパケット605にL2TPの終端処理を施
し、受信パケット605をPPPパケット606に変換
してアクセス回線102−1に転送する。上記PPPパ
ケット606はユーザ端末101−1によって受信さ
れ、Webブラウザ・アプリケーションによって、HT
TP応答メッセージから抽出したコンテンツデータが端
末画面に表示される(S1012)。
SP選択型IPネットワークでは、Webサーバ111
が提供するコンテンツデータを取得する場合、ユーザ端
末101−1から送信されたHTTP要求メッセージ
が、アクセスネットワーク105(PPPコネクション
103−1)とISPネットワーク108−1を経由し
てWebサーバ111まで転送され、Webサーバ11
1からの応答メッセージが、ISPネットワーク108
−1とアクセスネットワーク105を経由して要求元の
ユーザ端末に送信される。すなわち、従来のLAC10
4は、端末から受信したHTTP要求メッセージ(PP
Pフレーム)を単にアクセスネットワーク105側のL
2TPコネクションに中継するのみであり、PPPフレ
ーム内のIPヘッダに従ったIPパケット・ルーティン
グの機能は備えていない。
イ装置を適用した場合のパケット転送シーケンスを図
7、図8を参照して説明する。本実施例では、LAC1
04に収容された各ユーザ端末101−i(i=1〜−
m)上で動作するWebブラウザ・アプリケーション
に、それぞれの端末ユーザが加入しているISPと対応
するWebキャッシュサーバ113のIPアドレスが、
予めプロキシサーバアドレスとして設定されていること
を前提とする。従って、HTTP要求メッセージは、I
Pヘッダの宛先アドレスフィールドに上記Webキャッ
シュサーバ113のIPアドレスを含むPPPパケット
として、各ユーザ端末からLAC104に送出される。
セス回線102−i(i=1〜m)から受信したパケッ
トの宛先IPアドレスをチェックし、宛先IPアドレス
に従って受信パケットをルーティングする。HTTP要
求メッセージを含むIPパケットは、LAC104から
Webキャッシュサーバ113に転送され、URLで指
定されたコンテンツデータがWebキャッシュサーバ1
13に存在していた場合は、指定コンテンツデータを含
む応答メッセージがWebキャッシュサーバ113から
要求元のユーザ端末に返送される。
テンツデータがWebキャッシュサーバ113に存在し
ていた場合のパケット転送シーケンスを示し、図7の
(B)は、図7の(A)に示した転送パケット中のIP
ヘッダに設定される宛先アドレスDAと送信元アドレス
SAとの関係を示している。
ラウザ・アプリケーションに対して、ユーザがコンテン
ツデータのURLを指定すると、HTTP要求メッセー
ジを含むPPPフレーム701が生成され、ユーザ端末
101−1からアクセス回線102−1に送出される
(S1011)。上記PPPフレーム701のIPヘッ
ダIP(e)の宛先アドレスには、上述したWebブラ
ウザ・アプリケーションのプロキシ設定によって、端末
ユーザが加入している特定のISPと対応したWebキ
ャッシュサーバIPアドレスが自動的に設定される。上
記宛先アドレスは、例えば、図1においてWebキャッ
シュサーバ113に割り当てられた複数のIPアドレス
“210.10.10.1”〜“210.10.10.n”のうちの何れかであ
る。
1を受信すると、受信フレームからIPパケット702
を抽出し、IPヘッダIP(e)の宛先アドレスをLA
Cに予め登録されているWebキャッシュサーバ113
の割り当てIPアドレスと比較する。宛先アドレスが、
Webキャッシュサーバ113に割り当てられたIPア
ドレスと一致すると、LAC104は、IPパケット7
02をWebキャッシュサーバ113に転送する。宛先
アドレスがWebキャッシュサーバ113の割り当てI
Pアドレスと一致しなかった場合、LAC104は、受
信PPPフレーム701を地域IP網105側のPPP
コネクション103−1bに中継する。
104からIPパケット702を受信すると、データ部
からHTTP要求メッセージを抽出し、URLで指定さ
れたコンテンツデータをキャッシュデータの中から検索
する(S1131)。指定されたコンテンツデータが見
つかった場合は、コンテンツデータを含むHTTP応答
メッセージを生成し(S1132)、該HTTP応答メ
ッセージをデータ部に含み、要求元のユーザ端末101
−1のIPアドレスを宛先アドレスとするIPパケット
703をLAC104に送出する。
113からの受信パケット703の宛先アドレスがユー
ザ端末101−1を示しているため、受信パケット70
3をPPPフレーム704の形式でアクセス回線102
−1に転送する。
で指定されたコンテンツデータがWebキャッシュサー
バ113に存在しなかった場合のパケット転送シーケン
スを示す。図8の(B)は、図8の(A)に示した転送
パケット中のIPヘッダに設定される宛先アドレスDA
と送信元アドレスSAとの関係を示している。
は、アクセス回線102−1からHTTP要求メッセー
ジを含むPPPフレーム701を受信すると、IPヘッ
ダIP(e)の宛先アドレスを判定して、IPパケット
702をWebキャッシュサーバ113に転送する。
ケット702のデータ部からHTTP要求メッセージを
抽出し、URLで指定されたコンテンツデータをキャッ
シュデータから検索する(S1131)。検索の結果、
指定されたコンテンツデータがキャッシュデータ中にな
かった場合、Webキャッシュサーバ113は、上記U
RLのホスト名を持つWebサーバ111のIPアドレ
スをDNSサーバ130−1に問い合わせる(S113
3)。Webサーバ111のIPアドレスが判明する
と、Webキャッシュサーバ113は、上記HTTP要
求メッセージをデータ部に設定したIPパケット705
を生成し、これをLAC1−4に送信する。
(g)は、宛先アドレスがWebサーバ111のIPア
ドレス、送信元アドレスが、PPPフレーム701の宛
先アドレスとなっていたWebキャッシュサーバ113
の割り当てIPアドレスとなっている。
からIPパケット705を受信すると、受信パケットの
送信元アドレスから宛先LNSを特定する。この例で
は、宛先LNSは107−1である。LAC104は、
上記IPパケット705をIPパケット706に変換
し、LNS107−1とLAC104との間のL2TP
コネクション106−1上のPPPコネクション116
−1に転送する。
ット706に、PPPヘッダ、L2TPヘッダ、UDP
ヘッダ、IPヘッダIP(h)を付加したものであり、
IPヘッダIP(h)の宛先アドレスはLNS107−
1のIPアドレス、送信元アドレスはLAC104のI
Pアドレスとなっている。上記IPパケット706は、
LNS107−1においてL2TPとPPPの終端処理
が施され、Webキャッシュサーバ113が送出した元
のIPパケット705戻してWebサーバ111に転送
される(707)。
05のデータ部からHTTP要求メッセージを抽出し、
URLで指定されたコンテンツデータを検索し(S11
11)、指定コンテンツデータを含むHTTP応答メッ
セージをIPパケット708としてインターネット11
0に送出する。上記IPパケット708のIPヘッダI
P(i)には、宛先アドレスとしてWebキャッシュサ
ーバ113のIPアドレス、送信元アドレスとしてWe
bサーバ111のIPアドレスが設定されている。
−1で受信され、PPPヘッダ、L2TPヘッダ、UD
Pヘッダ、IPヘッダIP(j)を付加したIPパケッ
ト709に変換して、地域IP網のL2TPコネクショ
ン106−1に送出される。上記IPヘッダIP(j)
は、宛先アドレスがLAC104のIPアドレス、送信
元アドレスがLNS107−1のIPアドレスとなって
おり、IPパケット709は、LAC104においてL
2TPとPPPの終端処理が施され、元のIPパケット
708に戻された後、IPヘッダIP(i)の宛先アド
レスに従ってWebキャッシュサーバ113に転送され
る。
ケット708のデータ部からHTTP応答メッセージを
抽出し、該応答メッセージに含まれるWebコンテンツ
データをキャッシュデータとして保存した後、該コンテ
ンツデータの要求元であるユーザ端末101−1宛のH
TTP応答メッセージを生成し(S1134)、これを
IPパケット703としてLAC104に送出する。L
AC104は、Webキャッシュサーバ113から受信
したIPパケット703の宛先アドレスがユーザ端末1
01−1のIPアドレスとなっているため、受信パケッ
トをPPPフレーム704に変換し、ユーザ端末101
−1のアクセス回線102−1に送出する。
つ本発明によるゲートウェイ装置の1実施例を示すブロ
ック図である。ゲートウェイ装置(LAC)104は、
それぞれアクセス回線101−i(i=1〜m)を収容
した複数のアクセス回線インタフェース回路80Aと、
LAN112に接続されたWebキャッシュサーバイン
タフェース回路80Bと、地域IP網105と接続され
た地域IP網インタフェース回路80Cと、これらのイ
ンタフェース回路と対応して設けられたプロトコル処理
回路81A、81B、81Cと、これらのプロトコル処
理回路間でパケットを交換する内部スイッチ回路87
と、上記各プロトコル処理回路に接続されたノード制御
回路88とからなる。
れぞれが収容するネットワークの物理回線種別(例え
ば、イーサネット(登録商標)、ATM等)に応じてパ
ケットデータを送受信する。プロトコル処理回路81A
〜81Cは、後述するように、それぞれが接続されたイ
ンタフェース回路80A、80B、80Cに対応したプ
ロトコル処理機能を備えている。図9では、アクセス回
線インタフェース回路80A毎に1つのプロトコル処理
回路81Aが接続されているが、各プロトコル処理回路
81Aにパケット多重化/分配装置を介して複数のアク
セス回線インタフェース回路80Aを接続した構成とす
ることも可能である。
回路81A〜81Cから入力されたパケットを内部ヘッ
ダの転送先情報で特定される何れかのプロトコル処理回
路にスイッチングする。ノード制御回路88は、制御端
末90から入力された設定情報に従って、ゲートウェイ
装置の全体動作を制御すると共に、制御端末90へ警報
および統計情報を出力する。
A〜81C)の基本的な構成を示す。プロトコル処理回
路81は、CPU811と、メモリ812と、インタフ
ェース受信バッファ813と、インタフェース送信バッ
ファ814と、内部スイッチ送信バッファ815と、内
部スイッチ受信バッファ816と、CPU間通信インタ
フェース回路817とからなり、接続されるインタフェ
ース回路の種別が異なっても、ハードウェア的には同一
の構成となっている。
20と、ユーザ端末情報管理テーブル830と、ISP
情報管理テーブル840と、HTTP要求メッセージ管
理テーブル850が配置される。但し、HTTP要求メ
ッセージ管理テーブル850は、後述する本発明の第2
実施例で必要となるテーブルであり、以下に説明する本
発明の第1実施例には不要である。プログラム格納領域
820には、後述するようにプロトコル処理回路の機能
(81A、81B、81C)に応じたプログラムが格納
され、ここに用意されたプログラムをCPU811で実
行することにより、対応するインタフェース回路との間
の送受信データに対して所定のプロトコル処理が施され
る。
ース回路817を介して、ゲートウェイ装置104を構
成する他のプロトコル処理回路およびノード制御回路8
8との間で、プロトコル処理に必要な管理情報や、警
報、統計情報を送受信する。
C)で受信されたパケットデータ(IPパケットまたは
PPPフレーム)は、対応するプロトコル処理回路81
(81A〜81C)に転送され、図10に示すインタフ
ェース受信バッファ813に一時的に蓄積される。イン
タフェース受信バッファ813に蓄積されたパケットデ
ータは、CPU811によって、メモリ領域820に用
意された受信パケット処理ルーチンで定義された所定の
プロトコル処理を受けた後、内部スイッチ送信バッファ
815を介して、内部スイッチ87に入力される。
ータは、内部スイッチ受信バッファ816に一時的に蓄
積され、CPU811によって、メモリ領域820に用
意された送信パケット処理ルーチンで定義された所定の
プロトコル処理を受けた後、インタフェース送信バッフ
ァ814を介して、対応するインタフェース回路80
(80A〜80C)に送出される。
ス回路80とプロトコル処理回路81との間で転送され
るパケットフォーマットを示す。(A)は、ペイロード
部1003にLCP制御情報を含むPPPフレーム、
(B)は、ペイロード部1003にNCP制御情報を含
むPPPフレーム、(C)は、ペイロード部1003に
IPヘッダ1005とHTTP要求メッセージ1006
とを含むPPPフレーム、(D)は、ペイロード部10
03にIPヘッダ1005とHTTP応答メッセージ1
007とを含むPPPフレーム、(E)は、ペイロード
部1003にIPヘッダ1005と、例えば、電子メー
ルやTelnetなどの非HTTPデータ1008とを
含むPPPフレームを示す。
路80(80A〜80C)によって、PPPヘッダ10
02の前にPPPコネクション識別子1001が付加さ
れる。ただし、受信データが特定のPPPコネクション
と対応づけられていない場合、上記識別子1001とし
て、不特定PPPコネクションであることを示す所定の
マジックナンバーが付される。
に含まれるプロトコル情報を識別し、(A)、(B)に
示すようにペイロード部1003にLCPまたはNCP
の制御情報を含むフレームについては、LAC内でLC
P処理またはNCP処理を実行しているが、(C)〜
(E)に示すようにペイロード部1003にIPパケッ
トを含むPPPフレームについては、単にユーザトラフ
ィックデータとして扱い、受信フレームを予め指定され
たPPPコネクションに沿って出力網側に中継する機能
しか備えていなかった。
ス回線またはIP網からの受信PPPフレームがペイロ
ード部1003にIPパケット(ユーザトラフィックデ
ータ)を含む場合、アクセス回線対応プロトコル処理部
81AとIP網対応プロトコル処理部81Cが、IPヘ
ッダ1005の宛先アドレスをチェックし、IPパケッ
トがHTTPトラフィック用のものであれば、受信IP
パケットをPPPコネクションから分離して、LACに
接続されたキャッシュサーバ114に転送するようにし
ている。
〜81C)と内部スイッチ87との間で送受信される内
部パケットフォーマットを示す。各プロトコル処理回路
81は、インタフェース回路80(80A〜80C)か
らの受信パケット(PPPコネクション識別子1001
が付加されたPPPフレーム1103)を、内部転送先
情報を含む内部ヘッダ1010を付加した形で、内部ス
イッチ87に出力する。受信パケットに付されたPPP
コネクション識別子1001は、プロトコル処理回路8
1において、必要に応じて書き換えられる。内部スイッ
チ87は、各プロトコル処理回路81からの受信パケッ
トを内部転送先情報(内部ヘッダ)1010が指定する
他の何れかのプロトコル処理回路81にスイッチングす
る。
30の1実施例を示す。ユーザ端末情報管理テーブル8
30には、LAC104に収容された各ユーザ端末と対
応する複数の管理情報エントリが登録される。各管理情
報エントリは、ユーザ端末のIPアドレス831と、ユ
ーザ端末−LNS間のPPPコネクションの識別子83
2と、ユーザの所属するISPの識別子833と、PP
PコネクションのLCP(LinkControl Protocol)設定
オプション情報834と、L2TPコネクション情報8
35との対応関係を示している。
は、例えば、プロトコルフィールド圧縮(PFC: Protoco
l Field Compression)オプションの選択の有無を示す
設定値834aと、アドレス/制御フィールド圧縮(AC
FC: Address and Control Field Compression)オプシ
ョンの選択の有無を示す設定値834bが含まれる。ま
た、L2TPコネクション情報835としては、L2T
Pコネクション内にPPPコネクションを設定する際に
使用されるトンネルID835a、セッションID83
5b等の情報が含まれる。
の1実施例を示す。ISP情報管理テーブル840に
は、アクセスネットワーク105に接続されているIS
Pネットワークと対応した複数の管理情報エントリが格
納される。
1と、Webキャッシュサーバ113に割り当てられた
IPアドレス842と、ISP識別子841が示すIS
Pネットワークを収容しているLNSのIPアドレス8
43と、Webキャッシュサーバ113とWebサーバ
111との通信に使用されるLAC−LNS間PPPコ
ネクションの識別子844と、LCP設定オプション情
報845と、L2TPコネクション情報846との対応
関係を示している。LCP設定オプション情報845と
L2TPコネクション情報846には、それぞれユーザ
情報管理テーブル830と同様の情報項目が含まれる。
おけるデータの流れを示す。アクセス回線からアクセス
回線インタフェース80Aに入力されたPPPフレーム
は、アクセス回線対応のプロトコル処理回路81Aにお
いて、プロトコルフィールド204が示す上位プロトコ
ルの種類に応じて処理される。受信フレームの上位プロ
トコルがPPPのLCPの場合はLCP処理、NCPの
場合はNCP処理が実行される。
アドレスが判定される。例えば、図8で説明した受信フ
レーム701のように、宛先アドレスがISP管理テー
ブル840に登録されたWebキャッシュサーバの割り
当てIPアドレス842と一致していた場合は、受信フ
レームから抽出されたIPパケット702が、内部スイ
ッチ回路87を介して、キャッシュサーバ対応のプロト
コル処理回路81Bに転送される。PPPの上位プロト
コルが、LCP、NCP、IP以外の場合、または、W
ebキャッシュサーバ宛でないIPの場合は、受信パケ
ットはIP網対応のプロトコル処理回路81Cに転送さ
れ、送信元IPアドレスによって決まる適切なL2TP
コネクションに送出される。
81BがWebキャッシュサーバ118から受信したI
Pパケットは、宛先IPアドレスによって、アクセス回
線対応プロトコル処理回路81AまたはIP網対応プロ
トコル処理回路81Cに振り分けられる。
3のように、宛先IPアドレスがユーザ情報管理テーブ
ル830に登録された何れかのユーザ端末のIPアドレ
ス831に一致した受信パケットは、HTTP応答メッ
セージを含むIPパケットと判断され、アクセス回線対
応プロトコル処理回路81Aに転送される。また、図8
で説明したIPパケット705のように、パケット宛先
IPアドレスがユーザ情報管理テーブル830に登録さ
れた何れのユーザ端末IPアドレスにも該当しない受信
パケットは、HTTP要求メッセージを含むIPパケッ
トと判断され、IP網対応プロトコル処理回路81Cに
転送される。
たL2TPフレームは、IP網対応プロトコル処理回路
81Cで終端され、L2TPフレームから抽出された受
信IPパケットが、PPPコネクションの識別子に応じ
て、アクセス回線対応プロトコル処理回路81Aまたは
キャッシュサーバ対応プロトコル処理回路81Bに振り
分けられる。例えば、ユーザ端末−LNS間に設定され
たPPPコネクション上で転送されてきたIPパケット
は、アクセス回線対応プロトコル処理回路81Aに送出
され、LAC−LNS間に設定されたキャッシュサーバ
用のPPPコネクション上で転送されてきたIPパケッ
トは、キャッシュサーバ対応プロトコル処理回路81B
に転送される。
理回路81AのCPU811が実行する受信パケット処
理ルーチン1500のフローチャートを示す。受信パケ
ット処理ルーチン1500では、先ず、インタフェース
受信バッファ813から、図11の(A)〜(E)に示
した受信パケットを取り出し、PPPヘッダ1002の
フォーマットを特定する(S1501)。PPPヘッダ
のフォーマットは、受信パケットに付されたPPPコネ
クション識別子1001に基づいてユーザ端末管理テー
ブル830を参照し、上記PPPコネクション識別子と
対応するLCP設定オプション情報814を読み出すこ
とによって特定できる。
ド204の内容から、受信PPPフレーム1003の上
位プロトコルを識別する。受信PPPフレームの上位プ
ロトコルがデータリンク制御プロトコル:LCPの場合
は(S1502)、LCPパケット処理を実行する(S
1520)。受信PPPフレームの上位プロトコルがネ
ットワーク制御プロトコル:NCPの場合は(S150
3)、NCPパケット処理を実行する(S1530)。
Pの場合(S1504)、IPヘッダの宛先アドレスが
Webキャッシュサーバ113に割り当てられたIPア
ドレスと一致するか否かをチェックする(S150
5)。具体的に言うと、先ず、上記IPヘッダの送信元
アドレスに基づいてユーザ端末管理テーブル830を参
照し、送信元ユーザが属するISPの識別子833を求
める。次に、上記ISP識別子に基づいてISP情報管
理テーブル840を参照することによって、ISPと対
応したWebキャッシュサーバの割り当てIPアドレス
842を特定し、このIPアドレスと受信IPパケット
の宛先アドレスとを比較する。
シュサーバの割り当てIPアドレスと一致した場合は、
受信IPパケットにPPPコネクション識別子1001
と内部転送先情報1010を付加し、内部スイッチ送信
バッファ815に格納する(S1510)。この場合、
PPPコネクション識別子1001としては、ISP識
別子と対応してISP情報管理テーブル840に登録さ
れたLAC−LNS間PPPコネクション識別子844
が適用され、内部転送先情報1010としては、キャッ
シュサーバ対応プロトコル処理回路81Bを指定する値
が設定される。
コルがIPでない場合、または、上位プロトコルがIP
であっても、宛先アドレスがWebキャッシュサーバの
割り当てIPアドレスと不一致の場合は、受信パケット
にIP網対応プロトコル処理回路81Cを指定する内部
転送先情報1010を付加して、内部スイッチ送信バッ
ファ815に格納する(S1540)。上記受信パケッ
ト処理ルーチン1500の実行を繰り返すことにより、
ユーザ端末101−1〜101−mから送出されたPP
Pフレームのうち、HTTP要求メッセージを含むPP
PフレームはWebキャッシュサーバ113に、その他
のPPPフレームはIP網105に転送することが可能
となる。
処理回路81AのCPU811が実行する送信パケット
処理ルーチン1600のフローチャートを示す。ルーチ
ン1600では、内部スイッチ受信バッファ815から
図12に示したフォーマットで送信パケットを取り出し
(S1601)、該パケットをインタフェース送信バッ
ファ814に転送して(S1602)、処理を終了す
る。上記ルーチン1600の実行を繰り返すことによっ
て、Webキャッシュサーバ113から送信されたHT
TP応答メッセージを含むIPパケットと、IP網10
5側から受信したユーザ端末宛のIPパケットをアクセ
ス回線インタフェース回路80Aに転送することが可能
となる。
は、アクセス回線対応プロトコル処理回路81Aから受
信したパケットから、内部転送先情報1010とPPP
コネクション識別子1001を分離し、該アクセス回線
インタフェース回路80Aに接続されたアクセス回線1
02に送出する。例えば、ATM回線のように、1つの
アクセス回線102上で複数のコネクションが多重化さ
れていた場合、PPPフレーム1103は、PPPコネ
クション識別子1001で特定されるコネクション上に
送出される。
ロトコル処理回路81BのCPUが実行する受信パケッ
ト処理ルーチン1700のフローチャートを示す。この
ルーチン1700では、インタフェース受信バッファ9
03から、図12の(C)または(D)に示したフォー
マットをもつ受信パケットを取り出す(S1701)。
Webキャッシュサーバが送出するIPパケットは、P
PPコネクションとの対応付けがなされていないため、
バッファ903から取り出されたパケットには、PPP
コネクション識別子1001として、不特定PPPコネ
クションを意味するマジックナンバーが付加されてい
る。
ケットのIPヘッダ1005に含まれる宛先アドレスを
ユーザ端末情報管理テーブル830に登録されているユ
ーザ端末IPアドレス831と比較する(S170
2)。宛先アドレスが何れかのユーザ端末IPアドレス
と一致した場合は、ユーザ端末情報管理テーブル830
の上記宛先アドレスと対応するエントリからPPPコネ
クション識別子832を取得し(S1703)、上記エ
ントリのLCP設定オプション情報834に従って、受
信IPパケットをPPPフレームに変換する(S170
4)。この後、上記PPPフレームに、上記ステップS
1703で取得しておいたPPPコネクション識別子
と、アクセス回線対応プロトコル処理回路81Aを指定
する内部転送先情報とを付加し、図12に示したフレー
ムフォーマットで内部スイッチ送信バッファ815に格
納する(S1705)。
記宛先アドレスと一致するユーザ端末IPアドレス83
1が見つからなかった場合は、ISP情報管理テーブル
840から、キャッシュサーバの割り当てIPアドレス
842が受信IPパケットの送信元アドレスと一致する
エントリを検索し、該エントリのPPPコネクション識
別子844を取得する(S1706)。次に、上記エン
トリのLCP設定オプション情報845に従って受信I
PパケットをPPPフレームに変換し(S1707)、
上記PPPフレームに、ステップS1706で取得して
おいたPPPコネクション識別子と、IP網対応プロト
コル処理回路81Cを指定する内部転送先情報とを付加
し、図12に示したフレームフォーマットで内部スイッ
チ送信バッファ815に格納する(S1708)。
ーバ113が送信したIPパケットのうち、HTTP応
答メッセージを含むユーザ端末宛のIPパケットはアク
セス回線対応プロトコル処理回路81Aに、HTTP要
求メッセージを含むWebサーバ宛のIPパケットはI
P網対応プロトコル処理回路81Cに振り分けることが
可能となる。
ル処理回路81BのCPUが実行する送信パケット処理
ルーチン1800のフローチャートを示す。ルーチン1
800では、内部スイッチ受信バッファ816から図1
2に示したフォーマットで送信パケットを取り出し(S
1801)、PPPフレーム1103からIPパケット
を抽出する(S1802)。この後、上記IPパケット
に対して、PPPコネクション識別子1001として不
特定PPPコネクションを意味するマジックナンバーを
付加し、インタフェース送信バッファに転送する(S1
803)。この処理ルーチンによって、アクセス回線1
02−1〜102−mから受信したHTTP要求メッセ
ージと、IP網105から受信したHTTP応答メッセ
ージをWebキャッシュサーバ113に転送することが
可能となる。
81CのCPUが実行する受信パケット処理ルーチンの
フローチャート1900を示す。ルーチン1900で
は、先ず、インタフェース受信バッファ813からIP
パケットを取り出す(S1901)。IP網対応プロト
コル処理回路81Cのインタフェース受信バッファ81
3に蓄積されるパケットは、例えば、図8に示したパケ
ット706、709のように、先頭部にIPヘッダをも
つIPパケット形式となっている。これらのIPパケッ
トを受信するIP網インタフェース回路80Cは、受信
IPパケットからPPPヘッダを抽出して上位プロトコ
ルのチェックするような特殊な機能は備えていない。こ
のため、IP網インタフェース回路80Cが各IPパケ
ットに付加するPPPコネクション識別子1001は、
前述した不特定PPPコネクションを意味するマジック
ナンバーとなっている。
3からIPパケットを取り出し、該IPパケットからI
PヘッダとUDPヘッダを除去して、L2TPフレーム
を抽出する(S1902)。次に、ユーザ端末情報管理
テーブル830とISP情報管理テーブル840から、
上記L2TPフレームのL2TPヘッダが示すトンネル
IDとセッションIDに一致したL2TPコネクション
情報835または846をもつエントリを検索する(S
1903)。
ブル830から見つかった場合(S1904)、上記L
2TPフレームからPPPフレームを抽出し(S190
5)、該PPPフレームに、上記エントリが示すPPP
コネクション識別子832と、アクセス回線対応プロト
コル処理回路81Aを指定する内部転送先情報とを付加
して、図12に示すフレームフォーマットで内部スイッ
チ送信バッファ815に転送する(S1906)。
840から見つかった場合は、上記L2TPフレームか
らPPPフレームを抽出し(S1907)、該PPPフ
レームに、上記エントリが示すPPPコネクション識別
子844と、キャッシュサーバ対応プロトコル処理回路
81Bを指定する内部転送先情報1010とを付加し
て、図12に示すフォーマットで内部スイッチ送信バッ
ファ815に転送する(S1908)。
ケットのうち、Webサーバ111がWebキャッシュ
サーバ113宛に送信したHTTP応答メッセージを含
むPPPフレームは、Webキャッシュサーバ113に
転送し、その他のPPPフレームは、宛先ユーザ端末1
01−1〜101−mと対応するアクセス回線方向に転
送することが可能となる。
81CのCPUが実行する送信パケット処理ルーチン2
000のフローチャートを示す。ルーチン2000で
は、内部スイッチ受信バッファ816から、図12に示
したフォーマットの送信パケットを取り出し(S200
1)、ユーザ端末情報管理テーブル830とISP情報
管理テーブル840から、上記送信パケットに付された
PPPコネクション識別子1001と一致したPPPコ
ネクション識別子832または844をもつエントリを
検索する(S2002)。
L2TPコネクション情報835または846が示すト
ンネルIDとセッションIDの値を適用してL2TPヘ
ッダを生成し、送信PPPフレーム1103にL2TP
ヘッダ、UDPヘッダ、IPヘッダを付加してIPパケ
ット化する(S2003)。この後、上記IPパケット
に上記PPPコネクション識別子1001を付加し、イ
ンタフェース送信バッファ814に転送する(S200
4)。
〜101−mから送信されたWebトラフィック以外の
パケットと、Webキャッシュサーバ113から送出さ
れたHTTP要求メッセージを含むパケットを、地域I
P網上の適切なL2TPコネクションを介してそれぞれ
の宛先に転送することが可能となる。
の第2実施例について説明する。第2実施例は、LAC
104の構成するゲートウェイ装置が、ユーザ端末から
送信されたWebサーバ宛のパケット(Webトラフィ
ック)を強制的にWebキャッシュサーバに転送する機
能を備えたことを特徴としている。
URLで指定されたコンテンツデータがWebキャッシ
ュサーバ113に存在していた場合のパケット転送シー
ケンスを示し、図22の(B)は、(A)に示した転送
パケット中のIPヘッダに設定される宛先アドレスDA
と送信元アドレスSAとの関係を示している。
ラウザ・アプリケーションに対して、ユーザが、取得す
べきコンテンツデータのURLを指定すると、HTTP
要求メッセージを含むPPPフレーム710が生成さ
れ、ユーザ端末101−1からアクセス回線102−1
に送出される(S1010)。本実施例では、上記PP
Pフレーム710のIPヘッダIP(a)の宛先アドレ
スが、Webサーバ111のIPアドレスとなってい
る。
を含むPPPフレーム710を受信すると、IPヘッダ
の宛先アドレスをWebキャッシュサーバ113のIP
アドレスに書き換え(S1041)、IPパケット70
2としてWebキャッシュサーバ113に転送する。
104からIPパケット702を受信すると、図7の
(A)で説明した第1実施例と同様、データ部からHT
TP要求メッセージを抽出し、URLで指定されたコン
テンツデータをキャッシュデータの中から検索する(S
1131)。指定されたコンテンツデータが見つかった
場合は、コンテンツデータを含むHTTP応答メッセー
ジを生成し(S1132)、該HTTP応答メッセージ
をデータ部に含み、要求元のユーザ端末101−1のI
Pアドレスを宛先アドレスとするIPパケット703を
LAC104に送出する。
113からIPパケット703を受信すると、IPヘッ
ダの送信元アドレスをパケット710の宛先アドレス、
すなわち、ユーザがコンテンツデータを要求したWeb
サーバ111のIPアドレスに書き換え(S104
2)、PPPフレーム712に変換して、アクセス回線
102−1に転送する。
HTTP要求メッセージで指定されたコンテンツデータ
がWebキャッシュサーバ113に存在しなかった場合
のパケット転送シーケンスを示す。図23の(B)は、
図23の(A)に示した転送パケット中のIPヘッダに
設定される宛先アドレスDAと送信元アドレスSAとの
関係を示している。
迄は、図22の(A)と同一である。Webキャッシュ
サーバ113におけるコンテンツ検索(S1131)の
結果、URLで指定されたコンテンツデータがキャッシ
ュデータ中になかった場合、図8の(A)で説明した第
1実施例の同様の手順で、Webキャッシュサーバ11
3からWebサーバ111宛にHTTP要求メッセージ
を含むIPパケット705が送信され、Webサーバ1
11からWebキャッシュサーバ113に、指定コンテ
ンツデータを含むHTTP応答メッセージを含むIPパ
ケット709が返送され、Webキャッシュサーバ11
3からLAC104にユーザ端末101−1宛のHTT
P応答メッセージを含むIPパケット703が送信され
る。
113からIPパケット703を受信すると、図22の
(A)と同様、IPヘッダの送信元アドレスをWebサ
ーバ111のIPアドレスに書き換え(S1042)、
PPPフレーム712に変換して、アクセス回線102
−1に転送する。上述したパケット転送を行うために、
第2実施例のゲートウェイ装置では、図9に示した複数
のプロトコル処理回路81A〜81Cのうち、アクセス
回線対応プロトコル処理回路81Aが、図10に示した
HTTP要求メッセージ管理テーブル850を備える。
信されたHTTP要求メッセージを含むPPPフレーム
は、アクセス回線対応プロトコル処理回路81Aにおい
て、IPヘッダの宛先アドレスをWebキャッシュサー
バ113のIPアドレスに書き換えた後、Webキャッ
シュサーバに転送される。また、ユーザ端末に代わって
Webキャッシュサーバ113がWebサーバから取得
したHTTP応答メッセージを含むIPパケットは、ア
クセス回線対応プロトコル処理回路81Aにおいて、I
Pヘッダの送信元アドレスをユーザ端末が発行したHT
TP要求メッセージの宛先アドレスに書き換えた後、ユ
ーザ端末に転送される。
0は、HTTP応答メッセージの送信元IPアドレスを
ユーザ端末が発行したHTTP要求メッセージの宛先I
Pアドレスに書き換える際に必要となるものであり、例
えば、図24に示すように、ユーザ端末から受信したH
TTP要求メッセージ毎に、該メッセージのPPPフレ
ームがもつPPPコネクション識別子851と対応し
て、TCP/UDPの送信元ポート番号852と、メッ
セージの宛先IPアドレス853とを記憶している。
るパケットデータの流れを示す。ここでは、第1実施例
と共通するパケットに図15と同一の符号を付すことに
よって、重複する説明は省略する。アクセス回線対応プ
ロトコル処理回路81Aは、アクセス回線からPPPフ
レームを受信すると、PPPの上位プロトコルを識別
し、上位プロトコルがLCPの場合はLCP処理、NC
Pの場合はNCP処理を実行する。
UDPヘッダの宛先ポート番号をチェックする。宛先ポ
ート番号が、例えば、HTTPのウェルノウンポート番
号である「80」となっていた場合は、受信パケット
(HTTP要求メッセージ)をキャッシュサーバ113
に転送するために、宛先IPアドレス変換処理1509
を実行して、IPヘッダの宛先アドレスをWebキャッ
シュサーバのIPアドレス値に書換える。
Pコネクション識別子1001の前にキャッシュサーバ
対応プロトコル処理回路81Bを指定する内部転送先情
報1010を付加した形で、内部スイッチ87に送出さ
れる。このパケットは、図15に示した第1実施例と同
様、キャッシュサーバ対応プロトコル処理回路81Bを
介して、キャッシュサーバ113にIPパケット702
として転送される。上位プロトコルがLCP、NCP、
IP以外の受信パケット、または、宛先ポート番号が
「80」以外のIPパケットは、IP網対応プロトコル
処理回路81Cを指定する内部転送先情報1010を付
加した形で、内部スイッチ87に送出される。
702を受信すると、HTTP要求メッセージのURL
で指定されたコンテンツデータをキャッシュデータの中
から検索し、検索結果に応じて、ユーザ端末宛のHTT
P応答メッセージを含むIPパケット703、またはW
ebサーバ111宛のHTTP要求メッセージを含むI
Pパケット705を発生する。
バ対応プロトコル処理回路81Bにおいて宛先IPアド
レスに従って処理され、ユーザ端末宛のIPアドレスを
もつHTTP応答メッセージ用のパケットは、アクセス
回線対応プロトコル処理回路81Aに転送され、Web
サーバ宛のIPアドレスをもつHTTP要求メッセージ
用のパケットは、IP網対応プロトコル処理回路81C
に転送される。キャッシュサーバ対応プロトコル処理回
路81Bと、IP網対応プロトコル処理回路81Cの動
作は、第1実施例と同様である。
TTP応答メッセージを含むIPパケット703は、ア
クセス回線対応プロトコル処理回路81Aが実行する送
信元IPアドレス変換処理1613によって、送信元I
PアドレスをWebサーバのIPアドレスに書き換えた
後、PPPパケット712として要求元のユーザ端末に
転送される。
理回路81AのCPUが実行する受信パケット処理ルー
チン1500−2のフローチャートを示す。図16と同
一の符号をもつ処理ステップは、第1実施例と共通して
いるため説明を省略する。受信したPPPフレームの上
位プロトコルがIPの場合(S1504)、IPの上位
プロトコルを判定する(S1506)。IPの上位プロ
トコルがTCPまたはUDPの場合、TCP/UDPの
宛先ポート番号を識別する(S1507)。宛先ポート
番号が、HTTPのウェルノウンポート番号である「8
0」であれば、受信PPPフレームをWebトラフィッ
クと判断し、以下の処理を行う。
識別子と、TCP/UDPの送信元ポート番号と、宛先
IPアドレスの関係を示す新たなエントリを生成し、H
TTP要求メッセージ管理テーブル850に設定する
(S1508)。次に、受信PPPフレームのIPヘッ
ダが示す宛先アドレスをWebキャッシュサーバのIP
アドレスに書き換える(S1509)。この時、宛先ア
ドレスの書換えに伴って、IPヘッダに含まれるヘッダ
チェックサムと、PPPフレームのFCS(Frame Chec
k Sequence)を再計算し、それぞれの値を更新する。最
後に、受信PPPフレームに、PPPコネクション識別
子1001と、Webキャッシュサーバ対応プロトコル
処理回路81Bを指定する内部転送先情報1010を付
加し、内部スイッチ送信バッファ815に格納して(S
1510、処理を終了する。
場合、IPであっても上位プロトコルがTCPかUDP
でない場合、あるいは、TCP/UDPであっても宛先
ポート番号が「80」でない場合は、受信PPPフレー
ムをWebトラフィック用以外のものと判断し、PPP
コネクション識別子1001と、IP網対応プロトコル
処理回路81Cを指定する内部転送先情報1010とを
付加して、内部スイッチ送信バッファ815に格納する
(S1540)。以上の処理により、ユーザ端末101
−1〜101−mからWebサーバ宛に送出されたHT
TP要求メッセージを含むPPPフレームをPPPコネ
クションから分離し、Webキャッシュサーバに転送す
ることが可能となる。
処理回路81AのCPUが実行する送信パケット処理ル
ーチン1600−2のフローチャートを示す。このルー
チンでは、内部スイッチ受信バッファ816から送信P
PPフレームを取り出し(S1611)、送信PPPフ
レームに付されたPPPコネクション識別子1001
と、送信PPPフレームに含まれるIPパケット内のT
CP/UDPヘッダから抽出した宛先ポート番号とに基
づいて、HTTP要求メッセージ管理テーブル850を
参照し、PPPコネクション識別子851と送信元ポー
ト番号852が上記送信PPPフレームのPPPコネク
ション識別子および宛先ポートに一致するエントリを検
索する(1612)。
セージの宛先IPアドレス853の値を求め、送信PP
Pフレームに含まれるIPパケットの送信元IPアドレ
スを上記宛先IPアドレスの値に書き換える(S161
3)。この時、IPヘッダのヘッダチェックサムとPP
PフレームのFCSを再計算し、それぞれの値を更新す
る。宛先IPアドレスが書き換えられた送信PPPフレ
ームは、PPPコネクションの識別子1001を付加し
た形でインタフェース送信バッファ814に格納される
(S1614)。上記送信バッファ814に格納された
PPPフレームは、アクセス回線インタフェース回路8
0Aに転送され、PPPコネクション識別子1001を
除去した後、送信先ユーザ端末の接続回線に送出され
る。
1つのWebキャッシュサーバに、地域IP網に接続さ
れる複数のISPと対応した複数のIPアドレスを割り
当てることによって、HTTP要求メッセージの送信元
ユーザが上記何れのISPに加入していた場合でも、同
一のWebキャッシュサーバで応答できるようにしてい
る。しかしながら、本発明の変形例として、LACにそ
れぞれが異なるISPと対応づけられた複数のWebキ
ャッシュサーバを接続しておき、LACが、Webトラ
フィック用IPパケットを送信元ユーザの加入ISPと
対応したWebキャッシュサーバに選択的に分配するよ
うにしてもよい。
のゲートウェイ装置は、PPPコネクション上でのIP
パケットの中継機能と、PPPコネクションからのWe
bトラフィック用IPパケットの分離機能とを備えてい
るため、これをISP選択型のアクセスネットワークシ
ステムにおけるLACとして使用し、ゲートウェイ装置
にWebキャッシュサーバを接続することによって、L
ACを通過するパケット列からWebトラフィック用の
IPパケットを選択的に分離し、上記Webキャッシュ
サーバに転送することができる。
要求に対して、コンテンツを提供するWebサーバに代
わってWebキャッシュサーバが応答メッセージを返送
することが可能となり、LACとISPネットワークと
を接続する地域IP網(インターネットアクセス網)に
おけるトラヒックを軽減でき、ユーザにとっては、We
bサーバアクセスに対するレスポンスが改善されるとい
う利点がある。
れるISP選択型ネットワークシステムの1例を示す
図。
て、ユーザ端末とLACとの間にPPPコネクションが
設定された状態を示す図。
て、PPPコネクションがLNSまで延長された状態を
示す図。
て、キャッシュサーバとWebサーバ間の通信用のPP
Pコネクションが設定された状態を示す図。
Pフレームのプロトコルフィールドに設定される代表的
な識別値(B)を示す図。
ワークシステムにおいて、ユーザ端末がWebコンテン
ツデータを取得する場合のパケット転送シーケンス
(A)と、各転送パケットに付されるIPヘッダの宛先
アドレスDAと送信元アドレスSAとの関係(B)を示
す図。
置を適用したISP選択型ネットワークシステムにおい
て、ユーザ端末が要求するWebコンテンツデータがキ
ャッシュサーバに存在した場合のパケット転送シーケン
ス(A)と、各転送パケットに付されるIPヘッダの宛
先アドレスDAと送信元アドレスSAとの関係(B)を
示す図。
置を適用したISP選択型ネットワークシステムにおい
て、ユーザ端末が要求するWebコンテンツデータがキ
ャッシュサーバに存在しなかった場合のパケット転送シ
ーケンス(A)と、各転送パケットに付されるIPヘッ
ダの宛先アドレスDAと送信元アドレスSAとの関係
(B)を示す図。
の構成を示すブロック図。
A〜81C)の構成を示すブロック図。
フェース回路80(80A〜80C)とプロトコル処理
回路81(81A〜81C)との間で転送されるパケッ
トデータのフォーマットを示す図。
コル処理回路81(81A〜81C)プロトコル処理回
路と内部スイッチ87との間で転送されるパケットデー
タのフォーマットを示す図。
C)が備えるユーザ端末情報テーブル830の1実施例
を示す図。
C)が備えるISP情報テーブル840の1実施例を示
す図。
AC)の内部におけるデータの流れを説明するための
図。
で実行される受信パケット処理ルーチン1500の1実
施例を示すフローチャート。
で実行される送信パケット処理ルーチン1600の1実
施例を示すフローチャート。
1Bで実行される受信パケット処理ルーチン1700の
1実施例を示すフローチャート。
1Bで実行される送信パケット処理ルーチン1800の
1実施例を示すフローチャート。
される受信パケット処理ルーチン1900の1実施例を
示すフローチャート。
される送信パケット処理ルーチン2000の1実施例を
示すフローチャート。
装置を適用したISP選択型ネットワークシステムにお
いて、ユーザ端末が要求するWebコンテンツデータが
キャッシュサーバに存在した場合のパケット転送シーケ
ンス(A)と、各転送パケットに付されるIPヘッダの
宛先アドレスDAと送信元アドレスSAとの関係(B)
を示す図。
装置を適用したISP選択型ネットワークシステムにお
いて、ユーザ端末が要求するWebコンテンツデータが
キャッシュサーバに存在しなかった場合のパケット転送
シーケンス(A)と、各転送パケットに付されるIPヘ
ッダの宛先アドレスDAと送信元アドレスSAとの関係
(B)を示す図。
対応プロトコル処理回路81Aが備えるHTTP要求メ
ッセージ管理テーブル850の1実施例を示す図。
AC)の内部におけるデータの流れを説明するための
図。
いて、アクセス回線対応プロトコル処理回路81Aで実
行される受信パケット処理ルーチン1500−2の1例
を示すフローチャート。
いて、アクセス回線対応プロトコル処理回路81Aで実
行される送信パケット処理ルーチン1600−2の1例
を示すフローチャート。
ユーザ端末用PPPコネクション、104:LAC、1
05:地域IP網、106:L2TPコネクション、1
97:LNS、108:ISPネットワーク、109:
ルータ、110:インターネット、111:Webサー
バ、112:LAN、113:Webキャッシュサー
バ、114:RADIUSサーバ、116:キャッシュ
サーバ用PPPコネクション、120:RADIUSサ
ーバ、130:DNSサーバ、80A:アクセス回線イ
ンタフェース回路、80B:キャッシュサーバインタフ
ェース回路、80C:IP網インタフェース回路、81
A:アクセス回線対応プロトコル処理回路、81B:キ
ャッシュサーバ対応プロトコル処理回路、81C:IP
網対応プロトコル処理回路、87:内部スイッチ回路、
88:ノード制御回路、90:制御端末、811:CP
U、812:メモリ、813:インタフェース受信バッ
ファ、814:インタフェース送信バッファ、815:
内部スイッチ送信バッファ、816:内部スイッチ受信
バッファ、817:CPU間通信インタフェース回路、
820:プログラム格納領域、830:ユーザ端末情報
管理テーブル、840:ISP情報管理テーブル、85
0:HTTP要求メッセージ管理テーブル、1001:
PPPコネクション識別子、1002:PPPヘッダ、
1003:ペイロード部、1005:IPヘッダ、10
06:HTTP要求メッセージ、1007:HTTP応
答メッセージ、1008:非HTTPデータ、101
0:内部転送先情報。
Claims (11)
- 【請求項1】インターネットに接続された少なくとも1
つのISP(Internet Service Provider)ネットワー
クを収容するアクセス網に接続され、ユーザ端末から受
信したPPP(Point to Point Protocol)フレームを
上記アクセス網上に設定されたL2TP(Layer2 Tunne
ling Protocol)コネクションを介して上記ISPネッ
トワークに転送するLAC(L2TP Access Concentrato
r)機能を備えたゲートウェイ装置において、 上記インターネットに接続されたWebサーバによって
提供されるコンテンツデータの一部をキャッシュデータ
として保持するキャッシュサーバとパケット通信するた
めのキャッシュサーバインタフェースと、 ユーザ端末から受信したPPPフレーム列の中からペイ
ロード部にWebコンテンツの要求メッセージを含むP
PPフレームを選択し、該PPPフレームが示す要求メ
ッセージを上記キャッシュサーバインタフェースを介し
て上記キャッシュサーバに転送し、上記キャッシュサー
バインタフェースを介して上記キャッシュサーバから受
信した応答メッセージをWebコンテンツ要求元のユー
ザ端末にPPPフレーム形式で転送するパケット転送制
御手段とを備えたことを特徴とするゲートウェイ装置。 - 【請求項2】前記パケット転送制御手段が、前記ユーザ
端末から受信した各PPPフレームに含まれるIPヘッ
ダの宛先アドレスと前記キャッシュサーバに割り当てら
れた特定のIPアドレスとの関係をチェックすることに
よって、Webコンテンツ要求メッセージを含むPPP
フレームを識別することを特徴とする請求項1に記載の
ゲートウェイ装置。 - 【請求項3】前記パケット転送制御手段が、前記アクセ
ス網に収容された複数のISPネットワークと対応して
前記キャッシュサーバに割り当てられた複数のIPアド
レスを記憶するための手段を備え、前記ユーザ端末から
受信した各PPPフレームに含まれるIPヘッダの宛先
アドレスと、前記キャッシュサーバに割り当てられた上
記PPPフレームの送信元ユーザが加入しているISP
ネットワークと対応する特定のIPアドレスとの関係を
チェックすることによって、Webコンテンツ要求メッ
セージを含むPPPフレームを識別することを特徴とす
る請求項2に記載のゲートウェイ装置。 - 【請求項4】前記パケット転送制御手段が、前記ユーザ
端末から受信した各PPPフレームに含まれるIPパケ
ットの上位プロトコルをチェックすることによって、W
ebコンテンツ要求メッセージを含むPPPフレームを
識別することを特徴とする請求項1に記載のゲートウェ
イ装置。 - 【請求項5】前記パケット転送制御手段が、前記各PP
Pフレームに含まれるIPパケットのTCP(Transmis
sion Control Protocol)またはUDP(Use Datagram
Protocol)におけるポート番号から、前記Webコンテ
ンツ要求メッセージを含むPPPフレームを識別するこ
とを特徴とする請求項4に記載のゲートウェイ装置。 - 【請求項6】前記パケット転送制御手段が、前記キャッ
シュサーバインタフェースを介して前記キャッシュサー
バから受信した前記Webサーバ宛のWebコンテンツ
要求メッセージをPPPフレームに変換して前記L2T
Pコネクションに送出するための手段を備えたことを特
徴とする請求項1〜請求項5の何れかに記載のゲートウ
ェイ装置。 - 【請求項7】インターネットに接続されたISP(Inte
rnet Service Provider)ネットワークを収容するため
の複数のLNS(L2TP Network Server)とアクセス網
を介して接続され、アクセス回線を介してユーザ端末か
ら受信したPPP(Point toPoint Protocol)フレーム
を上記アクセス網上に設定されたL2TP(Layer2Tunn
eling Protocol)コネクションを介して上記何れかのL
NSに転送するLAC(L2TP Access Concentrator)機
能を備えたゲートウェイ装置において、上記インターネ
ットに接続されたWebサーバが提供するコンテンツデ
ータの一部をキャッシュデータとして保持するキャッシ
ュサーバと通信するためのキャッシュサーバインタフェ
ースと、上記アクセス回線を介してユーザ端末と通信す
るためのアクセス回線インタフェースと、上記アクセス
網を介して上記LNSと通信するためのアクセス網イン
タフェースと、上記各インタフェースからの受信パケッ
トに所定のプロトコル処理を施した後、他のインタフェ
ース回路に選択的に転送するためのパケット転送制御装
置とを有し、上記パケット転送制御装置が、上記アクセ
ス回線インタフェースで受信したPPPフレーム列の中
からペイロード部にWebコンテンツ要求メッセージを
含むものを選択し、該PPPフレームから抽出されたW
ebコンテンツ要求メッセージを上記キャッシュサーバ
インタフェースを介してキャッシュサーバに転送するこ
とを特徴とするゲートウェイ装置。 - 【請求項8】前記パケット転送制御装置が、前記アクセ
ス回線インタフェースで受信した各PPPフレームに含
まれるIPヘッダの宛先アドレスと前記キャッシュサー
バに割り当てられた特定のIPアドレスとの関係をチェ
ックすることによって、Webコンテンツ要求メッセー
ジを含むPPPフレームを識別することを特徴とする請
求項7に記載のゲートウェイ装置。 - 【請求項9】前記パケット転送制御装置が、前記アクセ
ス回線から受信した各PPPフレームに含まれるIPパ
ケットの上位プロトコルをチェックすることによって、
Webコンテンツ要求メッセージを含むPPPフレーム
を識別することを特徴とする請求項7に記載のゲートウ
ェイ装置。 - 【請求項10】前記パケット転送制御装置が、前記キャ
ッシュサーバインタフェースを介して前記キャッシュサ
ーバから受信した前記Webサーバ宛のWebコンテン
ツ要求メッセージを前記ユーザ端末から受信したPPP
フレームとは異なるPPPヘッダをもつPPPフレーム
に変換し、前記アクセス網上に設定された何れかのL2
TPコネクションに送出するための手段を備えたことを
特徴とする請求項7〜請求項9の何れかに記載のゲート
ウェイ装置。 - 【請求項11】インターネットに接続された複数のIS
P(Internet Service Provider)ネットワークを収容
するアクセス網に接続され、ユーザ端末から受信したP
PP(Point to Point Protocol)フレームを上記アク
セス網上に設定されたL2TP(Layer2 Tunneling Pro
tocol)コネクションを介して上記ユーザ端末のユーザ
が加入しているISPと対応した上記何れかのISPネ
ットワークに転送するLAC(L2TP Access Concentrat
or)機能を備えたゲートウェイ装置において、上記イン
ターネットに接続されたWebサーバによって提供され
るコンテンツデータの一部をキャッシュデータとして保
持するキャッシュサーバとパケット通信するためのキャ
ッシュサーバインタフェースと、加入先ISPが異なる
複数のユーザ端末から受信した複数のPPPフレームの
中からペイロード部にWebコンテンツの要求メッセー
ジを含むPPPフレームを選択し、該PPPフレームが
示す要求メッセージを上記キャッシュサーバインタフェ
ースを介して上記キャッシュサーバに転送し、上記キャ
ッシュサーバインタフェースを介して上記キャッシュサ
ーバから受信した応答メッセージを含むIPパケットを
Webコンテンツ要求元のユーザ端末にPPPフレーム
形式で転送するパケット転送制御手段とを備えたことを
特徴とするゲートウェイ装置。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001332775A JP3655575B2 (ja) | 2001-10-30 | 2001-10-30 | ゲートウェイ装置 |
US10/057,835 US6816890B2 (en) | 2001-05-28 | 2002-01-24 | Gateway apparatus with LAC function |
US10/951,856 US6981026B2 (en) | 2001-05-28 | 2004-09-27 | Gateway apparatus with LAC function |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001332775A JP3655575B2 (ja) | 2001-10-30 | 2001-10-30 | ゲートウェイ装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2003143236A true JP2003143236A (ja) | 2003-05-16 |
JP3655575B2 JP3655575B2 (ja) | 2005-06-02 |
Family
ID=19148148
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001332775A Expired - Fee Related JP3655575B2 (ja) | 2001-05-28 | 2001-10-30 | ゲートウェイ装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3655575B2 (ja) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007519379A (ja) * | 2004-01-22 | 2007-07-12 | 株式会社東芝 | Ipアクセスネットワークを用いたマルチホーミング及びサービスネットワーク選択 |
JP2008035037A (ja) * | 2006-07-27 | 2008-02-14 | Hitachi Communication Technologies Ltd | パケット転送制御方法およびパケット転送装置 |
WO2009122915A1 (ja) * | 2008-04-02 | 2009-10-08 | 日本電気株式会社 | 通信システム及び通信方法 |
US8521216B2 (en) | 2003-05-29 | 2013-08-27 | Kyocera Corporation | Wireless transmission system |
JP2014508433A (ja) * | 2010-12-30 | 2014-04-03 | エフオーエヌ・テクノロジー | セキュアトンネル型プラットホームシステムおよび方法 |
CN112702313A (zh) * | 2020-12-01 | 2021-04-23 | 深圳市紫光同创电子有限公司 | 高速udp数据发送***及方法 |
CN113473651A (zh) * | 2015-06-10 | 2021-10-01 | 株式会社宙连 | 用于向无线终端提供对ip网络的访问的通信***及通信方法 |
-
2001
- 2001-10-30 JP JP2001332775A patent/JP3655575B2/ja not_active Expired - Fee Related
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8903385B2 (en) | 2003-05-29 | 2014-12-02 | Kyocera Corporation | Wireless transmission system |
US8639283B2 (en) | 2003-05-29 | 2014-01-28 | Kyocera Corporation | Wireless transmission system |
US8682294B2 (en) | 2003-05-29 | 2014-03-25 | Kyocera Corporation | Wireless transmission system |
US8521216B2 (en) | 2003-05-29 | 2013-08-27 | Kyocera Corporation | Wireless transmission system |
JP4675909B2 (ja) * | 2004-01-22 | 2011-04-27 | 株式会社東芝 | Ipアクセスネットワークを用いたマルチホーミング及びサービスネットワーク選択 |
US7860978B2 (en) | 2004-01-22 | 2010-12-28 | Toshiba America Research, Inc. | Establishing a secure tunnel to access router |
JP2007519379A (ja) * | 2004-01-22 | 2007-07-12 | 株式会社東芝 | Ipアクセスネットワークを用いたマルチホーミング及びサービスネットワーク選択 |
JP4732974B2 (ja) * | 2006-07-27 | 2011-07-27 | 株式会社日立製作所 | パケット転送制御方法およびパケット転送装置 |
JP2008035037A (ja) * | 2006-07-27 | 2008-02-14 | Hitachi Communication Technologies Ltd | パケット転送制御方法およびパケット転送装置 |
WO2009122915A1 (ja) * | 2008-04-02 | 2009-10-08 | 日本電気株式会社 | 通信システム及び通信方法 |
JP5263287B2 (ja) * | 2008-04-02 | 2013-08-14 | 日本電気株式会社 | 通信システム及び通信方法 |
US8699482B2 (en) | 2008-04-02 | 2014-04-15 | Nec Corporation | Communication system and communication method |
JP2014508433A (ja) * | 2010-12-30 | 2014-04-03 | エフオーエヌ・テクノロジー | セキュアトンネル型プラットホームシステムおよび方法 |
CN113473651A (zh) * | 2015-06-10 | 2021-10-01 | 株式会社宙连 | 用于向无线终端提供对ip网络的访问的通信***及通信方法 |
CN113473651B (zh) * | 2015-06-10 | 2024-04-30 | 株式会社宙连 | 用于向无线终端提供对ip网络的访问的通信***及通信方法 |
CN112702313A (zh) * | 2020-12-01 | 2021-04-23 | 深圳市紫光同创电子有限公司 | 高速udp数据发送***及方法 |
CN112702313B (zh) * | 2020-12-01 | 2022-11-01 | 深圳市紫光同创电子有限公司 | 高速udp数据发送***及方法 |
Also Published As
Publication number | Publication date |
---|---|
JP3655575B2 (ja) | 2005-06-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6816890B2 (en) | Gateway apparatus with LAC function | |
EP1234246B1 (en) | System and method for network access without reconfiguration | |
US7733859B2 (en) | Apparatus and method for packet forwarding in layer 2 network | |
JP5621778B2 (ja) | コンテンツベーススイッチシステム、及びコンテンツベーススイッチ方法 | |
US8499083B2 (en) | Relay device and communication system | |
US7697427B2 (en) | Method and system for scaling network traffic managers | |
US6456603B1 (en) | Method of supporting communications mobility in a telecommunications system | |
JP2000022740A (ja) | ネットワークコンテンツキャッシュ方法及び装置 | |
US20150127837A1 (en) | Relay apparatus and data transfer method | |
US7564848B2 (en) | Method for the establishing of connections in a communication system | |
US20030135646A1 (en) | Relay method for distributing packets to optimal server | |
JP3655575B2 (ja) | ゲートウェイ装置 | |
EP1530846B1 (en) | Dynamic file-based routing in a broadband communications system | |
EP1593230B1 (en) | Terminating a session in a network | |
US9338230B2 (en) | Method, network entity and network system for forwarding resources | |
JP2005184110A (ja) | パケット転送装置およびパケット転送方法 | |
WO2018121443A1 (zh) | 报文传输方法及装置 | |
KR100397673B1 (ko) | 씨디엔을 이용한 클라이언트간 직접 데이터 통신 방법 | |
JP2003258859A (ja) | 通信システム、通信方法、転送装置及びネットワーク管理装置 | |
JP2004158973A (ja) | パケット中継装置 | |
US20040258056A1 (en) | Provider connection system, packet exchange apparatus thereof, dns server, packet exchange method, and computer program thereof | |
WO2011026355A1 (zh) | 节点接入家乡代理的方法、家乡代理集群***及业务路由器 | |
JPH10173708A (ja) | 簡易ルーチング方式 | |
JP4025697B2 (ja) | パケット転送装置およびその制御方法 | |
JP3886103B2 (ja) | 通信システム、通信方法、並びにこれに用いられる通信装置および通信プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20040209 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050126 |
|
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: 20050215 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050303 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090311 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090311 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100311 Year of fee payment: 5 |
|
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: 20100311 Year of fee payment: 5 |
|
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: 20110311 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110311 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120311 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130311 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130311 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140311 Year of fee payment: 9 |
|
LAPS | Cancellation because of no payment of annual fees |