JP3737668B2 - パケットサーバにおける呼設立方法 - Google Patents
パケットサーバにおける呼設立方法 Download PDFInfo
- Publication number
- JP3737668B2 JP3737668B2 JP2000101549A JP2000101549A JP3737668B2 JP 3737668 B2 JP3737668 B2 JP 3737668B2 JP 2000101549 A JP2000101549 A JP 2000101549A JP 2000101549 A JP2000101549 A JP 2000101549A JP 3737668 B2 JP3737668 B2 JP 3737668B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- quality
- class
- call
- packet
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
- H04L12/2858—Access network architectures
- H04L12/2859—Point-to-point connection between the data network and the subscribers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、概して通信に関し、詳しくはパケット通信システムに関する。
【０００２】
【従来の技術】
過去には、インターネットを用いる全てのデータトラフィックが平等に取り扱われ、「最善の努力」を用いて搬送された。しかし、時を経て、インターネットを介しての実時間用途（例えば、オーディオ／映像会議ツール、ゲーム用途、等）をサポートする必要から、サービスに差異をつけて提供する、或る種のサービス差異化提供形式、が必要となった。このため、インターネットのユーザに「サービスの品質」を提供するための新しいプロトコルが、この技術の当業者によって定義されつつある。「サービスの品質」は「サービスの種類」とも称される。
【０００３】
例えば、資料（"An Architecture for Differentiated Services," RFC2475, December 1998 by S. Blake, et al.） では、或るサービスの品質（簡単に、サービス品質）（ＱｏＳ）を表す符号点（コードポイント）を搬送するためにインターネットプロトコルのヘッダ内の「サービスの種類」（簡単に、サービス種類）（ＴｏＳ）のバイト内に６ビットを定義する。
【０００４】
同様に、資料（"An Expedited Forwarding PHB", draft-ietf-diffserv-phb-ef-01.txt, Nov 1998, by V. Jacobson, et al.）に、まさにＡＴＭにおける定ビットレートサービスのような、異なる構成されたレートサービスにユーザが加入できるようにする１つの特定の符号点についての記述がある。
【０００５】
資料（"Assured Forwarding PHB Group", draft-ietf-diffserv-af-03.txt, Dec 1998, by J. Heinanen, et al.）に、ＡＴＭにおける実時間／非実時間可変ビットレートサービスに類似の、別のサービス種類についての記述がある。
【０００６】
そして、資料（"PPP in a real-time oriented HDLC-like framing," by C. Bormann, IETF draft August 1998）に、低ビットレートリンクを介した統合サービスを提供するための保留／再開指向の解が提案されている（ＰＰＰはポイント・ツー・ポイント・プロトコルを意味する）。
【０００７】
この提案は、ＰＰＰマルチリンク分割（fragmentation） プロトコル（例えば、資料（K. Slower et al., "The PPP Multilink Protocol (MP)," RFC1990, August 1996） を参照）及びそのマルチクラス拡張部分（例えば、資料（C. Bormann, "The Multi-class Extension to Multilink PPP," IETF draft August 1998）を参照）から構成される。
【０００８】
通信手段としてのインターネットの用法の１つは、仮想私設網（ＶＰＮ）と称する通信ネットワークを提供するように、異なる現場を一体に結合するための強化型データバックボーンとしての用法である。ＶＰＮの適用例は、企業の従業員が例えば家庭でインターネットを介して企業のデータネットワークに遠隔アクセスできるような、企業環境における適用である。ＶＰＮにおいては、公共通信ネットワーク施設を用いるにも拘わらず、閉ユーザ群に参加する遠隔ユーザに対するセキュリティ（機密保護）及び認証が与えられる。
【０００９】
実際、ＶＰＮの使用によって、企業及び従業員に、ＷＡＮ（広域ネットワーク）に似た通信手段が得られる（企業ネットワークでも又、例えば、ユーザが企業ネットワークにダイヤルするなどして直接に遠隔アクセスが可能であるが、ＶＰＮを利用する方が経済的に有利である）。
【００１０】
ＶＰＮを得るためには、ＰＰＴＰ（ポイント・ツー・ポイント・トンネリングプロトコル）及びＬ２Ｆ（レイヤー２・フォワーディング）プロトコルのような「トンネリングプロトコル」が用いられる。概していえば、トンネリングプロトコルにおいては、１個のパケットを別のパケット内に置くことにより公衆ネットワークを介して私用データストリームの生成が可能になる。ＶＰＮの構成においては、インターネットプロトコル（ＩＰ）パケットが別のＩＰパケット内に置かれる（ＩＰ・イン・ＩＰ）。
【００１１】
業界標準を設定する企てとして、ＩＥＴＦ（インターネット・エンジニアリング・タスクフォース（インターネットの研究開発及び標準化組織））が、Ｌ２ＴＰ（レイヤー２・トンネリングプロトコル）を開発中で、これは、ＰＰＴＰ及びＬ２Ｆの混成融合プロトコルである（例えば資料（K. Hamzeh, T, Kolar, M. Littlewood, G. Singh Pall, J. Taarud, A. J. Valencia, W. Verthein, 「Layer Two Tunneling Protocol "L2TP", Internet draft, Marh, 1998」）を参照）。
【００１２】
遠隔ユーザの場合、ＶＰＮへの一般的なアクセス形式は、ＶＰＮサービスを提供するインターネット接続サービス業者（簡単に、インターネット接続業者）への従来型電話サービスによる接続を介して行うアクセスである。
【００１３】
例えば、ユーザがアナログモデムをパソコン又は同等の装置に組み込み、特定のインターネット接続業者（以下、家庭用インターネット接続業者、と称する）の顧客アカウント（口座）を取得する（尚、ユーザのパソコンが上記トンネルプロトコルのうちの１つをサポートするように適切に構成されていると仮定する）。ユーザがＶＰＮにアクセスするには、単に、家庭用インターネット接続業者に対してデータ呼を発起して（例えば、その業者に連関する電話番号をダイヤルして）、ＶＰＮに「ログイン」（登録）するだけである。
【００１４】
【発明が解決しようとする課題】
上記したように、Ｌ２ＴＰプロトコルにおいては、いくつもの呼を搬送するために２つのＶＰＮサービス提供業者の間にトンネルが設立される。残念ながら、上記のＬ２ＴＰプロトコルは、「サービス品質」問題（「差異化サービス」問題としても知られる）を扱わない。このため、呼に対する保証最少帯域幅のようなサービス品質保証なしにＬ２ＴＰプロトコルを採用することを躊躇するユーザもある。
【００１５】
その結果、トンネルが設立された後に１個の符号点値のみを用いて呼ごとのサービス品質を相互処理により決定（相互処理決定）（negotiate） することができるようにＬ２ＴＰプロトコルを修正することがこの技術の当業者によって提案された（例えば、資料（"Layer Two Tunneling Protocol 'L2TP' IP Differential Services Extension," July 1998, draft-ietf-pppext-l2tp-ds-02.txt@http://www.ietf.org） を参照）。
【００１６】
残念ながら、１個の符号点値のみを用いて呼ごとのサービス品質を与える手法は、Ｌ２ＴＰに基づくシステムにおける問題に対する完全な解ではない。詳しくは、上記のＰＰＰマルチリンク・プロトコル（ＭＰ）及びそのマルチクラス拡張部分（マルチクラス対応のために拡張された部分）も又Ｌ２ＴＰ環境においてサポートされるべきであることを本発明者は認識している。
【００１７】
【課題を解決するための手段】
したがって、そして本発明に基づき、Ｌ２ＴＰにおける制御信号送信が、１つの呼の中で、「多数のサービスクラス」（マルチ・サービスクラス、とも称する）をサポートするように修正される。
【００１８】
本発明の一実施例において新しい「属性値の対」（属性値対）（ＡＶＰ）が、呼の設定用にＬ２ＴＰ制御メッセージにおいて使用するために定義される（Ｌ２ＴＰにおいて定義されるように属性値対を用いて更に制御信号が定められる）。
【００１９】
詳しくは、Ｌ２ＴＰ着信呼要求（ＩＣＲＱ）メッセージ又はＬ２ＴＰ発信呼要求（ＯＣＲＱ）メッセージが、サービス品質（ＱｏＳ）の属性値対（ＡＶＰ）を有し、このサービス品質の属性値対が、その呼の中でのサービス品質のクラスの個数を定義するためのフィールドを有する。個々のＰＰＰマルチクラス拡張部分ごとに１つのサービス品質が定義される。
【００２０】
本発明の別の実施例において、新しいサービス品質要求拡張部分及び新しいサービス品質回答拡張部分が、移動インターネットプロトコル（ＩＰ）ネットワークで用いるために定義される。
【００２１】
【発明の実施の形態】
本発明の概念を説明する前に、図１を参照して従来の技術のマルチリンク・プロトコル（ＭＰ）の例について述べる。図１は、カプセル化されたマルチリンク・プロトコル（ＭＰ）を有するＬ２ＴＰパケットの部分を示す。尚、この図１及びこれに続く同様な図面は、パケットで搬送される関連情報を集約して示すものであり、パケット内のフィールドの全てを示すものではない。
【００２２】
Ｌ２ＴＰ（レイヤー２・トンネリングプロトコル）パケット１０は、定義された「サービス品質」フィールドを有する。「サービス品質」フィールドは、インターネットプロトコル（ＩＰ）ではより一般的には「サービス種類」（ＴｏＳ）フィールドと称されるので、図中、ＴｏＳ１、として表す。
【００２３】
このフィールドに続いて「Ｌ２ＴＰシーケンス番号」フィールドがあり、例示では番号は「１」に設定され「＃１」と表す。「Ｌ２ＴＰシーケンス番号」フィールドに続いて「ＰＰＰヘッダ」フィールド及び「ＭＰクラス」フィールドがあり、例示ではこのパケットの「ＭＰクラス」は「１」である。
【００２４】
この技術分野で知られるように、Ｌ２ＴＰ制御メッセージ、及び異なるＬ２ＴＰデータセッションは、異なるシーケンス番号又はシーケンス番号群を用いる。詳しくは、Ｌ２ＴＰは現在のところ、特定のクラス又はリンクの、送信されたＰＰＰパケットの各々に対して、異なるシーケンス番号、又はシーケンス番号群を必要とする。
【００２５】
このことを、同じセッション１の一部であるＬ２ＴＰパケット１１及び１２として示す。Ｌ２ＴＰパケット１１は次のクラス１パケットを搬送するパケットで、Ｌ２ＴＰパケット１０と同じ設定されたシーケンス番号を用い、このフィールドの値としては単にシーケンス（又はシーケンス番号群）中の次の番号、すなわち、「２」をとる。
【００２６】
しかし、異なるクラスのＰＰＰデータ、すなわち、異なるＬ２ＴＰデータセッション、の場合になると、異なるシーケンス番号付けスペース、又はシーケンス番号群、が用いられる。このことを、セッション２のＬ２ＴＰパケット１２で表す。このＬ２ＴＰパケット１２は、ＭＰクラスが「２」で、全く異なるシーケンス番号系、例えば、「３１」を用いるＰＰＰデータを搬送する。
【００２７】
次に、図２に本発明の原理に基づく例示の通信システム１００を示す。本発明の概念の他は、構成要素は周知であり、詳細には説明しない。例えば、パソコン（ＰＣ）１０５は、インターネット接続を設立するために公衆交換電話ネットワーク（ＰＳＴＮ）１１０を介してインターネット接続業者Ａに対しダイヤルアップ方式のアクセスを行うためのデータ通信装置（図示しない）を有する。
【００２８】
同様に、通信システム１００の構成要素間の実線は、それぞれの終点間の周知の通信施設を表す。例えば、パソコン１０５と公衆交換電話ネットワーク１１０との間の接続実線は市内ループ接続回線を表し、インターネット接続業者Ａとインターネット１３０との間の接続は同期光ネットワーク（ＳＯＮＥＴ）を介して非同期転送モード（ＡＴＭ）によってサポートされる、等である。
【００２９】
更に、本説明の読み手が上記Ｌ２ＴＰプロトコル、急速回送サービス（Expedited Forwarding Service）、保証回送サービス（Assured Forwarding Service）、並びに、マルチクラス拡張部分を含むＰＰＰマルチリンク・プロトコル（ＭＰ）（以下、ＭＰプロトコル、とも称する）に詳しいものと仮定する。
【００３０】
ここで、次の用語を次の定義で用いることとする。
ｍＬ２ＴＰ＝「Ｌ２ＴＰ」（資料 （K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, A. J. Valencia, W. Verthein:Layer Two Tunneling Protocol "L2TP", Internet draft, March, 1998） に定義される）に本説明に記述の修正（modification）を加えた「修正版Ｌ２ＴＰ」。
【００３１】
ＬＡＣ＝ｍＬ２ＴＰアクセス制御装置、すなわち、ｍＬ２ＴＰをサポートするネットワークアクセスサーバ（ＮＡＳ）。
ＬＮＳ＝ｍＬ２ＴＰをサポートするネットワーク・サーバ（ＮＳ）。
【００３２】
尚、これらの定義は、本発明の概念の例示説明を簡単にするために用いられる。このため、そして又この技術分野の当業者に明らかなように、本発明の概念は、これらの定義により制限されるものではなく、どのトンネリングプロトコル及び連関する処理装置にも適用可能である。
【００３３】
図２から判るように、通信システム１００は、インターネット接続業者Ａネットワークとして表されるようなインターネット接続業者Ａからなる。後者すなわち、インターネット接続業者Ａネットワークは、ｍＬ２ＴＰアクセス制御装置（ＬＡＣ）１５５（取り扱い担当のＬＡＣとも称する）からなり、このｍＬ２ＴＰアクセス制御装置１５５（又は簡単に、アクセス制御サーバ）は、この技術分野で知られる（インターネット接続業者Ａの）「アクセスポイント」（point of presence） ルータ（図示しない）、ローカル・ネットワーク１６０、及びルータ１６５を有する。
【００３４】
ここに、遠隔に位置する企業従業員がその企業の例示ネットワークに、ｍＬ２ＴＰをサポートするネットワーク・サーバ（ＮＳ又はＬＮＳ）１３５（又は簡単に、ネットワーク・サーバ）を介してアクセスするためのＶＰＮ（仮想私設網）サービスをインターネット接続業者Ａが提供し、これにより、他の種々の機能のほかに、ルーティング（検討された経路による転送）及びファイヤウオールの能力が得られるものと仮定する。（企業のネットワークは例えば、ネットワーク・サーバ１３５の背後に適切に保護されたローカル・エリア・ネットワークの集合であると仮定する。）
【００３５】
ＶＰＮサービス（例えばパソコン１０５に連関するユーザのためのＶＰＮサービス）は、インターネット接続業者Ａを介しての点線１及び点線２によって表される。この場合、接続構成（conductivity）は、２点間接続通信用（ポイント・ツー・ポイント）のマルチリンク・プロトコル（ＭＰ）のセッションであり、その終点は、一端が、遠隔ユーザのネットワーク処理用装置（パソコン１０５で表されるような）であり、他端が、この接続構成がネットワーク・サーバ１３５において終端するその終端装置である。
【００３６】
（尚、要すれば計数課金処理を、取り扱い担当のアクセス制御サーバ、及びネットワーク・サーバで行うことができる。すなわち、各構成要素が、パケット、８ビットバイト、並びに接続開始及び停止時刻を計数する。）
【００３７】
説明の都合上、ＶＰＮサービスをサポートするためのトンネルが、既知のＬ２ＴＰ手法又は米国特許出願（of Chuah:entitled "Providing Quality of Service in Layer Two Tunneling Protocol Networks," serial No.09/259900, filed on February 26, 1999）に記述される方法を用いて、取り扱い担当のアクセス制御サーバ（ＬＡＣ）とネットワーク・サーバ（ＬＮＳ）との間に既に設定され又は相互処理決定されているものと仮定する。
【００３８】
更に、ユーザがＶＰＮサービスへのアクセスを望み、既に認証されているものと仮定する。（例えば、安全な管路に対して、ＩＥＴＦが、保全のための２つのプロトコルすなわち、ＰＡＰ（パスワード認証プロトコル）及びＣＨＡＰ（パスワード暗号化認証プロトコル）を定義している（これらについては、例えばＩＥＴＦのＲＦＣ（規格書）１３３４「ＰＰＰ認証プロトコル」を参照されたい）。
【００３９】
明らかに、もしアクセス制御サーバ（ＬＡＣ）１５５がユーザを認証できない場合、接続は受け入れられない。本発明の構成においては、ユーザと取り扱い担当のアクセス制御サーバ（ＬＡＣ）との間の接続がマルチリンク・プロトコル（ＭＰ）をサポートし、同様に認証されるものと仮定する。
【００４０】
個別のセッション、又は呼、については、アクセス制御サーバ（ＬＡＣ）１５５（又はネットワーク・サーバ（ＬＮＳ）１３５）が、ユーザからの着信呼を設定するための要求を受信する。本発明の概念に基づき、個別のセッションの各々が多数のサービス品質を要求できる。
【００４１】
アクセス制御サーバ（ＬＡＣ）１５５（又はネットワーク・サーバ（ＬＮＳ）１３５）が、ユーザの、事前定義されたプロフィル（概観）に基づいて、又は受信されたＭＰメッセージに定義されたように、関連トラフィックパラメータ及びサービス品質（符号点）（下に述べる）を定める。
【００４２】
（前者、すなわち、ユーザプロフィルに基づく場合には、アクセス制御サーバ（ＬＡＣ）１５５（又はネットワーク・サーバ（ＬＮＳ）１３５）が、この技術分野で知られるように、それぞれの認証・許可・課金サーバと通信して、例えば、ユーザぼログイン名に基づいてユーザのプロフィルを得る。しかし、本説明の以下残りの部分においては、本発明の概念を、アクセス制御サーバ（ＬＡＣ）１５５への着信呼でＭＰメッセージを用いた場合について述べる。）
【００４３】
上記の仮想ダイヤルアップサービスをサポートするために、そして本発明の概念に基づき、Ｌ２ＴＰの一形式であるｍＬ２ＴＰプロトコルが用いられる。Ｌ２ＴＰの場合のように、ｍＬ２ＴＰプロトコルには、与えられたトンネルで動作する２つの並行成分がある。すなわち、アクセス制御サーバ（ＬＡＣ）及びネットワーク・サーバ（ＬＮＳ）の各対の間の制御メッセージ、並びに同じＬＡＣ・ＬＮＳ対の間のペイロードパケットの２つである。
【００４４】
後者は、そのＬＡＣ・ＬＮＳ対の間のユーザのデータセッションのためのｍＬ２ＴＰカプセル化されたＭＰパケットを搬送するために用いられる。Ｌ２ＴＰの場合のように、「次受信」（Ｎｒ）フィールド及び「次送信」（Ｎｓ）フィールドが制御メッセージ内に常に存在し、ペイロードパケット内にはオプションとして存在する。制御メッセージ及びペイロードメッセージは異なるシーケンス番号群を用いる。
【００４５】
上記のＬＡＣ・ＬＮＳ対のシナリオ（動作モデル）については、「次受信」及び「次送信」のフィールドの維持及び使用に関する限り、Ｌ２ＴＰプロトコル案（draft） の定義に変更はない。
【００４６】
上記のように、呼が設立される前に、ｍＬ２ＴＰ制御メッセージが、取り扱い担当のアクセス制御サーバ（ＬＡＣ）とネットワーク・サーバ（ＬＮＳ）との間で交換される。したがって、２つのＬ２ＴＰピア（対等サーバ）が多数のサービスクラス（マルチ・サービスクラス）を有する呼を設立、又は相互処理決定できるようにするために、新しい属性値の対（下に述べる）が定義されて、Ｌ２ＴＰ制御メッセージ（したがって、これがｍＬ２ＴＰ制御メッセージとなる）に用いられる。
【００４７】
であるから、このような呼を設立するためのサービス品質の相互処理決定が加わる他には、Ｌ２ＴＰトンネル設定手順は変わらないことを認識されたい。
【００４８】
次に図３について説明する。図３は、単一の呼内で多数のサービス品質を相互処理決定するための本発明に基づく方法を例示する高次レベルの流れ図である。（アクセス制御サーバ（ＬＡＣ）１５５及びその他のサーバがそれぞれ、従来の（したがってここには述べない）プログラム作成手法を用いて、下に述べる方法を実行できるように、これらサーバが適切にプログラムされているものと仮定する。）
【００４９】
図３のステップ３０５において、取り扱い担当のアクセス制御サーバ（ＬＡＣ）が、マルチリンク・ヘッダを有する１個のＰＰＰ・ＬＣＰフレームをユーザから受信する。マルチリンク・ヘッダを識別の後、取り扱い担当のアクセス制御サーバ（ＬＡＣ）（例えば、１５５）が、修正されたマルチリンク・ヘッダ内の「推測クラス番号」フィールドの値及び連関するサービス種類の値を点検して、着信呼要求（ＩＣＲＱ）メッセージ（下に述べる）への添付用に、適切な「サービス品質要求の属性値対」を生成する。
【００５０】
（この技術分野で知られるように、「推測クラス番号」フィールド（"# Susp. Clses" field） は現在のところ、マルチリンク・ヘッダにおいて利用可能である。したがって、そして本発明の概念に基づき、マルチリンク・ヘッダが、サービス品質情報（図１４において３個のＴｏＳ（サービス種類）として例示）を追加して搬送するために、図１４に示すように修正される。）
【００５１】
ステップ３１５において、取り扱い担当のアクセス制御サーバ（ＬＡＣ）が、サービス品質（ＱｏＳ）要求の属性値対を有する着信呼要求メッセージを送信する。本発明の概念に基づき、サービス品質要求の属性値対が、この呼に連関するサービス品質クラスの個数及びサービス品質の種類を指定する（下で更に述べる）。
【００５２】
ステップ３２０において、取り扱い担当のアクセス制御サーバ（ＬＡＣ）が、受信された着信呼回答メッセージの中でサービス品質回答の属性値対を有する回答を受信する。それからステップ３２５において、取り扱い担当のアクセス制御サーバ（ＬＡＣ）が、着信呼接続（ＩＣＣＮ）メッセージで応答する。２つのＬ２ＴＰピア（対等サーバ）（ここではアクセス制御サーバ（ＬＡＣ）及びネットワーク・サーバ（ＬＮＳ）で表される）の間で上記の処理を行うための、これに対応する制御メッセージの処理を図４に例示する。
【００５３】
図５に、サービス品質（ＱｏＳ）要求の属性値対（ＡＶＰ）のフォーマットを例示する。この属性値対の最初の４ビットは、予め定義されたビットパターンの「１１００」（Ｌ２ＴＰの定義）を有する。ビット位置４及び５は、「何でもかまわない」（don't care）値である。そして、ビット位置６及び７は、２個の新しいパラメータ「Ｄ」及び「Ｌ」で、「Ｄ」は遅れクラスビットを表し、「Ｌ」は損失クラスを表す。
【００５４】
「Ｄ」ビットは、もし基本をなすトンネルが遅れクラスのみをサポートする場合に用いられる。言い換えれば、もし「Ｄ」ビットが着信呼要求メッセージに設定される場合、差異化された符号点のうちの遅れビットのみが考慮される（下に述べる）。同様に、「Ｌ」ビットは、もし基本をなすトンネルが損失クラスのみをサポートする場合に用いられる。すなわち、もし「Ｌ」ビットが設定される場合、符号点のうちの損失ビットのみが考慮される
【００５５】
「Ｄ」及び「Ｌ」のビットに続いて、８ビット長のフィールドがありその値はこの属性値対のサイズを表す。８ビット長のフィールドの後には、２バイトの、「業者（ベンダ）に固有のＩＤ（識別名）」のフィールドがある。（ここでは一例として、ルーセント社（Lucent）のＩＤを搬送する場合を示し、又この呼が多数のサービス品質を有することを表す。）（代わりに、これを、このメッセージが多数のサービス品質を有する呼メッセージであることを明らかにする予め定義されたｍＬ２ＴＰ属性値対の符号に置き換えてもよい。）
【００５６】
「業者に固有のＩＤ」フィールドの次には、２バイトの「Ｌ２ＴＰ属性種類」のフィールドがあり、ここでは「１」に設定される。「属性種類」のフィールドの次には、要求されているサービス品質の個数を指定する「クラス個数」のフィールドがある。この例では、「クラス個数」のフィールドは、図３のステップ３０５において定められる異なるクラスの個数に等しい。
【００５７】
「クラス個数」のフィールドの次には、「クラス個数」のフィールドの値によって指定される個数の「差異化サービス符号点値」（differentiated services code point values） （１バイト長のサービス品質識別名）が来る（「サービス品質」フィールド）。（図５のサービス品質要求の属性値対に対して、「クラス個数」のフィールドの例示値は「３」である。）
【００５８】
各サービス品質は、連関するＰＰＰクラス拡張部分に対する差異化されたサービスの、特定のクラスを定める。加えて、各サービス品質バイトの最初の２ビットは、格上げ可能ビット「Ｐ」及び格下げ可能ビット「Ｍ」を表す。言い換えれば、「Ｐ」及び「Ｍ」のビットの用法は、クラスごとに定められる。
【００５９】
「Ｐ」及び「Ｍ」のビットが「０」の値を表すときは、そのクラスに対するそのセッションのデータチャネル内のＩＰパケットに、選択された差異化符号点値のみが用いられることを、Ｌ２ＴＰピア（サーバ）が示している。
【００６０】
「Ｐ」ビットが設定されると、それは、もし要求されたサービス品質がクラスとして利用可能でない場合に、より高いサービスレベルを有する差異化サービス符号点値を、ｍＬ２ＴＰピアが推薦できることを意味する。「Ｍ」ビットが設定されると、それは、もし要求されたサービス品質がクラスとして利用可能でない場合に、より低いサービスレベルを有する差異化サービス符号点値を、ｍＬ２ＴＰピアが推薦できることを意味する。
【００６１】
「マルチ・サービス品質」のフィールドに続いて、要すれば、「パッディング」（詰め物）フィールドが、属性値対メッセージを埋めるために用いられる。
【００６２】
差異化サービス符号点値の値は、上記の保証回送サービス（Assured Forwarding Service）における符号点の定義に類似の仕方で定義される。詳しくは、これら２つのｍＬ２ＴＰピアが１つの呼にクラスＡijを設定する。ここに、「ｉ」は遅れクラスの種類を表し、「ｊ」は損失クラスの種類を表す。ここでは例示の目的だけで、ｉ＝１，２，３，４；ｊ＝１，２，３とする。
【００６３】
したがって、１つの呼に対してクラスが４個あり、各クラスが、異なる１つの遅れ優先クラスをサポートする。すなわち、各クラスが、次の表に示すような差異化されたサービス符号点（差異化サービス符号点）Ａix、ｉ＝１，２，３，４、を有する。
【００６４】
【００６５】
「Ｘ」は,「何でもかまわない」（don't care）状態を表す。すなわち、値は２進値の「０」又は「１」である。差異化サービス符号点Ａijを有する個々のセッションが、差異化サービス符号点Ａixをサポートするトンネルに写像される。
【００６６】
同様に、これら２つのｍＬ２ＴＰピアが、異なる損失優先クラスをサポートする呼、すなわち、次の表に示すような差異化サービス符号点Ａxj、ｊ＝１，２，３，を有する呼、を設定する。
【００６７】
【００６８】
したがって、保証回送サービスについては、「００１ＸＸＸ」又は「ＸＸＸ０１０」のような差異化符号点値が種々のクラスに対して受け入れ可能である。（適切なトラフィック処理のためには、２つのｍＬ２ＴＰピアが、保証回送サービスをサポートする各トンネルについてのレートを指定することが必要である。
【００６９】
このような仕様を用いることにより、ｍＬ２ＴＰピアがいつデータセッションを許可／拒絶すべきかを定めることができる。ｍＬ２ＴＰピアは又、利用可能な資源（帯域幅及びバッファ）を、設立された異なるトンネルの間でどのように共用させるかを定めることができる。
【００７０】
同様に、前に述べた急速回送サービスについては、サービス品質要求の属性値対は、急速回送サービス符号点（すなわち、差異化符号点値）及び要求された平均レートを有する。
【００７１】
着信呼要求又は着信呼回答におけるサービス品質要求属性値対の存在は、一方のｍＬ２ＴＰピアが、或る特定のＰＰＰ呼のデータパケット全てに対していくつもの差異化サービス符号点を用いたいと望んでいることを示す。
【００７２】
もし資源の不足からｍＬ２ＴＰピアがどの符号点も受け入れられない場合、そのｍＬ２ＴＰピアは、もし上記の格上げ／格下げ可能ビットが設定されているならば、代わりの符号点を推薦できる。もし設定されていないならば、ｍＬ２ＴＰピアはその呼要求を拒絶する。したがって、サービス品質許諾の属性値対（下に述べる）に見いだされる値が、ｍＬ２ＴＰピアが受け入れようとしている値を示す。
【００７３】
加えて、サービス品質要求の属性値対は、或る特定のクラスに対して更なるトラフィックパラメータの指定を許す別のパラメータを有する。図５においては、「サービス品質２」のみが追加パラメータを指定する状態を示す。
【００７４】
トラフィックパラメータには、要求レートのフィールド、許容バーストサイズのフィールド、オプションの過剰バーストサイズのフィールド、ピークレートのフィールド、及びオプションの損失／遅れ要件のフィールドが含まれる。これらのトラフィックパラメータを用いることによって、呼内のクラスに量的な遅れ／損失保証が付与され、呼が許可される確率が改善される（帯域幅多重が増加する）。
【００７５】
詳しくは、要求レートのフィールドの値がそのクラスに対する要求された平均ｂｐｓ（秒当たりのビット数）を表す。許容バーストサイズのフィールド値の要求は、送信機がピークレートでどれだけ長い間パケットを送信できるかを表す。過剰バーストサイズのフィールド値の要求は、送信機が許容バーストサイズをどれだけ長い間超過できるかを表す。
【００７６】
ピークレートのフィールド値の要求は、要求されるピークレートを例えばｂｐｓ値で表す。損失／遅れ要件のフィールド値の要求は、パケット損失（上記の「Ｌ」ビットフィールドが設定される）又は遅れクラス（上記の「Ｄ」ビットフィールドが設定される）を表す。パケット損失については、この値は許容パケット損失のパーセント値、例えば１％、５％等、を表す。遅れについては、この値は許容遅れを例えば、ミリ秒で表す。
【００７７】
図６は、着信呼メッセージでトンネル終端装置（例えば、図２のネットワーク・サーバ１３５）によって送信されるサービス品質（ＱｏＳ）許諾の属性値対（ＡＶＰ）についての例示フォーマットである。このサービス品質許諾の属性値対のフィールドは、上記のサービス品質要求の属性値対のフィールドと相補的なものである。
【００７８】
この場合、「Ｄ」又は「Ｌ」のビットはなくて、応答側サーバは、表示フィールド内に許諾されたレートを示す「許諾レート」及び「保証損失／遅れ値」（オプション）を表示する。許諾されたレートは要求されたレートよりも小さい。（ここで、もし多数のサービス品質を逆方向に相互処理決定する必要がある場合いは、ネットワーク・サーバが又、着信呼回答メッセージ（図示しない）に、本発明の概念に基づきサービス品質要求の属性値対を添付するようになることに留意したい。）
【００７９】
上記の相互処理決定を行うために、対応する制御メッセージ処理を２個のｍＬ２ＴＰピア（ここではアクセス制御サーバ及びネットワーク・サーバによって表される）間で行い、そのネットワーク・サーバが呼要求を発起する場合の、制御メッセージ処理を図７に例示する。この場合、対応する発信呼要求（ＯＣＲＱ）、発信呼回答（ＯＣＲＰ）、及び発信呼接続（ＯＣＣＮ）のメッセージは、上記のように適切に修正される。
【００８０】
上記から判るように、マルチリンク・ＰＰＰへのマルチクラス拡張部分の添付をサポートするための、Ｌ２ＴＰプロトコルへの柔軟なサービス品質拡張部分の添付について説明した。その結果、ペイロードが、異なるサービスクラスを表すにも拘わらず、ペイロードに用いるシーケンス番号群は１つだけでよい。これを図８に示す。セッションが１つだけ設立される。Ｌ２ＴＰパケット２０は、「ＴｏＳ１」で表される定義された「サービス品質」フィールドを有する。
【００８１】
このフィールドに続いて「Ｌ２ＴＰシーケンス番号」フィールドがあり、例示では番号は「１」に設定される。Ｌ２ＴＰパケット２１は次の「クラス１」パケットを搬送するもので、Ｌ２ＴＰパケット２０と同じシーケンス番号群を用い、そのフィールド値は、単にそのシーケンス中の次の番号すなわち「２」である。
【００８２】
しかし、異なるクラスのＰＰＰデータの場合になっても、本発明の概念に基づき、同じシーケンス番号付けスペース、又はシーケンス番号群、が用いられる。このことを、Ｌ２ＴＰパケット２２で表す。このＬ２ＴＰパケット２２は、ＭＰクラスが「２」で、同じシーケンス内の次の番号すなわち「３」を用いるＰＰＰデータを搬送する。
【００８３】
次に図９に、代表的なネットワーク・アクセスサーバ（Ｌ２ＴＰピア）、すなわち、パケットサーバ、６０５の高次レベルのブロック図を本発明に基づいて示す。パケットサーバ６０５は、内蔵プログラム制御に基づくプロセッサ構造で、プロセッサ６５０、例えば、サービス品質に関連する上記の新しい属性値対（ＡＶＰ）メッセージを通信するためのプログラム命令及びデータを格納記憶するためのメモリ６６０、及びパス６６６で表されるような１個以上の通信施設に結合するための通信インタフェース６６５を有する。
【００８４】
尚、各アクセス制御サーバ（ＬＡＣ）は、着信呼要求（ＩＣＲＱ）のサービス品質（ＱｏＳ）要求属性値対（ＡＶＰ）に指定されるように多くの呼ごとの、又はセッションごとの待ち行列を維持することを注記したい（他のセッションのバッファは図示しない）。本発明に基づき、データチャネルについて呼ごとに１個のシーケンス番号群だけが用いられる。
【００８５】
各待ち行列に対するパケットは、厳格な優先権計画アルゴリズム又は重み付けした公正待ち行列型の計画アルゴリズムを用いて処理される。異なる待ち行列を図９のメモリ６６０内のＱｏＳ１待ち行列及びＱｏＳ２待ち行列で示す。
【００８６】
したがって、差異化サービスをインターネット接続業者Ａが呼の中で提供できる。例えば、図２のインターネット接続業者Ａが次の３種類のデータサービスを提供すると仮定する。すなわち、ゴールド（ＩＰ音声通話用）、シルバー（緊急データ用）、及びブロンズ（通常のデータ用）のデータサービスである。各ユーザは、これら３種類のデータサービスのどれにも加入できる。
【００８７】
加えて、各ユーザは、そのユーザがインターネットアクセス、企業ネットワークアクセス、又は混合サービスのどれを望むかを指定できる。更にユーザは、それらサービスの、事前格納記憶されているプロフィル（図示しない）を介して、特定のデータサービスについて使用したい或る帯域幅を、例えばゴールドを８ｋｂｐｓで、シルバーを５６ｋｂｐｓでというように指定できる。
【００８８】
尚、本発明の概念が他のネットワークにおける保証／差異化サービスの提供にも適用可能であることを注記したい。一例として、本発明に基づく広域無線データネットワークを図１０に示す。本発明の概念を除いては、このネットワークの構成要素は周知であり詳細説明はしない。例えば、移動終端又は移動ノードが、移動ノード９０５で表される。移動ノード９０５は基地局９１０に接続される。
【００８９】
説明上、基地局９１０が、ポリシーサーバ（図示しない）を有する中間域外エージェント９１５によって取り扱われる「域外区域」の一部であると仮定する。中間域外エージェント９１５はゲートウェイ域外エージェント／動的域内エージェント９２０に接続される。
【００９０】
同様に、移動ノード９０５のユーザ（図示しない）は「域内（ホーム）区域」に連関する。「域内区域」はゲートウェイ域内エージェント９２５及び域内エージェント９３０によって構成される。周知のユーザ認証方法が、例えば、認証・許可・課金（ＡＡＡ）サーバ（図示しない）を介して用いられる。
【００９１】
この構成において、基地局９１０、中間域外エージェント９１５、ゲートウェイ域外エージェント／動的域内エージェント９２０、ゲートウェイ域内エージェント９２５、及び域内エージェント９３０は全て、異なる形態のパケットサーバである。例えば、ゲートウェイ域外エージェント／動的域内エージェント９２０とゲートウェイ域内エージェント９２５との間の通信は、ＩＰ系ネットワーク９４０を介して行われる。
【００９２】
本発明の概念による修正を除いては、図１０の通信システムは、移動ＩＰプロトコルを用いる。移動ＩＰプロトコルは、移動ノードが移動中接続を維持できるように設計されている。（例えば、資料（C. Perkins et al., "IP mobility support," RFC2002, Oct 1996） を参照されたい。）このため、ここでは移動ＩＰプロトコルの、本発明の概念によって修正される部分のみを説明する。
【００９３】
移動ＩＰプロトコルにおいて移動ノード９０５はリンク層メッセージ処理手段（図示しない）を介して基地局９１０に登録する。詳しくは、移動ノード９０５が登録要求メッセージを基地局９１０に送信する。基地局９１０がリンク層信号手段を用いて要求を中間域外エージェント９１５に通信する。それから中間域外エージェント９１５が、関連するフィールドを修正後に移動ＩＰ登録要求メッセージをゲートウェイ域外エージェント９２０に中継する。
【００９４】
それに続いて、移動ノード（例えば、移動ノード９０５）のために、「複合トンネル」が域内エージェント（例えば、域内エージェント９３０）と域外エージェント（例えば、域外エージェント９１５）との間に設定される。（例えば、資料（S. Blake et al., "An architecture for differentiated services," RFC2475 Dec 1998）を参照されたい。）（尚、もしネットワーク層信号手段が用いられる場合、複合トンネルは基地局９１０から域内エージェント９３０までである。どちらの場合も、本発明が等しく適用される。）
【００９５】
「サービス品質」（ＱｏＳ）を移動ＩＰに導入するように提案がなされているが、現在、移動ノードからのトラフィックは、移動ＩＰトンネルにおける最善努力トラフィックとして、「ＩＰ・イン・ＩＰ」方式（ＩＰパケットが別のＩＰパケット内に置かれる）で行われている。（このような「サービス品質」提案の一例が資料（"IP encapsulation in IP," by C. Perkins, RFC2003, Oct 1996）にみられ、そこでは、「サービス種類」（ＴｏＳ）フィールドのバイト内にある６ビット符号点に基づいてサービス品質を与える枠組を提案している。
【００９６】
又、この資料の１つ前に引用した資料（Blake et al.）には、外部ＩＰヘッダの）「サービス種類」（ＴｏＳ）バイトを、内部ＩＰヘッダにある値と同じ値でマーク付けする手法が記述されている。
【００９７】
しかし、本発明の概念に基づき、新しい「サービス品質」（ＱｏＳ）要求に関する拡張部分がこの移動ＩＰ登録要求メッセージに含められる。この新しい「サービス品質」要求拡張部分により、ユーザが同じセッション内で多数のサービス品質を要求することができる。加えて、この手法で、複合トンネル内の異なるセグメントが、関連するサービス品質によって異なる動作をすることが可能になる。（説明上、各セグメントの終端部分のみが、「サービス品質」に責任を有しその保証に同意するものと仮定する。）
【００９８】
本発明の概念に基づき、移動ノード９０５が最初に基地局９１０に登録するとき、移動ノード９０５が登録要求メッセージ内に「サービス品質」（ＱｏＳ）要求に関する拡張部分（サービス品質拡張部分）を添付する（以下、修正された登録要求メッセージ（修正登録要求メッセージ）と称する）。このサービス品質拡張部分により、ユーザがその接続に対して必要と考えるだけの多数のサービス品質のクラスを要求できる。
【００９９】
各レベルにおいて、もし対応する移動通信エージェント（例えば、基地局、中間域外エージェント、等）が、要求されたサービス品質を許諾するに十分な資源を得られない場合に、そのエージェントが、このサービス品質拡張部分を修正する。例えば、ゲートウェイ域外エージェント９２０が、そのユーザを受け入れるかどうかを、利用可能な資源及びユーザの要求の基づいて決定する。
【０１００】
もしユーザの要求が受諾される、すなわち、ユーザが受け入れられる場合、ゲートウェイ域外エージェント９２０が、修正登録要求メッセージをゲートウェイ域内エージェント９２５に送る。
【０１０１】
（もし図１０のネットワークにおいてゲートウェイ域外エージェント９２０とゲートウェイ域内エージェント９２５との間のセグメントについて現在輻輳がある場合には、ゲートウェイ域外エージェント９２０は又、サービスの格上げ又は格下げ能力に基づいて新しいしかし関連する符号点を選択することもできる。）
【０１０２】
ゲートウェイ域外エージェント９２０がゲートウェイ域内エージェント９２５から肯定的回答を受信すると、ゲートウェイ域外エージェント９２０はこの情報を、そのローカル・ポリシーサーバ（図示しない）又はその連関する認証・許可・課金サーバ（図示しない）に格納する。
【０１０３】
それからゲートウェイ域外エージェント９２０が、許諾されたサービス品質に関する拡張部分をメッセージに添付してより低次のレベルの移動通信エージェントに送る。より低次のレベルの移動通信エージェントは、「サービス品質」情報をそのローカル・ポリシーサーバ（図示しない）に格納する。（尚、このような格納は、情報を、格納された登録テーブルへのエントリとして格納するのと同じ程度に簡単であることを注記したい。）
【０１０４】
このようにして、サービス品質要求拡張部分により、移動ノード９０５が望む差異化サービスの符号点（コードポイント）（又は差異化サービスクラスの符号点）の指定が可能となり、１つの呼に対するオプションのトラフィックパラメータの指定も可能となる。移動ＩＰの登録要求メッセージ及び登録許諾メッセージに用いるための、「サービス品質要求拡張部分」及び「サービス品質回答拡張部分」のフォーマットを図１１及び図１２に例示する。
【０１０５】
尚、トンネル及び呼ＩＤ（識別名）が、「サービス品質要求拡張部分」及び／又は「サービス品質回答拡張部分」にある。これらの識別名は後に、包括的なルーティング及びカプセル化トンネルにおける搬送側データに用いられる。特定のサービス品質クラスのための搬送側データは、ＩＰ「サービス種類」（ＴｏＳ）バイト中の適切な「サービス種類」符号点を用いる。
【０１０６】
図５及び図６に示す「属性値対」（ＡＶＰ）メッセージと同様の仕方で、「サービス品質要求拡張部分」及び「サービス品質回答拡張部分」が、「クラスの個数」フィールドを有する。要求されたクラスが各々、対応する「サービス種類」（ＴｏＳ）バイトに示される（例えば、「ＴｏＳ１」、「ＴｏＳ２」等）。各「サービス種類」バイトは、「Ｐ」及び「Ｍ」のビットを有する。
【０１０７】
各クラスについてのオプションのトラフィックパラメータも図中に示す。（したがって、「サービス品質クラスの個数」フィールドには又、メッセージに含まれるオプションのトラフィックパラメータの個数も含まれる。）（しかし、これらのオプションのトラフィックパラメータは代わりに、ユーザプロフィルの一部として認証・許可・課金サーバ（図示しない）に格納することもできる。）
【０１０８】
オプションのトラフィックパラメータがあることで、顧客に販売可能なサービスという意味でのより多くの柔軟性が得られ、又よりよい帯域幅多重利得が得られるより高性能の受け入れ制御アルゴリズムが可能となる。「サービス品質回答拡張部分」において、サービス品質要求が許諾されるか又は拒絶されるかを示すために、符号フィールドが用いられる。
【０１０９】
移動ＩＰ登録及び回答メッセージへの別の修正を図１３に示す。移動ＩＰ登録要求メッセージ６０が、追加の「サービスオプション」フィールドからなり、それぞれ、連関するサービス品質を有する。「サービスオプション」フィールドは、サービス種類、例えば、インターネットアクセス、ＶＰＮ（仮想私設網）、混合サービス（例えば、インターネット及びＶＰＮの両方）の要求を搭載する。同様に、移動ＩＰ登録回答メッセージ６１に示されるような、対応する移動ＩＰ登録回答メッセージもある。
【０１１０】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらは本明細書に明示はしないがいずれも本発明の技術的範囲に包含される。
【０１１１】
例えば、本発明の概念を、取り扱い担当のアクセス制御サーバ（ＬＡＣ）からネットワーク・サーバ（ＬＮＳ）へトンネルが設立される構成に基づいて説明したが、本発明の概念は、例えば、米国特許出願（Chuah et al., entitled "A Multi-Hop Point-to-Point Protocol," serial No.09/074745, filed on May 5, 1998） に記述されるような、マルチ・ホップ・トンネル方式の構成にも適用可能である。
【０１１２】
尚、特許請求の範囲に記載した参照番号は発明の容易な理解のためで、その技術的範囲を制限するよう解釈されるべきではない。
【０１１３】
【発明の効果】
以上述べたごとく本発明によれば、Ｌ２ＴＰプロトコルに基づくデータ通信において、従来の技術と異なり、「サービス品質要求及び回答を扱う拡張部分」を制御メッセージに含めるようにＬ２ＴＰプロトコルを修正し、提供するサービス品質のクラスを相互処理により決定して呼を設定するようにしたので、ユーザの要求に対応したマルチ・品質レベルのサービスの提供が可能となる。
【図面の簡単な説明】
【図１】従来の技術において知られているような、カプセル化されたマルチリンク・プロトコル（ＭＰ）を有するＬ２ＴＰパケットの部分を示す説明図である。
【図２】本発明の原理に基づく通信システムを示すブロック図である。
【図３】図２の通信システムで用いられる例示方法の流れ図である。
【図４】本発明の原理に基づき呼のサービス品質を決めるための制御メッセージの処理を例示する説明図である。を
【図５】本発明の原理に基づいて用いるための新しいＬ２ＴＰ属性値対メッセージ（サービス品質要求属性値対）を示す説明図である。
【図６】本発明の原理に基づいて用いるための新しいＬ２ＴＰ属性値対メッセージ（サービス品質許諾属性値対）を示す説明図である。
【図７】本発明の原理に基づき呼のサービス品質を決めるための別の制御メッセージの処理を例示する説明図である。を
【図８】本発明の原理に基づく、カプセル化されたマルチリンク・プロトコル（ＭＰ）を有するＬ２ＴＰパケットの部分を示す説明図である。
【図９】パケットサーバの高次レベルの例示ブロック図である。
【図１０】本発明の原理に基づく別の通信システムを示すブロック図である。
【図１１】本発明の原理に基づいて用いるための別のサービス品質型のメッセージ（サービス品質要求拡張部分）を示す説明図である。
【図１２】本発明の原理に基づいて用いるための別のサービス品質型のメッセージ（サービス品質許諾拡張部分）を示す説明図である。
【図１３】本発明の原理に基づく登録及び回答メッセージを搬送する移動インターネットプロトコル（ＩＰ）パケットの部分を示す説明図である。
【図１４】修正されたマルチリンク・ヘッダの一部分を示す説明図である。
【符号の説明】
１０、１１、１２ Ｌ２ＴＰ（レイヤー２・トンネリングプロトコル）パケット
２０、２１、２２ Ｌ２ＴＰパケット
６０ 移動体ＩＰ登録要求メッセージ
６１ 移動体ＩＰ登録回答メッセージ
１００ 通信システム
１０５ パソコン（ＰＣ）
１１０ 公衆交換電話ネットワーク（ＰＳＴＮ）
１３０ インターネット
１３５ ｍＬ２ＴＰをサポートするネットワーク・サーバ（ＮＳ又はＬＮＳ）
１５５ ｍＬ２ＴＰアクセス制御装置（サーバ）（ＬＡＣ）
１６０ ローカル・ネットワーク
１６５ ルータ
６０５ パケットサーバ
６５０ プロセッサ
６６０ メモリ
６６５ 通信インタフェース
６６６ パス
９０５ 移動ノード
９１０ 基地局
９１５ 中間域外エージェント
９２０ ゲートウェイ域外エージェント／動的域内エージェント
９２５ ゲートウェイ域内エージェント
９３０ 域内エージェント
９４０ ＩＰ系ネットワーク
【発明の属する技術分野】
本発明は、概して通信に関し、詳しくはパケット通信システムに関する。
【０００２】
【従来の技術】
過去には、インターネットを用いる全てのデータトラフィックが平等に取り扱われ、「最善の努力」を用いて搬送された。しかし、時を経て、インターネットを介しての実時間用途（例えば、オーディオ／映像会議ツール、ゲーム用途、等）をサポートする必要から、サービスに差異をつけて提供する、或る種のサービス差異化提供形式、が必要となった。このため、インターネットのユーザに「サービスの品質」を提供するための新しいプロトコルが、この技術の当業者によって定義されつつある。「サービスの品質」は「サービスの種類」とも称される。
【０００３】
例えば、資料（"An Architecture for Differentiated Services," RFC2475, December 1998 by S. Blake, et al.） では、或るサービスの品質（簡単に、サービス品質）（ＱｏＳ）を表す符号点（コードポイント）を搬送するためにインターネットプロトコルのヘッダ内の「サービスの種類」（簡単に、サービス種類）（ＴｏＳ）のバイト内に６ビットを定義する。
【０００４】
同様に、資料（"An Expedited Forwarding PHB", draft-ietf-diffserv-phb-ef-01.txt, Nov 1998, by V. Jacobson, et al.）に、まさにＡＴＭにおける定ビットレートサービスのような、異なる構成されたレートサービスにユーザが加入できるようにする１つの特定の符号点についての記述がある。
【０００５】
資料（"Assured Forwarding PHB Group", draft-ietf-diffserv-af-03.txt, Dec 1998, by J. Heinanen, et al.）に、ＡＴＭにおける実時間／非実時間可変ビットレートサービスに類似の、別のサービス種類についての記述がある。
【０００６】
そして、資料（"PPP in a real-time oriented HDLC-like framing," by C. Bormann, IETF draft August 1998）に、低ビットレートリンクを介した統合サービスを提供するための保留／再開指向の解が提案されている（ＰＰＰはポイント・ツー・ポイント・プロトコルを意味する）。
【０００７】
この提案は、ＰＰＰマルチリンク分割（fragmentation） プロトコル（例えば、資料（K. Slower et al., "The PPP Multilink Protocol (MP)," RFC1990, August 1996） を参照）及びそのマルチクラス拡張部分（例えば、資料（C. Bormann, "The Multi-class Extension to Multilink PPP," IETF draft August 1998）を参照）から構成される。
【０００８】
通信手段としてのインターネットの用法の１つは、仮想私設網（ＶＰＮ）と称する通信ネットワークを提供するように、異なる現場を一体に結合するための強化型データバックボーンとしての用法である。ＶＰＮの適用例は、企業の従業員が例えば家庭でインターネットを介して企業のデータネットワークに遠隔アクセスできるような、企業環境における適用である。ＶＰＮにおいては、公共通信ネットワーク施設を用いるにも拘わらず、閉ユーザ群に参加する遠隔ユーザに対するセキュリティ（機密保護）及び認証が与えられる。
【０００９】
実際、ＶＰＮの使用によって、企業及び従業員に、ＷＡＮ（広域ネットワーク）に似た通信手段が得られる（企業ネットワークでも又、例えば、ユーザが企業ネットワークにダイヤルするなどして直接に遠隔アクセスが可能であるが、ＶＰＮを利用する方が経済的に有利である）。
【００１０】
ＶＰＮを得るためには、ＰＰＴＰ（ポイント・ツー・ポイント・トンネリングプロトコル）及びＬ２Ｆ（レイヤー２・フォワーディング）プロトコルのような「トンネリングプロトコル」が用いられる。概していえば、トンネリングプロトコルにおいては、１個のパケットを別のパケット内に置くことにより公衆ネットワークを介して私用データストリームの生成が可能になる。ＶＰＮの構成においては、インターネットプロトコル（ＩＰ）パケットが別のＩＰパケット内に置かれる（ＩＰ・イン・ＩＰ）。
【００１１】
業界標準を設定する企てとして、ＩＥＴＦ（インターネット・エンジニアリング・タスクフォース（インターネットの研究開発及び標準化組織））が、Ｌ２ＴＰ（レイヤー２・トンネリングプロトコル）を開発中で、これは、ＰＰＴＰ及びＬ２Ｆの混成融合プロトコルである（例えば資料（K. Hamzeh, T, Kolar, M. Littlewood, G. Singh Pall, J. Taarud, A. J. Valencia, W. Verthein, 「Layer Two Tunneling Protocol "L2TP", Internet draft, Marh, 1998」）を参照）。
【００１２】
遠隔ユーザの場合、ＶＰＮへの一般的なアクセス形式は、ＶＰＮサービスを提供するインターネット接続サービス業者（簡単に、インターネット接続業者）への従来型電話サービスによる接続を介して行うアクセスである。
【００１３】
例えば、ユーザがアナログモデムをパソコン又は同等の装置に組み込み、特定のインターネット接続業者（以下、家庭用インターネット接続業者、と称する）の顧客アカウント（口座）を取得する（尚、ユーザのパソコンが上記トンネルプロトコルのうちの１つをサポートするように適切に構成されていると仮定する）。ユーザがＶＰＮにアクセスするには、単に、家庭用インターネット接続業者に対してデータ呼を発起して（例えば、その業者に連関する電話番号をダイヤルして）、ＶＰＮに「ログイン」（登録）するだけである。
【００１４】
【発明が解決しようとする課題】
上記したように、Ｌ２ＴＰプロトコルにおいては、いくつもの呼を搬送するために２つのＶＰＮサービス提供業者の間にトンネルが設立される。残念ながら、上記のＬ２ＴＰプロトコルは、「サービス品質」問題（「差異化サービス」問題としても知られる）を扱わない。このため、呼に対する保証最少帯域幅のようなサービス品質保証なしにＬ２ＴＰプロトコルを採用することを躊躇するユーザもある。
【００１５】
その結果、トンネルが設立された後に１個の符号点値のみを用いて呼ごとのサービス品質を相互処理により決定（相互処理決定）（negotiate） することができるようにＬ２ＴＰプロトコルを修正することがこの技術の当業者によって提案された（例えば、資料（"Layer Two Tunneling Protocol 'L2TP' IP Differential Services Extension," July 1998, draft-ietf-pppext-l2tp-ds-02.txt@http://www.ietf.org） を参照）。
【００１６】
残念ながら、１個の符号点値のみを用いて呼ごとのサービス品質を与える手法は、Ｌ２ＴＰに基づくシステムにおける問題に対する完全な解ではない。詳しくは、上記のＰＰＰマルチリンク・プロトコル（ＭＰ）及びそのマルチクラス拡張部分（マルチクラス対応のために拡張された部分）も又Ｌ２ＴＰ環境においてサポートされるべきであることを本発明者は認識している。
【００１７】
【課題を解決するための手段】
したがって、そして本発明に基づき、Ｌ２ＴＰにおける制御信号送信が、１つの呼の中で、「多数のサービスクラス」（マルチ・サービスクラス、とも称する）をサポートするように修正される。
【００１８】
本発明の一実施例において新しい「属性値の対」（属性値対）（ＡＶＰ）が、呼の設定用にＬ２ＴＰ制御メッセージにおいて使用するために定義される（Ｌ２ＴＰにおいて定義されるように属性値対を用いて更に制御信号が定められる）。
【００１９】
詳しくは、Ｌ２ＴＰ着信呼要求（ＩＣＲＱ）メッセージ又はＬ２ＴＰ発信呼要求（ＯＣＲＱ）メッセージが、サービス品質（ＱｏＳ）の属性値対（ＡＶＰ）を有し、このサービス品質の属性値対が、その呼の中でのサービス品質のクラスの個数を定義するためのフィールドを有する。個々のＰＰＰマルチクラス拡張部分ごとに１つのサービス品質が定義される。
【００２０】
本発明の別の実施例において、新しいサービス品質要求拡張部分及び新しいサービス品質回答拡張部分が、移動インターネットプロトコル（ＩＰ）ネットワークで用いるために定義される。
【００２１】
【発明の実施の形態】
本発明の概念を説明する前に、図１を参照して従来の技術のマルチリンク・プロトコル（ＭＰ）の例について述べる。図１は、カプセル化されたマルチリンク・プロトコル（ＭＰ）を有するＬ２ＴＰパケットの部分を示す。尚、この図１及びこれに続く同様な図面は、パケットで搬送される関連情報を集約して示すものであり、パケット内のフィールドの全てを示すものではない。
【００２２】
Ｌ２ＴＰ（レイヤー２・トンネリングプロトコル）パケット１０は、定義された「サービス品質」フィールドを有する。「サービス品質」フィールドは、インターネットプロトコル（ＩＰ）ではより一般的には「サービス種類」（ＴｏＳ）フィールドと称されるので、図中、ＴｏＳ１、として表す。
【００２３】
このフィールドに続いて「Ｌ２ＴＰシーケンス番号」フィールドがあり、例示では番号は「１」に設定され「＃１」と表す。「Ｌ２ＴＰシーケンス番号」フィールドに続いて「ＰＰＰヘッダ」フィールド及び「ＭＰクラス」フィールドがあり、例示ではこのパケットの「ＭＰクラス」は「１」である。
【００２４】
この技術分野で知られるように、Ｌ２ＴＰ制御メッセージ、及び異なるＬ２ＴＰデータセッションは、異なるシーケンス番号又はシーケンス番号群を用いる。詳しくは、Ｌ２ＴＰは現在のところ、特定のクラス又はリンクの、送信されたＰＰＰパケットの各々に対して、異なるシーケンス番号、又はシーケンス番号群を必要とする。
【００２５】
このことを、同じセッション１の一部であるＬ２ＴＰパケット１１及び１２として示す。Ｌ２ＴＰパケット１１は次のクラス１パケットを搬送するパケットで、Ｌ２ＴＰパケット１０と同じ設定されたシーケンス番号を用い、このフィールドの値としては単にシーケンス（又はシーケンス番号群）中の次の番号、すなわち、「２」をとる。
【００２６】
しかし、異なるクラスのＰＰＰデータ、すなわち、異なるＬ２ＴＰデータセッション、の場合になると、異なるシーケンス番号付けスペース、又はシーケンス番号群、が用いられる。このことを、セッション２のＬ２ＴＰパケット１２で表す。このＬ２ＴＰパケット１２は、ＭＰクラスが「２」で、全く異なるシーケンス番号系、例えば、「３１」を用いるＰＰＰデータを搬送する。
【００２７】
次に、図２に本発明の原理に基づく例示の通信システム１００を示す。本発明の概念の他は、構成要素は周知であり、詳細には説明しない。例えば、パソコン（ＰＣ）１０５は、インターネット接続を設立するために公衆交換電話ネットワーク（ＰＳＴＮ）１１０を介してインターネット接続業者Ａに対しダイヤルアップ方式のアクセスを行うためのデータ通信装置（図示しない）を有する。
【００２８】
同様に、通信システム１００の構成要素間の実線は、それぞれの終点間の周知の通信施設を表す。例えば、パソコン１０５と公衆交換電話ネットワーク１１０との間の接続実線は市内ループ接続回線を表し、インターネット接続業者Ａとインターネット１３０との間の接続は同期光ネットワーク（ＳＯＮＥＴ）を介して非同期転送モード（ＡＴＭ）によってサポートされる、等である。
【００２９】
更に、本説明の読み手が上記Ｌ２ＴＰプロトコル、急速回送サービス（Expedited Forwarding Service）、保証回送サービス（Assured Forwarding Service）、並びに、マルチクラス拡張部分を含むＰＰＰマルチリンク・プロトコル（ＭＰ）（以下、ＭＰプロトコル、とも称する）に詳しいものと仮定する。
【００３０】
ここで、次の用語を次の定義で用いることとする。
ｍＬ２ＴＰ＝「Ｌ２ＴＰ」（資料 （K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, A. J. Valencia, W. Verthein:Layer Two Tunneling Protocol "L2TP", Internet draft, March, 1998） に定義される）に本説明に記述の修正（modification）を加えた「修正版Ｌ２ＴＰ」。
【００３１】
ＬＡＣ＝ｍＬ２ＴＰアクセス制御装置、すなわち、ｍＬ２ＴＰをサポートするネットワークアクセスサーバ（ＮＡＳ）。
ＬＮＳ＝ｍＬ２ＴＰをサポートするネットワーク・サーバ（ＮＳ）。
【００３２】
尚、これらの定義は、本発明の概念の例示説明を簡単にするために用いられる。このため、そして又この技術分野の当業者に明らかなように、本発明の概念は、これらの定義により制限されるものではなく、どのトンネリングプロトコル及び連関する処理装置にも適用可能である。
【００３３】
図２から判るように、通信システム１００は、インターネット接続業者Ａネットワークとして表されるようなインターネット接続業者Ａからなる。後者すなわち、インターネット接続業者Ａネットワークは、ｍＬ２ＴＰアクセス制御装置（ＬＡＣ）１５５（取り扱い担当のＬＡＣとも称する）からなり、このｍＬ２ＴＰアクセス制御装置１５５（又は簡単に、アクセス制御サーバ）は、この技術分野で知られる（インターネット接続業者Ａの）「アクセスポイント」（point of presence） ルータ（図示しない）、ローカル・ネットワーク１６０、及びルータ１６５を有する。
【００３４】
ここに、遠隔に位置する企業従業員がその企業の例示ネットワークに、ｍＬ２ＴＰをサポートするネットワーク・サーバ（ＮＳ又はＬＮＳ）１３５（又は簡単に、ネットワーク・サーバ）を介してアクセスするためのＶＰＮ（仮想私設網）サービスをインターネット接続業者Ａが提供し、これにより、他の種々の機能のほかに、ルーティング（検討された経路による転送）及びファイヤウオールの能力が得られるものと仮定する。（企業のネットワークは例えば、ネットワーク・サーバ１３５の背後に適切に保護されたローカル・エリア・ネットワークの集合であると仮定する。）
【００３５】
ＶＰＮサービス（例えばパソコン１０５に連関するユーザのためのＶＰＮサービス）は、インターネット接続業者Ａを介しての点線１及び点線２によって表される。この場合、接続構成（conductivity）は、２点間接続通信用（ポイント・ツー・ポイント）のマルチリンク・プロトコル（ＭＰ）のセッションであり、その終点は、一端が、遠隔ユーザのネットワーク処理用装置（パソコン１０５で表されるような）であり、他端が、この接続構成がネットワーク・サーバ１３５において終端するその終端装置である。
【００３６】
（尚、要すれば計数課金処理を、取り扱い担当のアクセス制御サーバ、及びネットワーク・サーバで行うことができる。すなわち、各構成要素が、パケット、８ビットバイト、並びに接続開始及び停止時刻を計数する。）
【００３７】
説明の都合上、ＶＰＮサービスをサポートするためのトンネルが、既知のＬ２ＴＰ手法又は米国特許出願（of Chuah:entitled "Providing Quality of Service in Layer Two Tunneling Protocol Networks," serial No.09/259900, filed on February 26, 1999）に記述される方法を用いて、取り扱い担当のアクセス制御サーバ（ＬＡＣ）とネットワーク・サーバ（ＬＮＳ）との間に既に設定され又は相互処理決定されているものと仮定する。
【００３８】
更に、ユーザがＶＰＮサービスへのアクセスを望み、既に認証されているものと仮定する。（例えば、安全な管路に対して、ＩＥＴＦが、保全のための２つのプロトコルすなわち、ＰＡＰ（パスワード認証プロトコル）及びＣＨＡＰ（パスワード暗号化認証プロトコル）を定義している（これらについては、例えばＩＥＴＦのＲＦＣ（規格書）１３３４「ＰＰＰ認証プロトコル」を参照されたい）。
【００３９】
明らかに、もしアクセス制御サーバ（ＬＡＣ）１５５がユーザを認証できない場合、接続は受け入れられない。本発明の構成においては、ユーザと取り扱い担当のアクセス制御サーバ（ＬＡＣ）との間の接続がマルチリンク・プロトコル（ＭＰ）をサポートし、同様に認証されるものと仮定する。
【００４０】
個別のセッション、又は呼、については、アクセス制御サーバ（ＬＡＣ）１５５（又はネットワーク・サーバ（ＬＮＳ）１３５）が、ユーザからの着信呼を設定するための要求を受信する。本発明の概念に基づき、個別のセッションの各々が多数のサービス品質を要求できる。
【００４１】
アクセス制御サーバ（ＬＡＣ）１５５（又はネットワーク・サーバ（ＬＮＳ）１３５）が、ユーザの、事前定義されたプロフィル（概観）に基づいて、又は受信されたＭＰメッセージに定義されたように、関連トラフィックパラメータ及びサービス品質（符号点）（下に述べる）を定める。
【００４２】
（前者、すなわち、ユーザプロフィルに基づく場合には、アクセス制御サーバ（ＬＡＣ）１５５（又はネットワーク・サーバ（ＬＮＳ）１３５）が、この技術分野で知られるように、それぞれの認証・許可・課金サーバと通信して、例えば、ユーザぼログイン名に基づいてユーザのプロフィルを得る。しかし、本説明の以下残りの部分においては、本発明の概念を、アクセス制御サーバ（ＬＡＣ）１５５への着信呼でＭＰメッセージを用いた場合について述べる。）
【００４３】
上記の仮想ダイヤルアップサービスをサポートするために、そして本発明の概念に基づき、Ｌ２ＴＰの一形式であるｍＬ２ＴＰプロトコルが用いられる。Ｌ２ＴＰの場合のように、ｍＬ２ＴＰプロトコルには、与えられたトンネルで動作する２つの並行成分がある。すなわち、アクセス制御サーバ（ＬＡＣ）及びネットワーク・サーバ（ＬＮＳ）の各対の間の制御メッセージ、並びに同じＬＡＣ・ＬＮＳ対の間のペイロードパケットの２つである。
【００４４】
後者は、そのＬＡＣ・ＬＮＳ対の間のユーザのデータセッションのためのｍＬ２ＴＰカプセル化されたＭＰパケットを搬送するために用いられる。Ｌ２ＴＰの場合のように、「次受信」（Ｎｒ）フィールド及び「次送信」（Ｎｓ）フィールドが制御メッセージ内に常に存在し、ペイロードパケット内にはオプションとして存在する。制御メッセージ及びペイロードメッセージは異なるシーケンス番号群を用いる。
【００４５】
上記のＬＡＣ・ＬＮＳ対のシナリオ（動作モデル）については、「次受信」及び「次送信」のフィールドの維持及び使用に関する限り、Ｌ２ＴＰプロトコル案（draft） の定義に変更はない。
【００４６】
上記のように、呼が設立される前に、ｍＬ２ＴＰ制御メッセージが、取り扱い担当のアクセス制御サーバ（ＬＡＣ）とネットワーク・サーバ（ＬＮＳ）との間で交換される。したがって、２つのＬ２ＴＰピア（対等サーバ）が多数のサービスクラス（マルチ・サービスクラス）を有する呼を設立、又は相互処理決定できるようにするために、新しい属性値の対（下に述べる）が定義されて、Ｌ２ＴＰ制御メッセージ（したがって、これがｍＬ２ＴＰ制御メッセージとなる）に用いられる。
【００４７】
であるから、このような呼を設立するためのサービス品質の相互処理決定が加わる他には、Ｌ２ＴＰトンネル設定手順は変わらないことを認識されたい。
【００４８】
次に図３について説明する。図３は、単一の呼内で多数のサービス品質を相互処理決定するための本発明に基づく方法を例示する高次レベルの流れ図である。（アクセス制御サーバ（ＬＡＣ）１５５及びその他のサーバがそれぞれ、従来の（したがってここには述べない）プログラム作成手法を用いて、下に述べる方法を実行できるように、これらサーバが適切にプログラムされているものと仮定する。）
【００４９】
図３のステップ３０５において、取り扱い担当のアクセス制御サーバ（ＬＡＣ）が、マルチリンク・ヘッダを有する１個のＰＰＰ・ＬＣＰフレームをユーザから受信する。マルチリンク・ヘッダを識別の後、取り扱い担当のアクセス制御サーバ（ＬＡＣ）（例えば、１５５）が、修正されたマルチリンク・ヘッダ内の「推測クラス番号」フィールドの値及び連関するサービス種類の値を点検して、着信呼要求（ＩＣＲＱ）メッセージ（下に述べる）への添付用に、適切な「サービス品質要求の属性値対」を生成する。
【００５０】
（この技術分野で知られるように、「推測クラス番号」フィールド（"# Susp. Clses" field） は現在のところ、マルチリンク・ヘッダにおいて利用可能である。したがって、そして本発明の概念に基づき、マルチリンク・ヘッダが、サービス品質情報（図１４において３個のＴｏＳ（サービス種類）として例示）を追加して搬送するために、図１４に示すように修正される。）
【００５１】
ステップ３１５において、取り扱い担当のアクセス制御サーバ（ＬＡＣ）が、サービス品質（ＱｏＳ）要求の属性値対を有する着信呼要求メッセージを送信する。本発明の概念に基づき、サービス品質要求の属性値対が、この呼に連関するサービス品質クラスの個数及びサービス品質の種類を指定する（下で更に述べる）。
【００５２】
ステップ３２０において、取り扱い担当のアクセス制御サーバ（ＬＡＣ）が、受信された着信呼回答メッセージの中でサービス品質回答の属性値対を有する回答を受信する。それからステップ３２５において、取り扱い担当のアクセス制御サーバ（ＬＡＣ）が、着信呼接続（ＩＣＣＮ）メッセージで応答する。２つのＬ２ＴＰピア（対等サーバ）（ここではアクセス制御サーバ（ＬＡＣ）及びネットワーク・サーバ（ＬＮＳ）で表される）の間で上記の処理を行うための、これに対応する制御メッセージの処理を図４に例示する。
【００５３】
図５に、サービス品質（ＱｏＳ）要求の属性値対（ＡＶＰ）のフォーマットを例示する。この属性値対の最初の４ビットは、予め定義されたビットパターンの「１１００」（Ｌ２ＴＰの定義）を有する。ビット位置４及び５は、「何でもかまわない」（don't care）値である。そして、ビット位置６及び７は、２個の新しいパラメータ「Ｄ」及び「Ｌ」で、「Ｄ」は遅れクラスビットを表し、「Ｌ」は損失クラスを表す。
【００５４】
「Ｄ」ビットは、もし基本をなすトンネルが遅れクラスのみをサポートする場合に用いられる。言い換えれば、もし「Ｄ」ビットが着信呼要求メッセージに設定される場合、差異化された符号点のうちの遅れビットのみが考慮される（下に述べる）。同様に、「Ｌ」ビットは、もし基本をなすトンネルが損失クラスのみをサポートする場合に用いられる。すなわち、もし「Ｌ」ビットが設定される場合、符号点のうちの損失ビットのみが考慮される
【００５５】
「Ｄ」及び「Ｌ」のビットに続いて、８ビット長のフィールドがありその値はこの属性値対のサイズを表す。８ビット長のフィールドの後には、２バイトの、「業者（ベンダ）に固有のＩＤ（識別名）」のフィールドがある。（ここでは一例として、ルーセント社（Lucent）のＩＤを搬送する場合を示し、又この呼が多数のサービス品質を有することを表す。）（代わりに、これを、このメッセージが多数のサービス品質を有する呼メッセージであることを明らかにする予め定義されたｍＬ２ＴＰ属性値対の符号に置き換えてもよい。）
【００５６】
「業者に固有のＩＤ」フィールドの次には、２バイトの「Ｌ２ＴＰ属性種類」のフィールドがあり、ここでは「１」に設定される。「属性種類」のフィールドの次には、要求されているサービス品質の個数を指定する「クラス個数」のフィールドがある。この例では、「クラス個数」のフィールドは、図３のステップ３０５において定められる異なるクラスの個数に等しい。
【００５７】
「クラス個数」のフィールドの次には、「クラス個数」のフィールドの値によって指定される個数の「差異化サービス符号点値」（differentiated services code point values） （１バイト長のサービス品質識別名）が来る（「サービス品質」フィールド）。（図５のサービス品質要求の属性値対に対して、「クラス個数」のフィールドの例示値は「３」である。）
【００５８】
各サービス品質は、連関するＰＰＰクラス拡張部分に対する差異化されたサービスの、特定のクラスを定める。加えて、各サービス品質バイトの最初の２ビットは、格上げ可能ビット「Ｐ」及び格下げ可能ビット「Ｍ」を表す。言い換えれば、「Ｐ」及び「Ｍ」のビットの用法は、クラスごとに定められる。
【００５９】
「Ｐ」及び「Ｍ」のビットが「０」の値を表すときは、そのクラスに対するそのセッションのデータチャネル内のＩＰパケットに、選択された差異化符号点値のみが用いられることを、Ｌ２ＴＰピア（サーバ）が示している。
【００６０】
「Ｐ」ビットが設定されると、それは、もし要求されたサービス品質がクラスとして利用可能でない場合に、より高いサービスレベルを有する差異化サービス符号点値を、ｍＬ２ＴＰピアが推薦できることを意味する。「Ｍ」ビットが設定されると、それは、もし要求されたサービス品質がクラスとして利用可能でない場合に、より低いサービスレベルを有する差異化サービス符号点値を、ｍＬ２ＴＰピアが推薦できることを意味する。
【００６１】
「マルチ・サービス品質」のフィールドに続いて、要すれば、「パッディング」（詰め物）フィールドが、属性値対メッセージを埋めるために用いられる。
【００６２】
差異化サービス符号点値の値は、上記の保証回送サービス（Assured Forwarding Service）における符号点の定義に類似の仕方で定義される。詳しくは、これら２つのｍＬ２ＴＰピアが１つの呼にクラスＡijを設定する。ここに、「ｉ」は遅れクラスの種類を表し、「ｊ」は損失クラスの種類を表す。ここでは例示の目的だけで、ｉ＝１，２，３，４；ｊ＝１，２，３とする。
【００６３】
したがって、１つの呼に対してクラスが４個あり、各クラスが、異なる１つの遅れ優先クラスをサポートする。すなわち、各クラスが、次の表に示すような差異化されたサービス符号点（差異化サービス符号点）Ａix、ｉ＝１，２，３，４、を有する。
【００６４】
「Ｘ」は,「何でもかまわない」（don't care）状態を表す。すなわち、値は２進値の「０」又は「１」である。差異化サービス符号点Ａijを有する個々のセッションが、差異化サービス符号点Ａixをサポートするトンネルに写像される。
【００６６】
同様に、これら２つのｍＬ２ＴＰピアが、異なる損失優先クラスをサポートする呼、すなわち、次の表に示すような差異化サービス符号点Ａxj、ｊ＝１，２，３，を有する呼、を設定する。
【００６７】
したがって、保証回送サービスについては、「００１ＸＸＸ」又は「ＸＸＸ０１０」のような差異化符号点値が種々のクラスに対して受け入れ可能である。（適切なトラフィック処理のためには、２つのｍＬ２ＴＰピアが、保証回送サービスをサポートする各トンネルについてのレートを指定することが必要である。
【００６９】
このような仕様を用いることにより、ｍＬ２ＴＰピアがいつデータセッションを許可／拒絶すべきかを定めることができる。ｍＬ２ＴＰピアは又、利用可能な資源（帯域幅及びバッファ）を、設立された異なるトンネルの間でどのように共用させるかを定めることができる。
【００７０】
同様に、前に述べた急速回送サービスについては、サービス品質要求の属性値対は、急速回送サービス符号点（すなわち、差異化符号点値）及び要求された平均レートを有する。
【００７１】
着信呼要求又は着信呼回答におけるサービス品質要求属性値対の存在は、一方のｍＬ２ＴＰピアが、或る特定のＰＰＰ呼のデータパケット全てに対していくつもの差異化サービス符号点を用いたいと望んでいることを示す。
【００７２】
もし資源の不足からｍＬ２ＴＰピアがどの符号点も受け入れられない場合、そのｍＬ２ＴＰピアは、もし上記の格上げ／格下げ可能ビットが設定されているならば、代わりの符号点を推薦できる。もし設定されていないならば、ｍＬ２ＴＰピアはその呼要求を拒絶する。したがって、サービス品質許諾の属性値対（下に述べる）に見いだされる値が、ｍＬ２ＴＰピアが受け入れようとしている値を示す。
【００７３】
加えて、サービス品質要求の属性値対は、或る特定のクラスに対して更なるトラフィックパラメータの指定を許す別のパラメータを有する。図５においては、「サービス品質２」のみが追加パラメータを指定する状態を示す。
【００７４】
トラフィックパラメータには、要求レートのフィールド、許容バーストサイズのフィールド、オプションの過剰バーストサイズのフィールド、ピークレートのフィールド、及びオプションの損失／遅れ要件のフィールドが含まれる。これらのトラフィックパラメータを用いることによって、呼内のクラスに量的な遅れ／損失保証が付与され、呼が許可される確率が改善される（帯域幅多重が増加する）。
【００７５】
詳しくは、要求レートのフィールドの値がそのクラスに対する要求された平均ｂｐｓ（秒当たりのビット数）を表す。許容バーストサイズのフィールド値の要求は、送信機がピークレートでどれだけ長い間パケットを送信できるかを表す。過剰バーストサイズのフィールド値の要求は、送信機が許容バーストサイズをどれだけ長い間超過できるかを表す。
【００７６】
ピークレートのフィールド値の要求は、要求されるピークレートを例えばｂｐｓ値で表す。損失／遅れ要件のフィールド値の要求は、パケット損失（上記の「Ｌ」ビットフィールドが設定される）又は遅れクラス（上記の「Ｄ」ビットフィールドが設定される）を表す。パケット損失については、この値は許容パケット損失のパーセント値、例えば１％、５％等、を表す。遅れについては、この値は許容遅れを例えば、ミリ秒で表す。
【００７７】
図６は、着信呼メッセージでトンネル終端装置（例えば、図２のネットワーク・サーバ１３５）によって送信されるサービス品質（ＱｏＳ）許諾の属性値対（ＡＶＰ）についての例示フォーマットである。このサービス品質許諾の属性値対のフィールドは、上記のサービス品質要求の属性値対のフィールドと相補的なものである。
【００７８】
この場合、「Ｄ」又は「Ｌ」のビットはなくて、応答側サーバは、表示フィールド内に許諾されたレートを示す「許諾レート」及び「保証損失／遅れ値」（オプション）を表示する。許諾されたレートは要求されたレートよりも小さい。（ここで、もし多数のサービス品質を逆方向に相互処理決定する必要がある場合いは、ネットワーク・サーバが又、着信呼回答メッセージ（図示しない）に、本発明の概念に基づきサービス品質要求の属性値対を添付するようになることに留意したい。）
【００７９】
上記の相互処理決定を行うために、対応する制御メッセージ処理を２個のｍＬ２ＴＰピア（ここではアクセス制御サーバ及びネットワーク・サーバによって表される）間で行い、そのネットワーク・サーバが呼要求を発起する場合の、制御メッセージ処理を図７に例示する。この場合、対応する発信呼要求（ＯＣＲＱ）、発信呼回答（ＯＣＲＰ）、及び発信呼接続（ＯＣＣＮ）のメッセージは、上記のように適切に修正される。
【００８０】
上記から判るように、マルチリンク・ＰＰＰへのマルチクラス拡張部分の添付をサポートするための、Ｌ２ＴＰプロトコルへの柔軟なサービス品質拡張部分の添付について説明した。その結果、ペイロードが、異なるサービスクラスを表すにも拘わらず、ペイロードに用いるシーケンス番号群は１つだけでよい。これを図８に示す。セッションが１つだけ設立される。Ｌ２ＴＰパケット２０は、「ＴｏＳ１」で表される定義された「サービス品質」フィールドを有する。
【００８１】
このフィールドに続いて「Ｌ２ＴＰシーケンス番号」フィールドがあり、例示では番号は「１」に設定される。Ｌ２ＴＰパケット２１は次の「クラス１」パケットを搬送するもので、Ｌ２ＴＰパケット２０と同じシーケンス番号群を用い、そのフィールド値は、単にそのシーケンス中の次の番号すなわち「２」である。
【００８２】
しかし、異なるクラスのＰＰＰデータの場合になっても、本発明の概念に基づき、同じシーケンス番号付けスペース、又はシーケンス番号群、が用いられる。このことを、Ｌ２ＴＰパケット２２で表す。このＬ２ＴＰパケット２２は、ＭＰクラスが「２」で、同じシーケンス内の次の番号すなわち「３」を用いるＰＰＰデータを搬送する。
【００８３】
次に図９に、代表的なネットワーク・アクセスサーバ（Ｌ２ＴＰピア）、すなわち、パケットサーバ、６０５の高次レベルのブロック図を本発明に基づいて示す。パケットサーバ６０５は、内蔵プログラム制御に基づくプロセッサ構造で、プロセッサ６５０、例えば、サービス品質に関連する上記の新しい属性値対（ＡＶＰ）メッセージを通信するためのプログラム命令及びデータを格納記憶するためのメモリ６６０、及びパス６６６で表されるような１個以上の通信施設に結合するための通信インタフェース６６５を有する。
【００８４】
尚、各アクセス制御サーバ（ＬＡＣ）は、着信呼要求（ＩＣＲＱ）のサービス品質（ＱｏＳ）要求属性値対（ＡＶＰ）に指定されるように多くの呼ごとの、又はセッションごとの待ち行列を維持することを注記したい（他のセッションのバッファは図示しない）。本発明に基づき、データチャネルについて呼ごとに１個のシーケンス番号群だけが用いられる。
【００８５】
各待ち行列に対するパケットは、厳格な優先権計画アルゴリズム又は重み付けした公正待ち行列型の計画アルゴリズムを用いて処理される。異なる待ち行列を図９のメモリ６６０内のＱｏＳ１待ち行列及びＱｏＳ２待ち行列で示す。
【００８６】
したがって、差異化サービスをインターネット接続業者Ａが呼の中で提供できる。例えば、図２のインターネット接続業者Ａが次の３種類のデータサービスを提供すると仮定する。すなわち、ゴールド（ＩＰ音声通話用）、シルバー（緊急データ用）、及びブロンズ（通常のデータ用）のデータサービスである。各ユーザは、これら３種類のデータサービスのどれにも加入できる。
【００８７】
加えて、各ユーザは、そのユーザがインターネットアクセス、企業ネットワークアクセス、又は混合サービスのどれを望むかを指定できる。更にユーザは、それらサービスの、事前格納記憶されているプロフィル（図示しない）を介して、特定のデータサービスについて使用したい或る帯域幅を、例えばゴールドを８ｋｂｐｓで、シルバーを５６ｋｂｐｓでというように指定できる。
【００８８】
尚、本発明の概念が他のネットワークにおける保証／差異化サービスの提供にも適用可能であることを注記したい。一例として、本発明に基づく広域無線データネットワークを図１０に示す。本発明の概念を除いては、このネットワークの構成要素は周知であり詳細説明はしない。例えば、移動終端又は移動ノードが、移動ノード９０５で表される。移動ノード９０５は基地局９１０に接続される。
【００８９】
説明上、基地局９１０が、ポリシーサーバ（図示しない）を有する中間域外エージェント９１５によって取り扱われる「域外区域」の一部であると仮定する。中間域外エージェント９１５はゲートウェイ域外エージェント／動的域内エージェント９２０に接続される。
【００９０】
同様に、移動ノード９０５のユーザ（図示しない）は「域内（ホーム）区域」に連関する。「域内区域」はゲートウェイ域内エージェント９２５及び域内エージェント９３０によって構成される。周知のユーザ認証方法が、例えば、認証・許可・課金（ＡＡＡ）サーバ（図示しない）を介して用いられる。
【００９１】
この構成において、基地局９１０、中間域外エージェント９１５、ゲートウェイ域外エージェント／動的域内エージェント９２０、ゲートウェイ域内エージェント９２５、及び域内エージェント９３０は全て、異なる形態のパケットサーバである。例えば、ゲートウェイ域外エージェント／動的域内エージェント９２０とゲートウェイ域内エージェント９２５との間の通信は、ＩＰ系ネットワーク９４０を介して行われる。
【００９２】
本発明の概念による修正を除いては、図１０の通信システムは、移動ＩＰプロトコルを用いる。移動ＩＰプロトコルは、移動ノードが移動中接続を維持できるように設計されている。（例えば、資料（C. Perkins et al., "IP mobility support," RFC2002, Oct 1996） を参照されたい。）このため、ここでは移動ＩＰプロトコルの、本発明の概念によって修正される部分のみを説明する。
【００９３】
移動ＩＰプロトコルにおいて移動ノード９０５はリンク層メッセージ処理手段（図示しない）を介して基地局９１０に登録する。詳しくは、移動ノード９０５が登録要求メッセージを基地局９１０に送信する。基地局９１０がリンク層信号手段を用いて要求を中間域外エージェント９１５に通信する。それから中間域外エージェント９１５が、関連するフィールドを修正後に移動ＩＰ登録要求メッセージをゲートウェイ域外エージェント９２０に中継する。
【００９４】
それに続いて、移動ノード（例えば、移動ノード９０５）のために、「複合トンネル」が域内エージェント（例えば、域内エージェント９３０）と域外エージェント（例えば、域外エージェント９１５）との間に設定される。（例えば、資料（S. Blake et al., "An architecture for differentiated services," RFC2475 Dec 1998）を参照されたい。）（尚、もしネットワーク層信号手段が用いられる場合、複合トンネルは基地局９１０から域内エージェント９３０までである。どちらの場合も、本発明が等しく適用される。）
【００９５】
「サービス品質」（ＱｏＳ）を移動ＩＰに導入するように提案がなされているが、現在、移動ノードからのトラフィックは、移動ＩＰトンネルにおける最善努力トラフィックとして、「ＩＰ・イン・ＩＰ」方式（ＩＰパケットが別のＩＰパケット内に置かれる）で行われている。（このような「サービス品質」提案の一例が資料（"IP encapsulation in IP," by C. Perkins, RFC2003, Oct 1996）にみられ、そこでは、「サービス種類」（ＴｏＳ）フィールドのバイト内にある６ビット符号点に基づいてサービス品質を与える枠組を提案している。
【００９６】
又、この資料の１つ前に引用した資料（Blake et al.）には、外部ＩＰヘッダの）「サービス種類」（ＴｏＳ）バイトを、内部ＩＰヘッダにある値と同じ値でマーク付けする手法が記述されている。
【００９７】
しかし、本発明の概念に基づき、新しい「サービス品質」（ＱｏＳ）要求に関する拡張部分がこの移動ＩＰ登録要求メッセージに含められる。この新しい「サービス品質」要求拡張部分により、ユーザが同じセッション内で多数のサービス品質を要求することができる。加えて、この手法で、複合トンネル内の異なるセグメントが、関連するサービス品質によって異なる動作をすることが可能になる。（説明上、各セグメントの終端部分のみが、「サービス品質」に責任を有しその保証に同意するものと仮定する。）
【００９８】
本発明の概念に基づき、移動ノード９０５が最初に基地局９１０に登録するとき、移動ノード９０５が登録要求メッセージ内に「サービス品質」（ＱｏＳ）要求に関する拡張部分（サービス品質拡張部分）を添付する（以下、修正された登録要求メッセージ（修正登録要求メッセージ）と称する）。このサービス品質拡張部分により、ユーザがその接続に対して必要と考えるだけの多数のサービス品質のクラスを要求できる。
【００９９】
各レベルにおいて、もし対応する移動通信エージェント（例えば、基地局、中間域外エージェント、等）が、要求されたサービス品質を許諾するに十分な資源を得られない場合に、そのエージェントが、このサービス品質拡張部分を修正する。例えば、ゲートウェイ域外エージェント９２０が、そのユーザを受け入れるかどうかを、利用可能な資源及びユーザの要求の基づいて決定する。
【０１００】
もしユーザの要求が受諾される、すなわち、ユーザが受け入れられる場合、ゲートウェイ域外エージェント９２０が、修正登録要求メッセージをゲートウェイ域内エージェント９２５に送る。
【０１０１】
（もし図１０のネットワークにおいてゲートウェイ域外エージェント９２０とゲートウェイ域内エージェント９２５との間のセグメントについて現在輻輳がある場合には、ゲートウェイ域外エージェント９２０は又、サービスの格上げ又は格下げ能力に基づいて新しいしかし関連する符号点を選択することもできる。）
【０１０２】
ゲートウェイ域外エージェント９２０がゲートウェイ域内エージェント９２５から肯定的回答を受信すると、ゲートウェイ域外エージェント９２０はこの情報を、そのローカル・ポリシーサーバ（図示しない）又はその連関する認証・許可・課金サーバ（図示しない）に格納する。
【０１０３】
それからゲートウェイ域外エージェント９２０が、許諾されたサービス品質に関する拡張部分をメッセージに添付してより低次のレベルの移動通信エージェントに送る。より低次のレベルの移動通信エージェントは、「サービス品質」情報をそのローカル・ポリシーサーバ（図示しない）に格納する。（尚、このような格納は、情報を、格納された登録テーブルへのエントリとして格納するのと同じ程度に簡単であることを注記したい。）
【０１０４】
このようにして、サービス品質要求拡張部分により、移動ノード９０５が望む差異化サービスの符号点（コードポイント）（又は差異化サービスクラスの符号点）の指定が可能となり、１つの呼に対するオプションのトラフィックパラメータの指定も可能となる。移動ＩＰの登録要求メッセージ及び登録許諾メッセージに用いるための、「サービス品質要求拡張部分」及び「サービス品質回答拡張部分」のフォーマットを図１１及び図１２に例示する。
【０１０５】
尚、トンネル及び呼ＩＤ（識別名）が、「サービス品質要求拡張部分」及び／又は「サービス品質回答拡張部分」にある。これらの識別名は後に、包括的なルーティング及びカプセル化トンネルにおける搬送側データに用いられる。特定のサービス品質クラスのための搬送側データは、ＩＰ「サービス種類」（ＴｏＳ）バイト中の適切な「サービス種類」符号点を用いる。
【０１０６】
図５及び図６に示す「属性値対」（ＡＶＰ）メッセージと同様の仕方で、「サービス品質要求拡張部分」及び「サービス品質回答拡張部分」が、「クラスの個数」フィールドを有する。要求されたクラスが各々、対応する「サービス種類」（ＴｏＳ）バイトに示される（例えば、「ＴｏＳ１」、「ＴｏＳ２」等）。各「サービス種類」バイトは、「Ｐ」及び「Ｍ」のビットを有する。
【０１０７】
各クラスについてのオプションのトラフィックパラメータも図中に示す。（したがって、「サービス品質クラスの個数」フィールドには又、メッセージに含まれるオプションのトラフィックパラメータの個数も含まれる。）（しかし、これらのオプションのトラフィックパラメータは代わりに、ユーザプロフィルの一部として認証・許可・課金サーバ（図示しない）に格納することもできる。）
【０１０８】
オプションのトラフィックパラメータがあることで、顧客に販売可能なサービスという意味でのより多くの柔軟性が得られ、又よりよい帯域幅多重利得が得られるより高性能の受け入れ制御アルゴリズムが可能となる。「サービス品質回答拡張部分」において、サービス品質要求が許諾されるか又は拒絶されるかを示すために、符号フィールドが用いられる。
【０１０９】
移動ＩＰ登録及び回答メッセージへの別の修正を図１３に示す。移動ＩＰ登録要求メッセージ６０が、追加の「サービスオプション」フィールドからなり、それぞれ、連関するサービス品質を有する。「サービスオプション」フィールドは、サービス種類、例えば、インターネットアクセス、ＶＰＮ（仮想私設網）、混合サービス（例えば、インターネット及びＶＰＮの両方）の要求を搭載する。同様に、移動ＩＰ登録回答メッセージ６１に示されるような、対応する移動ＩＰ登録回答メッセージもある。
【０１１０】
以上の説明は、本発明の一実施例に関するもので、この技術分野の当業者であれば、本発明の種々の変形例を考え得るが、それらは本明細書に明示はしないがいずれも本発明の技術的範囲に包含される。
【０１１１】
例えば、本発明の概念を、取り扱い担当のアクセス制御サーバ（ＬＡＣ）からネットワーク・サーバ（ＬＮＳ）へトンネルが設立される構成に基づいて説明したが、本発明の概念は、例えば、米国特許出願（Chuah et al., entitled "A Multi-Hop Point-to-Point Protocol," serial No.09/074745, filed on May 5, 1998） に記述されるような、マルチ・ホップ・トンネル方式の構成にも適用可能である。
【０１１２】
尚、特許請求の範囲に記載した参照番号は発明の容易な理解のためで、その技術的範囲を制限するよう解釈されるべきではない。
【０１１３】
【発明の効果】
以上述べたごとく本発明によれば、Ｌ２ＴＰプロトコルに基づくデータ通信において、従来の技術と異なり、「サービス品質要求及び回答を扱う拡張部分」を制御メッセージに含めるようにＬ２ＴＰプロトコルを修正し、提供するサービス品質のクラスを相互処理により決定して呼を設定するようにしたので、ユーザの要求に対応したマルチ・品質レベルのサービスの提供が可能となる。
【図面の簡単な説明】
【図１】従来の技術において知られているような、カプセル化されたマルチリンク・プロトコル（ＭＰ）を有するＬ２ＴＰパケットの部分を示す説明図である。
【図２】本発明の原理に基づく通信システムを示すブロック図である。
【図３】図２の通信システムで用いられる例示方法の流れ図である。
【図４】本発明の原理に基づき呼のサービス品質を決めるための制御メッセージの処理を例示する説明図である。を
【図５】本発明の原理に基づいて用いるための新しいＬ２ＴＰ属性値対メッセージ（サービス品質要求属性値対）を示す説明図である。
【図６】本発明の原理に基づいて用いるための新しいＬ２ＴＰ属性値対メッセージ（サービス品質許諾属性値対）を示す説明図である。
【図７】本発明の原理に基づき呼のサービス品質を決めるための別の制御メッセージの処理を例示する説明図である。を
【図８】本発明の原理に基づく、カプセル化されたマルチリンク・プロトコル（ＭＰ）を有するＬ２ＴＰパケットの部分を示す説明図である。
【図９】パケットサーバの高次レベルの例示ブロック図である。
【図１０】本発明の原理に基づく別の通信システムを示すブロック図である。
【図１１】本発明の原理に基づいて用いるための別のサービス品質型のメッセージ（サービス品質要求拡張部分）を示す説明図である。
【図１２】本発明の原理に基づいて用いるための別のサービス品質型のメッセージ（サービス品質許諾拡張部分）を示す説明図である。
【図１３】本発明の原理に基づく登録及び回答メッセージを搬送する移動インターネットプロトコル（ＩＰ）パケットの部分を示す説明図である。
【図１４】修正されたマルチリンク・ヘッダの一部分を示す説明図である。
【符号の説明】
１０、１１、１２ Ｌ２ＴＰ（レイヤー２・トンネリングプロトコル）パケット
２０、２１、２２ Ｌ２ＴＰパケット
６０ 移動体ＩＰ登録要求メッセージ
６１ 移動体ＩＰ登録回答メッセージ
１００ 通信システム
１０５ パソコン（ＰＣ）
１１０ 公衆交換電話ネットワーク（ＰＳＴＮ）
１３０ インターネット
１３５ ｍＬ２ＴＰをサポートするネットワーク・サーバ（ＮＳ又はＬＮＳ）
１５５ ｍＬ２ＴＰアクセス制御装置（サーバ）（ＬＡＣ）
１６０ ローカル・ネットワーク
１６５ ルータ
６０５ パケットサーバ
６５０ プロセッサ
６６０ メモリ
６６５ 通信インタフェース
６６６ パス
９０５ 移動ノード
９１０ 基地局
９１５ 中間域外エージェント
９２０ ゲートウェイ域外エージェント／動的域内エージェント
９２５ ゲートウェイ域内エージェント
９３０ 域内エージェント
９４０ ＩＰ系ネットワーク
Claims (19)
- パケットサーバ（１５５）において用いられる、呼設立方法であって、
（ａ）パケットトンネルを用いて他のパケットサーバ（１３５）との間に呼を設立する必要があるかどうかを定めるステップ；と、
（ｂ）該呼に対する多数のサービスクラスを最初に相互処理決定することによって該パケットトンネルを通して該呼を設立するステップ；と、
からなることを特徴とする、パケットサーバにおいて用いられる、呼設立方法。 - 前記サービスクラスの各々が、前記呼に対する、連関するＰＰＰプロトコルのマルチクラス拡張部分に対応することを特徴とする請求項１の方法。
- 前記設立するステップ（ｂ）が、
（ｂ１）或る個数のサービスクラスのフィールド；からなるサービス品質要求メッセージであって、該個数の値が該サービス品質要求メッセージにおいて要求されるサービスクラスの個数を表すようなサービス品質要求メッセージ、を前記他のパケットサーバに送るステップ；からなる、ことを特徴とする請求項１の方法。 - 前記サービス品質要求メッセージが更に、
前記他のパケットサーバが、クラスについて、要求されたサービスクラスよりも高いサービスクラスを推薦できるようにする格上げ可能ビットを有するパラメータ；からなる、ことを特徴とする請求項３の方法。 - 前記サービス品質要求メッセージが更に、
前記他のパケットサーバがクラスについて、要求されたサービスクラスよりも低いサービスクラスを推薦できるようにする格下げ可能ビットを有するパラメータ；からなる、ことを特徴とする請求項３の方法。 - 前記サービス品質パラメータが、要求レートのフィールドと、許容バーストサイズのフィールドと、過剰バーストサイズのフィールドと、ピークレートのフィールドとを有することを特徴とする請求項３の方法。
- 前記サービス品質要求メッセージが、Ｌ２ＴＰ着信呼要求メッセージの一部であることを特徴とする請求項３の方法。
- 前記サービス品質要求メッセージが、Ｌ２ＴＰ発信呼要求メッセージの一部であることを特徴とする請求項３の方法。
- 前記サービス品質要求メッセージが、移動インターネットプロトコルに用いられる登録要求メッセージの一部であることを特徴とする請求項３の方法。
- 前記設立するステップ（ｂ）が、
（ｂ２）前記他のパケットサーバから、許諾されたサービスクラスのフィールドの情報を有するサービス品質許諾メッセージを受けるステップ；からなる、ことを特徴とする請求項１の方法。 - 前記サービス品質許諾メッセージが、許諾されたレートのフィールドと、許容バーストサイズのフィールドと、過剰バーストサイズのフィールドと、ピークレートのフィールドとを有することを特徴とする請求項１０の方法。
- 前記サービス品質許諾メッセージが、Ｌ２ＴＰ着信呼回答メッセージの一部であることを特徴とする請求項１０の方法。
- 前記サービス品質許諾メッセージが、移動インターネットプロトコルに用いられる登録回答メッセージの一部であることを特徴とする請求項１０の方法。
- 前記パケットサーバがインターネットプロトコルパケットを伝送し、
前記方法が更に、
（ｃ）前記呼に連関するユーザとマルチリンクＰＰＰプロトコル接続を最初に設立するステップ；からなり、該マルチリンクＰＰＰプロトコルがマルチクラス拡張部分を有する、ことを特徴とする請求項１の方法。 - 前記設立するステップ（ｂ）が、
（ｂ３）或る個数のクラスフィールド；からなり、該個数の値が前記マルチリンクＰＰＰプロトコルの、異なるクラスの個数に等しい、サービス品質要求メッセージ、を前記他のパケットサーバに送るステップ；からなる、ことを特徴とする請求項１４の方法。 - 前記設立するステップ（ｂ）が、
（ｂ４）或る個数のクラスフィールド；からなるＬ２ＴＰ属性値対メッセージであって、該個数の値が前記マルチリンクＰＰＰプロトコルの、異なるクラスの個数に等しいようなＬ２ＴＰ属性値対メッセージ、を前記他のパケットサーバに送るステップ；からなる、ことを特徴とする請求項１４の方法。 - 前記方法が更に、
（ｄ）異なるサービスクラスに連関するデータが同じシーケンス番号群を用いるようにしてシーケンス番号群から取られたシーケンス番号を用いて、前記他のパケットサーバにデータをパケットで伝送するステップ；からなる、ことを特徴とする請求項１の方法。 - 前記方法が更に、
（ｅ）連関する多数のサービスクラスを有するデータを運ぶための１個のデータセッションを用いて、前記他のパケットサーバにデータをパケットで伝送するステップ；からなる、ことを特徴とする請求項１の方法。 - 前記方法が更に、
（ｆ）待ち行列を各サービスクラスに割り当てるステップ；と、
（ｇ）サービスクラスのうち１つと連関するデータを運ぶパケットを受けるステップ；と、
（ｈ）前記データをそのサービスクラスに割り当てられた該待ち行列に格納するステップ；と、
からなることを特徴とする請求項１の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/285,817 US6654808B1 (en) | 1999-04-02 | 1999-04-02 | Proving quality of service in layer two tunneling protocol networks |
| US09/285817 | 1999-04-02 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000312228A JP2000312228A (ja) | 2000-11-07 |
| JP3737668B2 true JP3737668B2 (ja) | 2006-01-18 |
Family
ID=23095822
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000101549A Expired - Fee Related JP3737668B2 (ja) | 1999-04-02 | 2000-04-03 | パケットサーバにおける呼設立方法 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6654808B1 (ja) |
| EP (1) | EP1041792B8 (ja) |
| JP (1) | JP3737668B2 (ja) |
| AT (1) | ATE492095T1 (ja) |
| CA (1) | CA2300758C (ja) |
| DE (1) | DE60045355D1 (ja) |
Families Citing this family (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10511573B2 (en) * | 1998-10-30 | 2019-12-17 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
| US7194554B1 (en) | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
| US8266266B2 (en) | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
| US8713641B1 (en) | 1998-12-08 | 2014-04-29 | Nomadix, Inc. | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device |
| US6577644B1 (en) * | 1999-06-22 | 2003-06-10 | Lucent Technologies Inc. | Quality of service (QoS) enhancement to multilink point-to-point protocol (PPP) |
| US6922404B1 (en) * | 1999-10-14 | 2005-07-26 | Nortel Networks Limited | Mobile IP extensions rationalization (MIER) |
| WO2001031861A1 (en) * | 1999-10-22 | 2001-05-03 | Nomadix, Inc. | Systems and methods for dynamic bandwidth management on a per subscriber basis in a communications network |
| US6853621B1 (en) * | 2000-01-18 | 2005-02-08 | Go2Call.Com, Inc. | System and method for selecting a packet-switched telephony service provider |
| JP3855595B2 (ja) * | 2000-04-25 | 2006-12-13 | 株式会社日立製作所 | 通信システム、通信方法及び通信装置 |
| US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
| JP2002057698A (ja) * | 2000-08-09 | 2002-02-22 | Fujitsu Ltd | パケットデータ処理装置 |
| US7054321B1 (en) * | 2000-10-27 | 2006-05-30 | Redback Networks Inc. | Tunneling ethernet |
| US20020062379A1 (en) * | 2000-11-06 | 2002-05-23 | Widegren Ina B. | Method and apparatus for coordinating quality of service requirements for media flows in a multimedia session with IP bearer services |
| US20020085563A1 (en) * | 2001-01-03 | 2002-07-04 | Michael Mesh | Packet processing method and engine |
| KR100387044B1 (ko) * | 2001-02-01 | 2003-06-12 | 삼성전자주식회사 | 무선통신 시스템에서 패킷 호 서비스의 제공방법 |
| US6950862B1 (en) * | 2001-05-07 | 2005-09-27 | 3Com Corporation | System and method for offloading a computational service on a point-to-point communication link |
| US6816890B2 (en) * | 2001-05-28 | 2004-11-09 | Hitachi, Ltd. | Gateway apparatus with LAC function |
| US7339908B2 (en) * | 2001-07-31 | 2008-03-04 | Arraycomm, Llc. | System and related methods to facilitate delivery of enhanced data services in a mobile wireless communications environment |
| US7363376B2 (en) * | 2001-07-31 | 2008-04-22 | Arraycomm Llc | Method and apparatus for generating an identifier to facilitate delivery of enhanced data services in a mobile computing environment |
| US7225236B1 (en) * | 2001-08-07 | 2007-05-29 | 3Com Corporation | Load balancing between LNSs using virtual LNS with minimal LAC configuration |
| JP3831656B2 (ja) * | 2001-12-05 | 2006-10-11 | 株式会社日立製作所 | ネットワーク接続装置およびネットワーク接続方法 |
| KR100834671B1 (ko) * | 2002-01-18 | 2008-06-02 | 삼성전자주식회사 | 이동통신시스템의 데이터 서비스 방법 |
| KR100438431B1 (ko) * | 2002-02-23 | 2004-07-03 | 삼성전자주식회사 | 통신 네트워크에서 가상 사설 네트워크 서비스 접속을위한 보안 시스템 및 방법 |
| US7272122B2 (en) * | 2002-04-26 | 2007-09-18 | Nokia Corporation | Relocation of application-specific functionality during seamless network layer-level handoffs |
| US7224673B1 (en) * | 2002-05-24 | 2007-05-29 | Cisco Technology, Inc. | Mobile IP registration message compression |
| CN1757210A (zh) * | 2003-01-15 | 2006-04-05 | 希尔纳公司 | 用于在光网络上传输分组数据的方法和装置 |
| US7024687B2 (en) * | 2003-05-21 | 2006-04-04 | Cisco Technology, Inc. | System and method for providing end to end authentication in a network environment |
| US7724700B1 (en) * | 2003-08-25 | 2010-05-25 | Cisco Technology, Inc. | Application server-centric quality of service management in network communications |
| US20060171365A1 (en) * | 2005-02-02 | 2006-08-03 | Utstarcom, Inc. | Method and apparatus for L2TP dialout and tunnel switching |
| US7797427B2 (en) * | 2005-12-13 | 2010-09-14 | Cisco Technology, Inc. | System and method for applying a communication feature extension |
| US20080240053A1 (en) * | 2007-03-27 | 2008-10-02 | Oswal Anand K | Quality of service (QoS) negotiation between network nodes in a Mobile IP network |
| US8310924B2 (en) * | 2008-05-15 | 2012-11-13 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for providing QoS for MP subscribers at the subscriber level |
| WO2010121204A1 (en) * | 2009-04-17 | 2010-10-21 | Research In Motion Limited | Mechanisms for evolved packet system quality of service class identifier extension |
| JP4802263B2 (ja) * | 2009-07-17 | 2011-10-26 | 株式会社日立製作所 | 暗号化通信システム及びゲートウェイ装置 |
| AU2012207471B2 (en) | 2011-01-18 | 2016-07-28 | Nomadix, Inc. | Systems and methods for group bandwidth management in a communication systems network |
| CN103701710B (zh) | 2013-12-20 | 2017-01-11 | 杭州华为数字技术有限公司 | 一种数据传输方法、核心转发设备以及端点转发设备 |
| CN117042056A (zh) * | 2017-10-26 | 2023-11-10 | 华为技术有限公司 | 服务质量协商技术 |
| CN114615107A (zh) * | 2020-11-23 | 2022-06-10 | 华为技术有限公司 | 建立通信的方法及装置 |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ZA946674B (en) * | 1993-09-08 | 1995-05-02 | Qualcomm Inc | Method and apparatus for determining the transmission data rate in a multi-user communication system |
| US5674003A (en) * | 1995-04-28 | 1997-10-07 | Andersen; David B. | Mechanisms for accessing unique features of telephony networks from a protocol-Independent data transport interface |
| US5917822A (en) * | 1995-11-15 | 1999-06-29 | Xerox Corporation | Method for providing integrated packet services over a shared-media network |
| US6223028B1 (en) * | 1997-03-17 | 2001-04-24 | Nortel Networks Ltd | Enhanced method and system for programming a mobile telephone over the air within a mobile telephone communication network |
| US6137791A (en) * | 1997-03-25 | 2000-10-24 | Ericsson Telefon Ab L M | Communicating packet data with a mobile station roaming within an incompatible mobile network |
| US5914950A (en) * | 1997-04-08 | 1999-06-22 | Qualcomm Incorporated | Method and apparatus for reverse link rate scheduling |
| US5940390A (en) * | 1997-04-10 | 1999-08-17 | Cisco Technology, Inc. | Mechanism for conveying data prioritization information among heterogeneous nodes of a computer network |
| US6339595B1 (en) * | 1997-12-23 | 2002-01-15 | Cisco Technology, Inc. | Peer-model support for virtual private networks with potentially overlapping addresses |
| US6223222B1 (en) * | 1998-05-14 | 2001-04-24 | 3Com Corporation | Method and system for providing quality-of-service in a data-over-cable system using configuration protocol messaging |
| US6154778A (en) * | 1998-05-19 | 2000-11-28 | Hewlett-Packard Company | Utility-based multi-category quality-of-service negotiation in distributed systems |
| US6167028A (en) * | 1998-06-01 | 2000-12-26 | Motorola, Inc. | Methods and apparatus for facilitating transmission of cells having multiple priorities in a cell relay network |
| US6157955A (en) * | 1998-06-15 | 2000-12-05 | Intel Corporation | Packet processing system including a policy engine having a classification unit |
| US6094437A (en) * | 1998-10-09 | 2000-07-25 | Asc - Advanced Switching Communications | Layer two tunneling protocol (L2TP) merging and management |
-
1999
- 1999-04-02 US US09/285,817 patent/US6654808B1/en not_active Expired - Lifetime
-
2000
- 2000-03-16 CA CA002300758A patent/CA2300758C/en not_active Expired - Fee Related
- 2000-03-22 EP EP00302358A patent/EP1041792B8/en not_active Expired - Lifetime
- 2000-03-22 DE DE60045355T patent/DE60045355D1/de not_active Expired - Lifetime
- 2000-03-22 AT AT00302358T patent/ATE492095T1/de not_active IP Right Cessation
- 2000-04-03 JP JP2000101549A patent/JP3737668B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP1041792B1 (en) | 2010-12-15 |
| US6654808B1 (en) | 2003-11-25 |
| EP1041792B8 (en) | 2011-02-16 |
| EP1041792A2 (en) | 2000-10-04 |
| JP2000312228A (ja) | 2000-11-07 |
| CA2300758C (en) | 2004-06-29 |
| ATE492095T1 (de) | 2011-01-15 |
| EP1041792A3 (en) | 2004-07-14 |
| DE60045355D1 (de) | 2011-01-27 |
| CA2300758A1 (en) | 2000-10-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3737668B2 (ja) | パケットサーバにおける呼設立方法 | |
| EP2033451B1 (en) | Qos-aware service flow mapping in mobile wireless all ip networks | |
| US7225259B2 (en) | Service tunnel over a connectionless network | |
| JP4550879B2 (ja) | モバイルＩＰネットワークにおけるポリシーに基づくＵＭＴＳのＱｏＳとＩＰのＱｏＳ管理のためのメカニズム | |
| US8942168B2 (en) | Packet flow processing in a communication system | |
| US8514773B2 (en) | Packet flow processing in a communication system | |
| EP1250787B1 (en) | Rsvp handling in 3g networks | |
| US7701963B2 (en) | Method and apparatus for the use of micro-tunnels in a communications system | |
| US6819652B1 (en) | Method and apparatus for processing control messages in a communications system | |
| TWI271065B (en) | Method, devices and system for flow-based selective reverse tunneling in wireless local area network (WLAN)-cellular systems | |
| US20020122432A1 (en) | Method and apparatus for communicating data based on a plurality of traffic classes | |
| WO2019033920A1 (zh) | 网络侧对远端用户设备的识别和控制方法以及设备 | |
| CN105765919A (zh) | 用于传输和接收包的方法和系统 | |
| KR20030027067A (ko) | 무선 통신 네트워크에서 베어러 인가를 위한 방법 및 시스템 | |
| KR20000076720A (ko) | 패킷 서버 내에서의 이용 방법 | |
| JP2007521693A (ja) | 無線ローカルエリアネットワークにおけるサービス品質制御 | |
| Manner | Provision of Quality of Service in IP-based Mobile Access Networks | |
| Bhagavathula et al. | Mobility and Layer 2 Tunnels | |
| Bajpai | Intra-domain QOS provisioning in mobile IP-based networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050902 |
|
| 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: 20051005 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051027 |
|
| 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: 20091104 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091104 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101104 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111104 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121104 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131104 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |