JP2001285354A - 通信路設定方法 - Google Patents
通信路設定方法Info
- Publication number
- JP2001285354A JP2001285354A JP2000097813A JP2000097813A JP2001285354A JP 2001285354 A JP2001285354 A JP 2001285354A JP 2000097813 A JP2000097813 A JP 2000097813A JP 2000097813 A JP2000097813 A JP 2000097813A JP 2001285354 A JP2001285354 A JP 2001285354A
- Authority
- JP
- Japan
- Prior art keywords
- communication
- network
- setting
- communication path
- l2tp
- 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.)
- Pending
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
(57)【要約】
【課題】 インターネット上のVPNの通信帯域を確保で
きず、また、VPNを設定するための処理遅延が生じる。 【解決手段】 リモートユーザからアクセスコンセント
レータまでの通信路が設定される際に、アクセスコンセ
ントレータからアクセスサーバ間でRSVPにより通信帯域
を確保し、アクセスコンセントレータからアクセスサー
バまでのVPNも同時に設定する。
きず、また、VPNを設定するための処理遅延が生じる。 【解決手段】 リモートユーザからアクセスコンセント
レータまでの通信路が設定される際に、アクセスコンセ
ントレータからアクセスサーバ間でRSVPにより通信帯域
を確保し、アクセスコンセントレータからアクセスサー
バまでのVPNも同時に設定する。
Description
【発明の属する技術分野】公衆通信網とインターネット
とを接続するネットワーク装置において、動的に通信路
を設定する方法に関する。
とを接続するネットワーク装置において、動的に通信路
を設定する方法に関する。
【従来の技術】企業の社内LAN等のプライベートネット
ワークに遠隔地からアクセスするリモートアクセス方法
として、一般的に公衆通信網を利用しダイヤルアップPP
P接続することが行われている(PPPはRFC1661、http://w
ww.ietf.org/ 参照)。これまで、遠隔地にいるリモート
ユーザが電話をかけてPPP接続する装置(アクセスサー
バ)は通常プライベートネットワーク内にあるため、遠
距離の電話料金がかさむ場合が多かった。近年ではこの
電話の通話料金を抑えるため、インターネットを利用し
たリモートアクセスが盛んになってきている(アスキー
出版、VLAN/VPN教科書参照)。そのうちのひとつに、公
衆通信網のインターネットへの出口にリモートアクセス
のための装置(アクセスコンセントレータ)をおき、アク
セスコンセントレータとプライベートネットワークにあ
るアクセスサーバまでの区間でインターネット上にVPN
(Virtual Private Network)(上記VLAN/VPN教科書参照)
を設定する方法がある。この方法はインターネットを利
用して、利用料金が必要な公衆通信網を利用する区間を
できるだけ短くしようとするもので、電話の通話料金の
削減に非常に効果的である。しかし、インターネット上
では公衆通信網と異なり通常通信帯域が保証されない。
インターネット上で通信帯域を確保する方法としてRSVP
(RFC2205、http://www.ietf.org/ 参照)を利用すること
が考えられるが、上記のようにVPNを利用する場合に
は、VPNが設定完了するまでリモート端末とプライベー
トネットワーク内の装置間でのRSVPの制御メッセージが
交換できないため、VPN自身の帯域が確保されないとい
う課題がある。また、上記のインターネット上のVPNを
設定するためのプロトコルは複数存在する(例えばL2TP
がある。RFC2661、http://www.ietf.org/ を参照)が、
いずれもVPNを設定する手順は次のようである。 リモートユーザが公衆通信網に対しアクセスコンセン
トレータまでの通信路設定を要求し、公衆網は通信路を
設定する。この時点では公衆通信網内にのみ通信路が設
定される。 リモートユーザがプライベートネットワーク内のアク
セスサーバに対してPPP接続の確立を要求する。しか
し、この時点ではまだアクセスコンセントレータからア
クセスサーバまでの通信路(インターネット上のVPN)は
設定されていない。 アクセスコンセントレータは、リモートユーザがアク
セスサーバに対してPPP接続の確立を要求したことを契
機に、アクセスコンセントレータからアクセスサーバま
でのVPNを設定する。リモートユーザのアクセスサーバ
に対するPPP接続の確立要求パケットはVPNが設定される
までアクセスコンセントレータにためて置かれる。 アクセスコンセントレータとアクセスサーバ間のVPN
が設定された後、アクセスコンセントレータにためて置
かれた、リモートユーザのアクセスサーバに対するPPP
接続の確立要求パケットがアクセスサーバに送られる。 PPP接続が確立され、リモートユーザはプライベート
ネットワークにアクセスできる。インターネット上にVP
Nを設定する方法は、それまでのインターネットを利用
しない方法と比べると、上記の手続きが余分に必要と
なっており、その分処理時間に遅延が生じるという課題
がある。
ワークに遠隔地からアクセスするリモートアクセス方法
として、一般的に公衆通信網を利用しダイヤルアップPP
P接続することが行われている(PPPはRFC1661、http://w
ww.ietf.org/ 参照)。これまで、遠隔地にいるリモート
ユーザが電話をかけてPPP接続する装置(アクセスサー
バ)は通常プライベートネットワーク内にあるため、遠
距離の電話料金がかさむ場合が多かった。近年ではこの
電話の通話料金を抑えるため、インターネットを利用し
たリモートアクセスが盛んになってきている(アスキー
出版、VLAN/VPN教科書参照)。そのうちのひとつに、公
衆通信網のインターネットへの出口にリモートアクセス
のための装置(アクセスコンセントレータ)をおき、アク
セスコンセントレータとプライベートネットワークにあ
るアクセスサーバまでの区間でインターネット上にVPN
(Virtual Private Network)(上記VLAN/VPN教科書参照)
を設定する方法がある。この方法はインターネットを利
用して、利用料金が必要な公衆通信網を利用する区間を
できるだけ短くしようとするもので、電話の通話料金の
削減に非常に効果的である。しかし、インターネット上
では公衆通信網と異なり通常通信帯域が保証されない。
インターネット上で通信帯域を確保する方法としてRSVP
(RFC2205、http://www.ietf.org/ 参照)を利用すること
が考えられるが、上記のようにVPNを利用する場合に
は、VPNが設定完了するまでリモート端末とプライベー
トネットワーク内の装置間でのRSVPの制御メッセージが
交換できないため、VPN自身の帯域が確保されないとい
う課題がある。また、上記のインターネット上のVPNを
設定するためのプロトコルは複数存在する(例えばL2TP
がある。RFC2661、http://www.ietf.org/ を参照)が、
いずれもVPNを設定する手順は次のようである。 リモートユーザが公衆通信網に対しアクセスコンセン
トレータまでの通信路設定を要求し、公衆網は通信路を
設定する。この時点では公衆通信網内にのみ通信路が設
定される。 リモートユーザがプライベートネットワーク内のアク
セスサーバに対してPPP接続の確立を要求する。しか
し、この時点ではまだアクセスコンセントレータからア
クセスサーバまでの通信路(インターネット上のVPN)は
設定されていない。 アクセスコンセントレータは、リモートユーザがアク
セスサーバに対してPPP接続の確立を要求したことを契
機に、アクセスコンセントレータからアクセスサーバま
でのVPNを設定する。リモートユーザのアクセスサーバ
に対するPPP接続の確立要求パケットはVPNが設定される
までアクセスコンセントレータにためて置かれる。 アクセスコンセントレータとアクセスサーバ間のVPN
が設定された後、アクセスコンセントレータにためて置
かれた、リモートユーザのアクセスサーバに対するPPP
接続の確立要求パケットがアクセスサーバに送られる。 PPP接続が確立され、リモートユーザはプライベート
ネットワークにアクセスできる。インターネット上にVP
Nを設定する方法は、それまでのインターネットを利用
しない方法と比べると、上記の手続きが余分に必要と
なっており、その分処理時間に遅延が生じるという課題
がある。
【発明が解決しようとする課題】本発明はインターネッ
ト上のVPNの通信帯域を確保する手段を提供すること、
および上記の手続きによる処理時間遅延を低減するこ
とを目的とする。
ト上のVPNの通信帯域を確保する手段を提供すること、
および上記の手続きによる処理時間遅延を低減するこ
とを目的とする。
【課題を解決するための手段】VPNの通信帯域を確保す
るため、VPNを設定する際、まずアクセスコンセントレ
ータとアクセスサーバ間においてRSVPにより通信帯域を
確保し、その後アクセスコンセントレータとアクセスサ
ーバ間のVPNを設定する。また、VPN設定の処理遅延を低
減するため、リモートユーザのアクセスサーバに対する
PPP接続の確立要求ではなく、リモートユーザの公衆通
信網に対するアクセスコンセントレータまでの通信路設
定要求を契機としてインターネット上にVPNを設定す
る。すなわち、リモートユーザからアクセスコンセント
レータまでの通信路が設定される際に、アクセスコンセ
ントレータからアクセスサーバまでのインターネット上
のVPNも並行して設定する。
るため、VPNを設定する際、まずアクセスコンセントレ
ータとアクセスサーバ間においてRSVPにより通信帯域を
確保し、その後アクセスコンセントレータとアクセスサ
ーバ間のVPNを設定する。また、VPN設定の処理遅延を低
減するため、リモートユーザのアクセスサーバに対する
PPP接続の確立要求ではなく、リモートユーザの公衆通
信網に対するアクセスコンセントレータまでの通信路設
定要求を契機としてインターネット上にVPNを設定す
る。すなわち、リモートユーザからアクセスコンセント
レータまでの通信路が設定される際に、アクセスコンセ
ントレータからアクセスサーバまでのインターネット上
のVPNも並行して設定する。
【発明の実施の形態】以下、第３世代移動体通信方法で
あるGPRS発展方法(3GPP TS 23.060および29.060、http:
//www.3gpp.org/TSG/Dec99_status_list.htm 参照)によ
るIMT-2000パケット通信網(以下GPRS網と呼ぶ) を公衆
通信網の例、L2TPをVPN設定プロトコルの例とし、図面
をもとに説明する。 図１に本発明による、リモートユ
ーザがプライベートネットワークにアクセスする際の通
信手順を示す。図２はリモートアクセスを行う場合の全
体のネットワーク構成を示す。L2TPではアクセスコンセ
ントレータのことをLAC(L2TP Access Concentrator)、
アクセスサーバのことをLNS(L2TP Network Server)と呼
ぶ。図２ではGGSNがLACを兼ねている。 リモートユー
ザがGPRS網を利用する場合、通信の前に必ずGPRS網に対
して携帯端末から Activate PDP context request (10
1)が発行される。これはGPRS網内にSGSN(202)からGGSN/
LAC(203)までの通信路の設定を要求するものであり、リ
モートユーザのユーザ識別番号、リモートユーザの通信
先の名前(例えばISPの名前)などが含まれている。図7に
GPRSメッセージのフォーマットを示すが、このうちTID
にユーザ識別番号が含まれ、そのフォーマットを図8に
示す。また、図7のInformation Elementの部分に通信先
の名前が含まれ、Information Elementの例を図9に示
す。GPRS発展方法では、ユーザデータも図7と同じフォ
ーマットで転送され、図7のInformation Elements の部
分にユーザデータが収められる。そして、GPRSメッセー
ジとユーザデータはさらにUDP(図12にフォーマットを示
す)、およびIP(図11にフォーマットを示す)のヘッダを
付加され、GPRS網内を転送される。リモートユーザがGP
RS網を利用してプライベートネットワークにアクセスを
する際、Activate PDP context request (101) がSGSN
(202)に向かって携帯端末から発行される。SGSN(202)で
このメッセージを処理した後、同様の内容のメッセージ
(Create PDP context request)(101-2)がGGSN/LAC(203)
に送られる。GGSN/LAC(203)ではこのメッセージを契機
としてSGSN(202)との間でユーザデータ用の通信路を設
定し、設定が完了するとSGSN(202)へＣｒｅａｔｅ Ｐ
ＤＰ ｃｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅ（１０２）を
送る。これを受けたＳＧＳＮ（２０２）は、通信可能で
あることを通知するため携帯端末へActivate PDP conte
xt accept(102-2)のメッセージを送り、この後携帯端末
はLNS(204)に対してPPP接続を開始する。 一方、GGSN/
LAC(203)が Create PDPcontext request(101-2)のメッ
セージを受け取った際、RADIUSサーバに対してL2TPトン
ネルユーザ認証を要求(103)する。これはリモートユー
ザがL2TPトンネルを利用できるユーザかどうかの確認を
行うもので、リモートユーザが、アクセスを要求してい
るプライベート網のユーザであるかを認証する。すなわ
ち、CreatePDP context requestに含まれるユーザ識別
番号と通信先の名前の組がRADIUSサーバのもつデータベ
ース中に存在すれば認証されることになる。RADIUSサー
バのデータベース中の情報は通常リモートアクセスユー
ザと通信事業者との契約情報として管理され、ユーザ識
別番号とプライベートネットワークの名前のほかに、LN
SのIPアドレス、L2TPトンネル設定情報などが含まれ
る。このL2TPトンネル設定情報についてはL2TPトンネル
設定手順で詳細に記述する。RADIUSサーバがリモートユ
ーザを認証すると、GGSN/LACにトンネルユーザ認証応答
(103-2)を行うが、このメッセージ中にLNSのIPアドレス
やL2TPトンネル設定情報が含まれる。次にRSVPによりLN
Sまでの経路の通信帯域を確保する。まずGGSN/LAC(203)
がLNS(204)に向け、pathメッセージ(104)を発行する。
このメッセージは通常、GGSN/LAC(203)からLNS(204)ま
での経路にあるすべてのルータに対して、RSVPを利用し
ているセッション(例えば1つのアプリケーションに対応
する)の情報(使用通信帯域など)を伝達するものだが、
次の資源予約メッセージ(104-2)に対する準備を促す役
割も持つ。RSVPメッセージ(図10にフォーマットを示す)
はIPパケットのペイロードに直接収められ、インターネ
ット上を転送される。LNS(204)ではpathメッセージ(10
4)を受信した後、GGSN/LAC(203)に向けて資源予約メッ
セージ(104-2)を発行し、途中のルータはこのメッセー
ジ中に含まれる要求通信帯域を確保する。資源予約メッ
セージ(104-2)を受信し、これから設定するL2TPトンネ
ルのための通信帯域が確保された後、GGSN/LAC(203)はL
NS(204)に対してVPN(L2TPトンネル)(206)の設定要求を
送る。図13はL2TPメッセージのフォーマットを示すが、
このうちAVPの部分に必要な情報を記述する。そのフォ
ーマットを図14に示し、記述する情報の例としてL2TPメ
ッセージの種類を図15に示す。L2TPメッセージはさらに
UDP(図12にフォーマットを示す)およびIP(図11にフォー
マットを示す)ヘッダを付加されてインターネット上を
転送される。通常、L2TPトンネル設定要求(105)を送る
ためにL2TPトンネルの設定情報が必要となる。これは、
L2TPトンネルをほかのユーザと共有するか、セッション
ごとに異なるトンネルを利用するか、トンネルの生存時
間、等の情報である。LNS(204)はL2TPトンネル設定要求
(105)を受信すると、トンネルを設定し、L2TPトンネル
設定応答(105-2)をGGSN/LAC(203)に送る。GGSN/LAC(20
3)はこのメッセージを受信したことでトンネルが設定さ
れたことを検知し、L2TPトンネル確立確認メッセージ(1
05-3)をLNS(204)に送る。LNS(204)はL2TPトンネル確立
確認(105-3)を受信することで、GGSN/LAC(203)がL2TPト
ンネルが設定されたと確認したことを検知する。L2TPト
ンネルが設定されると、L2TPトンネル設定と同様の手順
でL2TPセッションをGGSN/LCA(203)とLNS(204)間で設定
する。L2TPセッションは例えば1つのアプリケーション
に対応し、複数のセッションを1つのL2TPトンネルに多
重することもできる。LACとLNSではL2TPトンネルに対し
てはトンネルID、セッションに対してはセッションIDを
割り当て、各トンネルとセッションを管理する。また、
ユーザデータ(IPパケット)がどのセッションやトンネル
に属しているかは、IPパケットのヘッダにあるDIP(Dest
ination IP Address)、SIP(Source IP Address)、UDPや
TCPのPort番号等の組み合わせで判断する。他方、IPパ
ケットがRSVPで確保した通信帯域を利用できるセッショ
ンに属しているかの判断もIPパケットのDIP、UDPやTCP
のDestination Portの組み合わせで行う。また、L2TPの
トンネルIDで判断することもできる。すなわち、RSVPで
確保した通信帯域をL2TPトンネルのトンネルIDと関連付
けることもできる。よって、GGSN/LAC(203)におけるリ
モート端末からプライベート網に向かうユーザデータ(I
PパケットをPPPフレームに収めたもの)の処理は例えば
次のようになる。 PPPフレーム中のIPヘッダのDIP等からL2TPトンネルI
D、セッションIDを対応付ける。 PPPフレームにL2TPヘッダ(L2TPトンネルID、セッショ
ンIDを含む)、UDPヘッダ、IPヘッダ(DIPがLNSのIPアド
レス、SIPがGGSN/LACのIPアドレス)を付加する。 L2TPトンネルIDと関連付けられた、RSVPにより確保さ
れた通信帯域を使用してで生成したIPパケットをLNS
に向けて転送する。ここで、GGSN/LAC(203)とLNS(204)
間にすでにL2TPトンネルがあり、L2TPトンネル設定情報
からトンネル共有が許可されていれば、あらたにトンネ
ルを設定する必要はなく、セッションごとに帯域を確保
する場合には図3に示す通信手順をとることになる。図1
との差異は、L2TPトンネル設定の手順(105,105-2,105-
3)がないことのみである。もしトンネルごとに帯域を確
保する場合には図3において帯域確保の手順(104,104-2)
を省くことができる。また、すでにL2TPトンネルがあっ
てもトンネル共有が許可されていなければ、図1の手順
に従い、あらたにL2TPトンネルを設定することになる。
このトンネル共有については、同一ユーザの複数のセッ
ション(例えば複数のアプリケーション)を1つのトンネ
ルに多重することや、複数のユーザのセッションを1つ
のトンネルに多重することが考えられる。また、ある特
定のアプリケーションのセッションだけでトンネルを占
有し(複数ユーザの同一アプリケーションのセッション
を束ねる)、ほかのアプリケーションのセッションとは
共有しないことや、あるユーザの1つのセッションが1つ
のトンネルを占有することも考えられる。 L2TPトンネ
ルはインターネット上を転送することができないPPPフ
レームを転送するために用いているが、RSVPと組み合わ
せてL2TPトンネル用の通信帯域を予め確保することによ
り、L2TPセッション単位やトンネル単位で通信帯域確保
が可能となる。RSVPでは1つのセッション単位でのみ通
信帯域を確保できるが、L2TPトンネル単位で通信帯域を
確保することにより、結果として複数のセッションを束
ねた通信帯域確保が可能となる。さらにこれまでに述べ
た通信路設定手順により、GGSN/LAC(203)におけるSGSN
(202)との通信路設定とLNS(204)とのL2TPトンネル(206)
設定は並行して行うことができる。図2のネットワーク
図における従来の方法による通信手順を図4に示すが、
リモートユーザから見ると、LACとLNS間のL2TPトンネル
設定手順の起動を早めた分、処理の遅延時間が低減す
る。第2の実施例としては、RADIUSサーバ(207)で管理す
るL2TPトンネルユーザ情報、L2TPトンネル設定情報、LN
S(204)のIPアドレスなどをGPRS網内にすでに存在するHL
R(Home Location Register)(208)で管理する例がある。
これは第1の実施例においてRADIUSサーバをHLRに統合し
た場合に相当する。 第3の実施例として、図2において
GGSNとLACを分離した場合のネットワーク図を図5に示
す。この場合、図6に示すようにGGSN(501)からLAC(502)
に Activate PDP context request(101) が送られてき
たことを通知する(601)(このメッセージにユーザの識別
番号や通信先の名前を含め、LAC(502)がRADIUSサーバへ
問い合わせるときに用いる)ことにより、図1と同様GGSN
(501)とSGSN(202)間の通信路設定とLAC(502)とLNS(204)
間のL2TPトンネル設定を並行して行うことができる。第4
の実施例としては第2と第3の実施例の組み合わせがあ
る。
あるGPRS発展方法(3GPP TS 23.060および29.060、http:
//www.3gpp.org/TSG/Dec99_status_list.htm 参照)によ
るIMT-2000パケット通信網(以下GPRS網と呼ぶ) を公衆
通信網の例、L2TPをVPN設定プロトコルの例とし、図面
をもとに説明する。 図１に本発明による、リモートユ
ーザがプライベートネットワークにアクセスする際の通
信手順を示す。図２はリモートアクセスを行う場合の全
体のネットワーク構成を示す。L2TPではアクセスコンセ
ントレータのことをLAC(L2TP Access Concentrator)、
アクセスサーバのことをLNS(L2TP Network Server)と呼
ぶ。図２ではGGSNがLACを兼ねている。 リモートユー
ザがGPRS網を利用する場合、通信の前に必ずGPRS網に対
して携帯端末から Activate PDP context request (10
1)が発行される。これはGPRS網内にSGSN(202)からGGSN/
LAC(203)までの通信路の設定を要求するものであり、リ
モートユーザのユーザ識別番号、リモートユーザの通信
先の名前(例えばISPの名前)などが含まれている。図7に
GPRSメッセージのフォーマットを示すが、このうちTID
にユーザ識別番号が含まれ、そのフォーマットを図8に
示す。また、図7のInformation Elementの部分に通信先
の名前が含まれ、Information Elementの例を図9に示
す。GPRS発展方法では、ユーザデータも図7と同じフォ
ーマットで転送され、図7のInformation Elements の部
分にユーザデータが収められる。そして、GPRSメッセー
ジとユーザデータはさらにUDP(図12にフォーマットを示
す)、およびIP(図11にフォーマットを示す)のヘッダを
付加され、GPRS網内を転送される。リモートユーザがGP
RS網を利用してプライベートネットワークにアクセスを
する際、Activate PDP context request (101) がSGSN
(202)に向かって携帯端末から発行される。SGSN(202)で
このメッセージを処理した後、同様の内容のメッセージ
(Create PDP context request)(101-2)がGGSN/LAC(203)
に送られる。GGSN/LAC(203)ではこのメッセージを契機
としてSGSN(202)との間でユーザデータ用の通信路を設
定し、設定が完了するとSGSN(202)へＣｒｅａｔｅ Ｐ
ＤＰ ｃｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅ（１０２）を
送る。これを受けたＳＧＳＮ（２０２）は、通信可能で
あることを通知するため携帯端末へActivate PDP conte
xt accept(102-2)のメッセージを送り、この後携帯端末
はLNS(204)に対してPPP接続を開始する。 一方、GGSN/
LAC(203)が Create PDPcontext request(101-2)のメッ
セージを受け取った際、RADIUSサーバに対してL2TPトン
ネルユーザ認証を要求(103)する。これはリモートユー
ザがL2TPトンネルを利用できるユーザかどうかの確認を
行うもので、リモートユーザが、アクセスを要求してい
るプライベート網のユーザであるかを認証する。すなわ
ち、CreatePDP context requestに含まれるユーザ識別
番号と通信先の名前の組がRADIUSサーバのもつデータベ
ース中に存在すれば認証されることになる。RADIUSサー
バのデータベース中の情報は通常リモートアクセスユー
ザと通信事業者との契約情報として管理され、ユーザ識
別番号とプライベートネットワークの名前のほかに、LN
SのIPアドレス、L2TPトンネル設定情報などが含まれ
る。このL2TPトンネル設定情報についてはL2TPトンネル
設定手順で詳細に記述する。RADIUSサーバがリモートユ
ーザを認証すると、GGSN/LACにトンネルユーザ認証応答
(103-2)を行うが、このメッセージ中にLNSのIPアドレス
やL2TPトンネル設定情報が含まれる。次にRSVPによりLN
Sまでの経路の通信帯域を確保する。まずGGSN/LAC(203)
がLNS(204)に向け、pathメッセージ(104)を発行する。
このメッセージは通常、GGSN/LAC(203)からLNS(204)ま
での経路にあるすべてのルータに対して、RSVPを利用し
ているセッション(例えば1つのアプリケーションに対応
する)の情報(使用通信帯域など)を伝達するものだが、
次の資源予約メッセージ(104-2)に対する準備を促す役
割も持つ。RSVPメッセージ(図10にフォーマットを示す)
はIPパケットのペイロードに直接収められ、インターネ
ット上を転送される。LNS(204)ではpathメッセージ(10
4)を受信した後、GGSN/LAC(203)に向けて資源予約メッ
セージ(104-2)を発行し、途中のルータはこのメッセー
ジ中に含まれる要求通信帯域を確保する。資源予約メッ
セージ(104-2)を受信し、これから設定するL2TPトンネ
ルのための通信帯域が確保された後、GGSN/LAC(203)はL
NS(204)に対してVPN(L2TPトンネル)(206)の設定要求を
送る。図13はL2TPメッセージのフォーマットを示すが、
このうちAVPの部分に必要な情報を記述する。そのフォ
ーマットを図14に示し、記述する情報の例としてL2TPメ
ッセージの種類を図15に示す。L2TPメッセージはさらに
UDP(図12にフォーマットを示す)およびIP(図11にフォー
マットを示す)ヘッダを付加されてインターネット上を
転送される。通常、L2TPトンネル設定要求(105)を送る
ためにL2TPトンネルの設定情報が必要となる。これは、
L2TPトンネルをほかのユーザと共有するか、セッション
ごとに異なるトンネルを利用するか、トンネルの生存時
間、等の情報である。LNS(204)はL2TPトンネル設定要求
(105)を受信すると、トンネルを設定し、L2TPトンネル
設定応答(105-2)をGGSN/LAC(203)に送る。GGSN/LAC(20
3)はこのメッセージを受信したことでトンネルが設定さ
れたことを検知し、L2TPトンネル確立確認メッセージ(1
05-3)をLNS(204)に送る。LNS(204)はL2TPトンネル確立
確認(105-3)を受信することで、GGSN/LAC(203)がL2TPト
ンネルが設定されたと確認したことを検知する。L2TPト
ンネルが設定されると、L2TPトンネル設定と同様の手順
でL2TPセッションをGGSN/LCA(203)とLNS(204)間で設定
する。L2TPセッションは例えば1つのアプリケーション
に対応し、複数のセッションを1つのL2TPトンネルに多
重することもできる。LACとLNSではL2TPトンネルに対し
てはトンネルID、セッションに対してはセッションIDを
割り当て、各トンネルとセッションを管理する。また、
ユーザデータ(IPパケット)がどのセッションやトンネル
に属しているかは、IPパケットのヘッダにあるDIP(Dest
ination IP Address)、SIP(Source IP Address)、UDPや
TCPのPort番号等の組み合わせで判断する。他方、IPパ
ケットがRSVPで確保した通信帯域を利用できるセッショ
ンに属しているかの判断もIPパケットのDIP、UDPやTCP
のDestination Portの組み合わせで行う。また、L2TPの
トンネルIDで判断することもできる。すなわち、RSVPで
確保した通信帯域をL2TPトンネルのトンネルIDと関連付
けることもできる。よって、GGSN/LAC(203)におけるリ
モート端末からプライベート網に向かうユーザデータ(I
PパケットをPPPフレームに収めたもの)の処理は例えば
次のようになる。 PPPフレーム中のIPヘッダのDIP等からL2TPトンネルI
D、セッションIDを対応付ける。 PPPフレームにL2TPヘッダ(L2TPトンネルID、セッショ
ンIDを含む)、UDPヘッダ、IPヘッダ(DIPがLNSのIPアド
レス、SIPがGGSN/LACのIPアドレス)を付加する。 L2TPトンネルIDと関連付けられた、RSVPにより確保さ
れた通信帯域を使用してで生成したIPパケットをLNS
に向けて転送する。ここで、GGSN/LAC(203)とLNS(204)
間にすでにL2TPトンネルがあり、L2TPトンネル設定情報
からトンネル共有が許可されていれば、あらたにトンネ
ルを設定する必要はなく、セッションごとに帯域を確保
する場合には図3に示す通信手順をとることになる。図1
との差異は、L2TPトンネル設定の手順(105,105-2,105-
3)がないことのみである。もしトンネルごとに帯域を確
保する場合には図3において帯域確保の手順(104,104-2)
を省くことができる。また、すでにL2TPトンネルがあっ
てもトンネル共有が許可されていなければ、図1の手順
に従い、あらたにL2TPトンネルを設定することになる。
このトンネル共有については、同一ユーザの複数のセッ
ション(例えば複数のアプリケーション)を1つのトンネ
ルに多重することや、複数のユーザのセッションを1つ
のトンネルに多重することが考えられる。また、ある特
定のアプリケーションのセッションだけでトンネルを占
有し(複数ユーザの同一アプリケーションのセッション
を束ねる)、ほかのアプリケーションのセッションとは
共有しないことや、あるユーザの1つのセッションが1つ
のトンネルを占有することも考えられる。 L2TPトンネ
ルはインターネット上を転送することができないPPPフ
レームを転送するために用いているが、RSVPと組み合わ
せてL2TPトンネル用の通信帯域を予め確保することによ
り、L2TPセッション単位やトンネル単位で通信帯域確保
が可能となる。RSVPでは1つのセッション単位でのみ通
信帯域を確保できるが、L2TPトンネル単位で通信帯域を
確保することにより、結果として複数のセッションを束
ねた通信帯域確保が可能となる。さらにこれまでに述べ
た通信路設定手順により、GGSN/LAC(203)におけるSGSN
(202)との通信路設定とLNS(204)とのL2TPトンネル(206)
設定は並行して行うことができる。図2のネットワーク
図における従来の方法による通信手順を図4に示すが、
リモートユーザから見ると、LACとLNS間のL2TPトンネル
設定手順の起動を早めた分、処理の遅延時間が低減す
る。第2の実施例としては、RADIUSサーバ(207)で管理す
るL2TPトンネルユーザ情報、L2TPトンネル設定情報、LN
S(204)のIPアドレスなどをGPRS網内にすでに存在するHL
R(Home Location Register)(208)で管理する例がある。
これは第1の実施例においてRADIUSサーバをHLRに統合し
た場合に相当する。 第3の実施例として、図2において
GGSNとLACを分離した場合のネットワーク図を図5に示
す。この場合、図6に示すようにGGSN(501)からLAC(502)
に Activate PDP context request(101) が送られてき
たことを通知する(601)(このメッセージにユーザの識別
番号や通信先の名前を含め、LAC(502)がRADIUSサーバへ
問い合わせるときに用いる)ことにより、図1と同様GGSN
(501)とSGSN(202)間の通信路設定とLAC(502)とLNS(204)
間のL2TPトンネル設定を並行して行うことができる。第4
の実施例としては第2と第3の実施例の組み合わせがあ
る。
【発明の効果】遠隔地からプライベートネットワークへ
のリモートアクセスにおける、インターネット上のVPN
の帯域を確保し、またVPNの設定処理遅延時間を低減
し、ユーザにより通信品質がよく通信開始までの待ち時
間が短いサービスを提供できる。
のリモートアクセスにおける、インターネット上のVPN
の帯域を確保し、またVPNの設定処理遅延時間を低減
し、ユーザにより通信品質がよく通信開始までの待ち時
間が短いサービスを提供できる。
【図１】本発明による通信路設定手順(L2TPトンネルが
ない、またはあっても共有しない場合)
ない、またはあっても共有しない場合)
【図２】遠隔地からプライベートネットワークへリモー
トアクセスする場合のネットワーク図。
トアクセスする場合のネットワーク図。
【図３】本発明による通信路設定手順(L2TPトンネルが
すでにあり、それを共有する場合)。
すでにあり、それを共有する場合)。
【図４】従来の通信路設定手順。
【図５】図２においてGGSNとLACを分離したネットワー
ク図。
ク図。
【図６】図５における本発明の通信路設定手順。
【図７】GPRSメッセージのパケットフォーマット。
【図８】図７にあるTIDのフォーマット。
【図９】Activate PDP context requestの情報要素。
【図１０】RSVPメッセージパケットのフォーマット。
【図１１】IPのパケットフォーマット。
【図１２】UDPのパケットフォーマット。
【図１３】L2TPメッセージのパケットフォーマット。
【図１４】図１３にあるAVPのフォーマット。
【図１５】図１４にあるAttribute typeとAttribute va
lueの一例。
lueの一例。
１０１ GPRS網内の通信路設定要求メッセージ １０１−２ GPRS網内の通信路設定要求メッセージ １０２ GPRS網内の通信路設定完了メッセージ １０２−２ GPRS網内の通信路設定完了メッセージ １０３ L2TPトンネルの利用ユーザ確認要求メッセージ １０３−２ L2TPトンネルの利用ユーザ確認応答メッセ
ージ １０４ RSVP path メッセージ １０４−２ RSVP reserve メッセージ １０５ L2TPトンネル設定要求メッセージ １０５−２ L2TPトンネル設定応答メッセージ １０５−３ L2TPトンネル確立確認メッセージ １０６ L2TPセッション設定要求メッセージ １０６−２ L2TPセッション設定応答メッセージ １０６−３ L2TPセッション確立確認メッセージ １０７ PPP認証要求メッセージ １０８ PPPコネクション確立メッセージ２０１ RNC(無
線基地局制御装置) ２０２ SGSN(Serving GPRS Support Node) ２０３ GGSN/LAC(Gateway GPRS Support Node and L2TP
Access Server) ２０４ LNS(L2TP Network Server) ２０５ リモートユーザの通信相手であるサーバ ２０６ L2TPトンネル ２０７ RADIUSサーバ ２０８ HLR(Home Location Register) ２０９ 携帯端末５０１ GGSN ５０２ LAC ６０１ VPN設定要求メッセージ。
ージ １０４ RSVP path メッセージ １０４−２ RSVP reserve メッセージ １０５ L2TPトンネル設定要求メッセージ １０５−２ L2TPトンネル設定応答メッセージ １０５−３ L2TPトンネル確立確認メッセージ １０６ L2TPセッション設定要求メッセージ １０６−２ L2TPセッション設定応答メッセージ １０６−３ L2TPセッション確立確認メッセージ １０７ PPP認証要求メッセージ １０８ PPPコネクション確立メッセージ２０１ RNC(無
線基地局制御装置) ２０２ SGSN(Serving GPRS Support Node) ２０３ GGSN/LAC(Gateway GPRS Support Node and L2TP
Access Server) ２０４ LNS(L2TP Network Server) ２０５ リモートユーザの通信相手であるサーバ ２０６ L2TPトンネル ２０７ RADIUSサーバ ２０８ HLR(Home Location Register) ２０９ 携帯端末５０１ GGSN ５０２ LAC ６０１ VPN設定要求メッセージ。
フロントページの続き Ｆターム(参考） 5K030 GA01 GA20 HA08 HB28 HC01 HC09 HC14 HD03 HD06 HD09 JA02 JT09 LB05 LC05 LC09 LD20 5K034 AA02 DD01 EE03 EE09 FF06 FF11 FF13 KK21 LL01 9A001 CC07 CC08 JJ25 KK56
Claims (5)
- 【請求項１】公衆通信網などの私設網1とインターネッ
トなどの公共網2とを接続する装置において、該装置か
ら上記公共網2を経由して、上記私設網1と異なる私設網
3内に存在する装置4まで通信路を設定する場合に、上記
私設網1内に通信路を設定することを契機として公共網2
上に通信路を設定する通信路設定方法。 - 【請求項２】公衆通信網などの私設網1とインターネッ
トなどの公共網2とを接続する装置において、該装置か
ら上記公共網2を経由して、上記私設網1と異なる私設網
3内に存在する装置4まで通信路を設定する場合に、公共
網2上で通信帯域を確保した後、公共網2上に通信路を設
定する通信路設定方法。 - 【請求項３】請求項2記載の公共網2上に、複数のデータ
フローを多重することができる通信路を複数設定し、か
つ該通信路ごとに通信帯域を確保することにより、1つ
のデータフロー単位以外に、複数のデータフローを束ね
た単位でも通信帯域制御が可能な請求項2記載の通信路
設定方法。 - 【請求項４】請求項1記載の公共網2上に通信路を設定す
る際、公共網2上で通信帯域を確保してから公共網2上に
通信路を設定する請求項1記載の通信路設定方法。 - 【請求項５】請求項１記載の私設網1と公共網2とを接続
する装置がもつ、私設網1内の通信路を設定、終端する
機能1と、公共網2内の通信路を設定、終端する機能2を
分離して物理的に異なる装置とした場合において、私設
網1内に通信路を設定することを契機として、前者の機
能1を持つ装置から後者の機能2を持つ装置へ向けて、公
共網2内に通信路を設定することを指示する請求項1、請
求項2、請求項3、および請求項4記載の通信路設定方
法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000097813A JP2001285354A (ja) | 2000-03-30 | 2000-03-30 | 通信路設定方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000097813A JP2001285354A (ja) | 2000-03-30 | 2000-03-30 | 通信路設定方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2001285354A true JP2001285354A (ja) | 2001-10-12 |
Family
ID=18612385
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000097813A Pending JP2001285354A (ja) | 2000-03-30 | 2000-03-30 | 通信路設定方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2001285354A (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2007141840A1 (ja) * | 2006-06-05 | 2007-12-13 | Hitachi Communication Technologies, Ltd. | 中継ネットワークシステム及び端末アダプタ装置 |
| JP2008067054A (ja) * | 2006-09-07 | 2008-03-21 | Fujitsu Ltd | 伝送装置 |
| CN101056310B (zh) * | 2006-04-10 | 2013-06-12 | 株式会社日立制作所 | 通信装置 |
| JP2013533705A (ja) * | 2010-06-29 | 2013-08-22 | アルカテル−ルーセント | ネットワーク要素内でセッションのバンドルを割り当てるための方法および装置 |
| JP2015502694A (ja) * | 2011-11-14 | 2015-01-22 | エフオーエヌ・ワイヤレス・リミテッドＦｏｎ Ｗｉｒｅｒｌｅｓｓ Ｌｉｍｉｔｅｄ | セキュアトンネリング・プラットフォームシステムならびに方法 |
-
2000
- 2000-03-30 JP JP2000097813A patent/JP2001285354A/ja active Pending
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101056310B (zh) * | 2006-04-10 | 2013-06-12 | 株式会社日立制作所 | 通信装置 |
| WO2007141840A1 (ja) * | 2006-06-05 | 2007-12-13 | Hitachi Communication Technologies, Ltd. | 中継ネットワークシステム及び端末アダプタ装置 |
| JPWO2007141840A1 (ja) * | 2006-06-05 | 2009-10-15 | 株式会社日立コミュニケーションテクノロジー | 中継ネットワークシステム及び端末アダプタ装置 |
| JP4598859B2 (ja) * | 2006-06-05 | 2010-12-15 | 株式会社日立製作所 | 中継ネットワークシステム及び端末アダプタ装置 |
| US8159989B2 (en) | 2006-06-05 | 2012-04-17 | Hitachi, Ltd. | Relay network system and terminal adaptor apparatus |
| JP2008067054A (ja) * | 2006-09-07 | 2008-03-21 | Fujitsu Ltd | 伝送装置 |
| JP2013533705A (ja) * | 2010-06-29 | 2013-08-22 | アルカテル−ルーセント | ネットワーク要素内でセッションのバンドルを割り当てるための方法および装置 |
| JP2015502694A (ja) * | 2011-11-14 | 2015-01-22 | エフオーエヌ・ワイヤレス・リミテッドＦｏｎ Ｗｉｒｅｒｌｅｓｓ Ｌｉｍｉｔｅｄ | セキュアトンネリング・プラットフォームシステムならびに方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3836272B2 (ja) | 移動ポイント・ツー・ポイント・プロトコル | |
| JP5491650B2 (ja) | 移動ユーザ機器 | |
| EP2628287B1 (en) | Multipath transmission control protocol proxy | |
| EP2738982B1 (en) | Session association method, device and system | |
| US7561586B2 (en) | Method and apparatus for providing network VPN services on demand | |
| JP3470882B2 (ja) | 多重ホップ・ポイント・ツー・ポイント・プロトコル | |
| KR100680076B1 (ko) | 통신시스템에서의 망요소 통합 방법 | |
| EP2426885B9 (en) | Method, device and system for mobile virtual private network communication | |
| US6496491B2 (en) | Mobile point-to-point protocol | |
| KR100894074B1 (ko) | 패킷 데이터 네트워크에서 액세스 베어러 관련 정보를제공하는 방법 및 시스템 | |
| WO2008006317A1 (fr) | Système et procédé pour accès multiservice | |
| US20070127461A1 (en) | Router and communication system | |
| JP2002531005A (ja) | 既存のリザーベーションプロトコルおよびフレームフォーマットを使用してネットワーク内およびネットワークを横切って行われる保証されたサービスの品質またはクラスを提供する方法および装置 | |
| WO2004105319A1 (fr) | Procede d'acces a large bande et grande capacite et systeme associe | |
| WO2016150140A1 (zh) | 一种基于sdn的网关中控制报文的处理方法及系统 | |
| WO2008138274A1 (fr) | Procédé et dispositif correspondant et système servant à accéder à un service distant | |
| WO2014071685A1 (zh) | 基于移动网络的租户网络业务实现方法、系统及网元 | |
| WO2014000520A1 (zh) | 一种策略控制的方法、装置和系统 | |
| US8665721B2 (en) | Systems, methods, and computer readable media for maintaining packet data protocol (PDP) context while performing data offload | |
| KR101769344B1 (ko) | 다중 경로 환경에서의 서비스 플로우 별 mp-gw 포트 매핑 방법 및 시스템 | |
| KR100990796B1 (ko) | 무선 근거리 통신망에서의 서비스 품질 제어 | |
| EP1411676A1 (en) | Method, network access server, client and computer software product for dynamic definition of layer 2 tunneling connections | |
| WO2011088702A1 (zh) | 在全业务融合网络中控制资源的方法和系统 | |
| JP2001285354A (ja) | 通信路設定方法 | |
| KR20050095420A (ko) | 무선통신시스템에서 시그널링을 제외한 사용자 트래픽에대한 과금 방법 |