JP4087559B2

JP4087559B2 - 非同期伝送モードの適合レイヤ２を用いたインターネットプロトコルパケットの効率的な転送

Info

Publication number: JP4087559B2
Application number: JP2000513441A
Authority: JP
Inventors: ラルスウェストベルイ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 1997-09-24
Filing date: 1998-09-22
Publication date: 2008-05-21
Anticipated expiration: 2018-09-22
Also published as: AU9289698A; RU2208303C2; AU744170B2; KR100568651B1; CA2304652A1; BR9812533A; EP1018286A1; CN1279876A; CN1192678C; CA2304652C; EP1018286B1; JP2001517915A; KR20010024281A; WO1999016284A1; DE69832511D1; US6041054A; DE69832511T2

Description

【０００１】
背景
本発明は単一のＡＴＭ接続についての非同期転送モード（ＡＴＭ）とインターネットプロトコル（ＩＰ）データパケットの伝送に関するものである。特に、本発明は、ＡＴＭ適合レイヤ２（ＡＬＬ２）とヘッダ圧縮技術とを採用し、ネットワーク環境における単一ＡＴＭ接続でのマルチプロトコルインターネットデータをより効率的に転送することに関するものである。
【０００２】
ＡＴＭは非同期で通信データを送信するための標準的なプロトコルである。このプロトコルはＡＴＭセルとして知られている固定サイズのデータパケットでのデータ伝送に基づいている。各ＡＴＭセルは４８オクテットのペイロード部と５オクテットのヘッダ部とを有する単一のフォーマットをもつという特徴がある。ＡＴＭは公知の従来技術である。
【０００３】
残念なことに、ＡＴＭは低ビットレートのデータを効率的に伝送しない。典型的な低ビットレートのデータパケット長は４８オクテット（即ち、ＡＴＭセルペイロード長）よりかなり短いという理由がある。ＡＴＭセルペイロードのどの未使用部分も“パッディグビット”で埋められる。データよりむしろパッディグビットが挿入されるならば、バンド幅は無駄になる。また、パッディグビットを挿入することにより、特に、伝送されるデータが遅延に対して非常に敏感である場合、例えば、音声タイプのデータの場合、受容できない、有害ともなりえるかもしれない伝送遅延が生じることも理解されよう。
【０００４】
最近になって、ＡＡＬ２として知られているＡＴＭ適合レイヤが開発された。ＡＡＬ２は、低ビットデータを伝送するために用いられるとき、特に、ＡＴＭ効率を改善するためのものである。図２において、ＡＡＬ２は、（しばしば、マイクロセル或いはショートパケットとして言及される）ミニセルと呼ばれる小さな、可変長のデータパケット、例えば、ミニセル２０５に低ビットレートデータを格納することにより動作する。バンド幅利用の改善が、いくつかのミニセルを、例えば、ＡＴＭセル２１０のような単一のＡＴＭセルのペイロードに挿入することにより達成される。さらにバンド幅の利用を改善にするために、例えば、ミニセル２１５のようなミニセルがセグメントに分割され、それは図示されているように２つのＡＴＭセルにオーバラップする。
【０００５】
図３はＡＡＬ２ミニセル３０１についての公知のプロトコルを図示している。ミニセル３０１は３バイトのヘッダ３０２とペイロード３０３とに分割される。一般に、そのヘッダは次のフィールド、即ち、回路（チャネル）識別子（ＣＩＤ）３０４、長さコード３０５、循環冗長コード（ＣＲＣ）コード３０６、ユーザ対ユーザ情報（ＵＵＩ）フィールド３０７に分割される。ＣＩＤ３０４は、いくつかのチャネルを多重化するとき、各ミニセルを対応するチャネルに関連させるのに必要な情報を備える。長さコード３０５は各ミニセルの最初と最後のオクテットの場所を決定するのに必要な情報を備える。ＣＲＣ３０６はミニセル３０１についての完全性チェックを備え、ＵＵＩフィールド３０７はミニセルの切り分け処理に関連して用いられる。
【０００６】
ＡＴＭは一般にはネットワーク環境においてある地点からある地点へとデータを転送するためのベアラとして用いられることが従来から知られている。典型的には、伝送されるデータパケットは初めには数多くの異なるインターネットプロトコル（ＩＰｓ）のいずれか１つに従ってフォーマットされる。そのようなＩＰの例には、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、リアルタイム転送プロトコル（ＲＴＰ）が含まれる。
【０００７】
従来より、これらＩＰデータパケットはさらに、ポイント−ツウ−ポイントプロトコル（ＰＰＰ）に従ってフォーマットされる。ＰＰＰを用いる主たる目的は、ＰＰＰがポイント−ツウ−ポイントリンクについてのマルチプロトコルデータパケットについての標準フォーマットを備える点にある。ＰＰＰは、図４に図示されているように、異なるＩＰデータパケットタイプをカプセルに包み込むことによって、これを成し遂げる。
【０００８】
図４に図示されたカプセル包み込みモデル４００は、いくつかのデータフィールドを含んでいる。ＰＰＰプロトコルＩＤフィールド４０５は一般に２オクテットの長さをもっており、それは、情報フィールド４１０に現れるＩＰデータパケットのタイプを識別する。例えば、ＰＰＰプロトコルＩＤフィールド４０５は、ＲＴＰデータパケット、ＵＤＰデータパケット、或いは、ＴＣＰデータパケットとしてＩＰデータパケット（不図示）を識別しても良い。加えて、ＰＰＰプロトコルＩＤフィールド４０５は、そのＩＰデータパケットに関連したヘッダが圧縮されているのか、或いは、非圧縮であるのかを確証する。カプセル包み込みモデル４００はまた、多数のパッデングビット４１５を含んでも良い。
【０００９】
図５は、典型的なＩＰ／ＰＰＰデータパケットヘッダ５００、特に、ＴＣＰデータパケットヘッダを図示している。バンド幅の利用と伝送効率を改善するために、従来から良く知られているように、ＩＰ／ＰＰＰデータパケットのヘッダを圧縮することは実際によくなされてきたことである。ヘッダ圧縮は、ＩＰ／ＰＰＰヘッダ、例えば、ＩＰ／ＰＰＰデータパケットヘッダ５００におけるかなりの数のデータフィールドはセッション或いはコネクションの間ずっと、定数に留まっているという事実に基づいている。例えば、図６は、定数に留まっているＩＰ／ＰＰＰデータパケットヘッダ５００におけるデータフィールドを図示している。従って、フルヘッダは、そのセッション／コネクションが最初に確立されたときに送信されても良い。フルヘッダを最初に送信することにより、伸長器は、そのセッション／コネクションの残りの時間、圧縮ヘッダを収容するように構成できる。これ以後、変化するフィールドだけが伝送される必要がある。事実、この分野ではよく理解されているように、さらに周期的に変化したり、或いは、一定の値だけ変化するフィールドを利用することにより、ＩＰ／ＰＰＰデータパケットのヘッダをさらに圧縮することさえも可能である。定数として留まったり、周期的に変化したり、或いは、一定の値だけ変化する特定のデータフィールドは、ＩＰ／ＰＰＰデータパケットのタイプに依存している。
【００１０】
しばしば、ネットワークは１つ以上のタイプのアプリケーションのサービスを行う。そこでは、各アプリケーションはユニークなデータ転送フォーマットをその特徴としてもつデータを生成する。ＡＴＭを採用するために、異なるデータ転送フォーマット夫々が再フォーマットされ（即ち、適合され）、ＡＴＭフォーマットに準拠しなければならない。これは、いくつかのＡＴＭ適合レイヤ（ＡＡＬｓ）の１つ、例えば、図１に図示されているＡＡＬ１０１によって成し遂げられ、そこでは、アプリケーションレイヤ１０２が特定のアプリケーションから到着するデータ（例えば、インターネットプロトコルデータ）を表現する。即ち、ＡＡＬ１０１は１つ以上のＡＴＭセルのペイロード部にそのアプリケーションデータを格納する。ＡＴＭレイヤ１０３はそれから、１つ以上のＡＴＭセルをネットワークの受信地点に送信する。
【００１１】
いくつかの良く知られたＡＡＬがある。最も広く使用されているＡＡＬの２つとは、ＡＡＬ１とＡＡＬ５である。ＡＡＬ１は同期データ（即ち、回路エミュレーションデータ）を伝送するのに用いられる。一方、ＡＡＬ５はパケットデータ、例えば、ＩＰパケットデータを伝送するのに用いられる。
【００１２】
ＩＰ／ＰＰＰデータパケットについてのベアラとしてＡＴＭを採用するネットワークにおいて、ＡＡＬ５は用いられるＡＴＭ適合レイヤである。各ＩＰ／ＰＰＰデータパケットのパケット長が通常は、ＡＴＭセルの長さ、或いは、より具体的にはＡＴＭセルのペイロード長とは同等ではないのであるから、ＡＴＭセルのペイロードの未使用部は、ＩＰ／ＰＰＰパケットがそこに挿入された後に、パッドされなければならない。上述のように、ＡＴＭセルをパッディングすることやデータで完全に埋められてはいないＡＴＭセルを送信することはバンド幅の利用効率を極端に悪いものにし、ＩＰ／ＰＰＰデータパケットのヘッダを圧縮することにより達成される付加的な効率改善に対して反対の作用をする効果となる。従って、ＡＴＭをベアラとして用いるときに、ＩＰ／ＰＰＰデータパケットを伝送するのにより効率的な方法を提供することが本当に必要である。
【００１３】
要約
本発明の目的は、ＡＴＭを用いたＩＰ／ＰＰＰデータパケットを伝送する、よりバンド幅効率の良い技術を提供することである。
【００１４】
また、本発明の別の目的は、短い、或いは、可変長のデータパケットを伝送するためにより適しているＡＡＬ２を採用することによって、バンド幅効率を改善してＩＰ／ＰＰＰデータパケットを伝送することである。
【００１５】
さらに、本発明の別の目的は、ＡＡＬ２とともにヘッダ圧縮技術を採用してオーバヘッドを低減し、さらにバンド幅効率を改善することである。
【００１６】
本発明の１つの側面に従えば、上述の、また、他の目的は、ネットワーク環境におけるインターネットプロトコルデータパケットを伝送する方法によって達成される。その方法は、ルックアップテーブルのある場所にインターネットプロトコルデータパケットの一部を格納し、それから、ＡＡＬ２ミニセルヘッダの一部にアドレスを挿入することにより、そのインターネットプロトコルデータパケットのヘッダの一部をマッピングすることを含んでいる。ここで、そのアドレスは、そのインターネットプロトコルデータパケットのヘッダの一部が格納されたルックアップテーブルに対応している。そのとき、そのインターネットプロトコルデータパケットの残りの部分はＡＡＬ２ミニセルのペイロード部に挿入され、次に、ネットワークの受信地点に送信される。その受信地点では、ＡＡＬ２ミニセルヘッダに挿入されたアドレスが解析され、ＡＡＬ２ミニセルヘッダのアドレスに基づいて、ルックアップテーブルに格納されたインターネットプロトコルデータパケットのヘッダの一部が取り出される。
【００１７】
本発明の別の側面に従えば、上述の、また、他の目的は、ＡＡＬ２コネクションでインターネットプロトコルデータパケットを伝送する方法によって達成される。その方法は、ポイント−ツウ−ポイントのプロトコルを用いて、インターネットプロトコルデータパケットをカプセルに包むことが含まれる。ここで、インターネットプロトコルデータパケットはヘッダ部を含む。それから、その方法は、そのインターネットプロトコルデータパケットのヘッダのデータフィールドに関連したデータがルックアップテーブルに以前に格納されていたかどうかを判断する。もし、そのデータがルックアップテーブルに以前に格納されていたならば、インターネットプロトコルデータパケットのヘッダからそのデータフィールドを省略し、ＡＡＬ２ミニセルヘッダのデータフィールドにアドレスを挿入する。ここで、そのアドレスは、ルックアップテーブルに以前に格納されたデータの位置に対応する。それから、カプセルに包まれたインターネットプロトコルデータパケットはＡＡＬ２ミニセルのペイロード部に挿入され、それは次に、ネットワークの受信地点に送信される。その受信地点では、ＡＡＬ２ミニセルヘッダのデータフィールドに格納されたアドレスに従って、そのルックアップテーブルからインターネットプロトコルデータパケットのヘッダのデータフィールドに関連したデータが取り出される。
【００１８】
本発明のさらに別の側面に従えば、上述の、また、他の目的は、ネットワーク環境におけるＡＡＬ２ミニセルで、ポイント−ツウ−ポイントのプロトコルで、カプセルに包まれたインターネットプロトコルデータパケットを伝送する方法によって達成される。その方法は、まず、そのインターネットプロトコルデータパケットのヘッダが圧縮形式にあるかどうかの判断を含み、もし、そのインターネットプロトコルデータパケットのヘッダが圧縮されていたならば、ＡＡＬ２ミニセルヘッダの第１データフィールドに格納されたアドレスを用いて、以前に第１のルックアップテーブルに格納されたインターネットプロトコルデータパケットのヘッダの第１データフィールドに関連したデータをマップする。次に、その方法は、ＡＡＬ２ミニセルがセグメントに分割されるべきかどうかを判断し、もし、ＡＡＬ２ミニセルがセグメントに分割されるべきであるなら、ＡＡＬ２ミニセルヘッダの第２の部分に格納されたアドレスを用いて、以前に第２のルックアップテーブルに格納されたインターネットプロトコルデータパケットの第２データフィールドに関連したデータをマップする。ついに、ＡＡＬ２ミニセルはネットワークにおける受信地点に送信され、そのＡＡＬ２ミニセルヘッダの第１の部分に格納されたアドレスに基づいて、第１のルックアップテーブルから、インターネットプロトコルデータパケットのヘッダの第１データフィールドに関連したデータが取り出され、そして、そのＡＡＬ２ミニセルヘッダの第２の部分に格納されたアドレスに基づいて、第２のルックアップテーブルから、インターネットプロトコルデータパケットの第２データフィールドに関連したデータが取り出される。
【００１９】
本発明のまたさらに別の側面に従えば、上述の、また、他の目的は、ネットワーク環境におけるＡＡＬ２ミニセルでインターネットプロトコルデータパケットを伝送する方法によって達成される。ここで、そのインターネットプロトコルデータパケットはヘッダ部を含んでいる。まず、その方法では、第１のインターネットプロトコルデータパケットのヘッダ部のセッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが以前にルックアップテーブルに格納されたものであるかどうかを判断する。もし、それが以前にそのルックアップテーブルに格納されたものではないなら、その方法によれば、第１のＡＡＬ２ミニセルのペイロード部に、インターネットプロトコルデータパケットのフルヘッダを挿入する。加えて、未使用のルックアップテーブルアドレスが、ＡＡＬ２ミニセルのヘッダ部に関連したデータフィールドに挿入される。それから、第１のＡＡＬ２ミニセルがネットワークにおける送信地点から受信地点に送信される。その受信地点では、ＡＡＬ２ミニセルヘッダに関連したデータフィールドの未使用アドレスに従って、ルックアップテーブルに、そのセッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが格納される。次に、その方法によれば、第２のインターネットプロトコルデータパケットのヘッダ部のセッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが以前にそのルックアップテーブルに格納されたものであるかどうかを判断する。もし、第２のインターネットプロトコルデータパケットのヘッダのセッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが以前に格納されたものであるなら、第２のＡＡＬ２ミニセルのヘッダ部のデータフィールドに、この以前に格納されたデータに関連したルックアップテーブルのアドレスが挿入される。それから、そのセッションコンテキスト／コネクション識別子のデータフィールドを除く第２のインターネットプロトコルデータパケットのヘッダの残りの部分が第２のＡＡＬ２ミニセルのペイロード部に挿入され、次に、これが受信地点に送信される。第２のＡＡＬ２ミニセルヘッダのデータフィールドに格納されたアドレスに基づいて、第２のインターネットプロトコルデータパケットのヘッダのセッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが、ルックアップテーブルから取り出される。
【００２０】
詳細な説明
本発明は、ここでは、ＩＰ／ＰＰＰデータパケットとして言及されるポイント−ツウ−ポイントプロトコル（ＰＰＰ）でカプセルとして包み込まれたインターネットプロトコル（ＩＰ）データパケットを伝送することを含んでいる。リアルタイム伝送プロトコル（ＲＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、伝送制御プロトコル（ＴＣＰ）を含む、この技術分野では知られているいくつかの異なるインターネットプロトコルがある。その技術分野ではＡＴＭ、より厳密にはＡＡＬ５を用いてネットワーク環境においてＩＰ／ＰＰＰデータパケットを伝送することが良く知られている。
【００２１】
一般に、本発明では、ＡＡＬ５に従うＡＴＭセルではなく、むしろ、ＩＰ／ＰＰＰデータパケットを転送するためにＡＴＭ適合レイヤタイプ２（ＡＡＬ２）のミニセルを採用する。ＡＡＬ２は特に、短いパケットの低ビットレートデータに関するバンド幅利用を改善するために設計されている。従って、できる限り短いＩＰ／ＰＰＰデータパケットを維持することが本発明における主たる関心事である。それゆえに、本発明は現存するＩＰ／ＰＰＰヘッダ圧縮技術を利用して、可能であるならいつでも、望まれないオーバヘッドを低減する。加えて、本発明はＡＡＬ２ミニセルヘッダにおけるデータフィールドを用いてＩＰ／ＰＰＰデータパケットヘッダにあるデータフィールドをマップする。ＩＰ／ＰＰＰデータパケットヘッダに情報をマッピングすることにより、ＩＰ／ＰＰＰデータパケットのオーバヘッドはさらに低減され、これによって、さらに、バンド幅利用と伝送効率を改善している。
【００２２】
図７は典型的なＩＰ／ＰＰＰデータパケット７００を図示している。ＩＰ／ＰＰＰデータパケット７００はＩＰデータを含むペイロード部７０５を含み、そのパケットはＩＰ／ＰＰＰデータパケットヘッダ７１５とＰＰＰプロトコル識別子（ＩＤ）７２０とを有するオーバヘッド部７１０を含んでいる。図７に図示されたＩＰ／ＰＰＰデータパケットヘッダ７１５はフルの、非圧縮のヘッダである。そういうものとして、ＩＰデータパケットタイプ（例えば、ＴＣＰ、ＲＴＰ、ＵＤＰ）に依存して、ＰＰＰプロトコルＩＤ７２０で定義されるように、そのヘッダは４０バイト以上の情報を含んでも良い。
【００２３】
これとは反対に、図８は圧縮ヘッダ８０５を含むＩＰ／ＰＰＰデータパケット８００を図示している。圧縮ヘッダ８０５の具体的な内容は、もしそうでなければフルヘッダを圧縮するために用いられる圧縮アルゴリズムと、ＰＰＰプロトコルＩＤ８１０によって定義されるＩＰデータパケットタイプに依存している。ＴＣＰヘッダについての代表的な圧縮アルゴリズムは、ヤコブソン（Jacobson）著、“低速シリアルリンクでのＴＣＰ／ＩＰヘッダの圧縮（Compressing TCP/IP Headers for Low-Speed Serial Links）”、ネットワークワーキンググループＲＦＣ１１４４（１９９０）で十分に説明されている。ＵＤＰとＲＴＰヘッダについての他の代表的な圧縮アルゴリズムは、カスナ他（Casner et al.）著、“低速シリアルリンクでのＩＰ／ＵＤＰ／ＲＴＰヘッダの圧縮（Compressing IP/UDP/RTP Headers for Low-Speed Serial Links）”、インターネットエンジニアリングタスクフォース（１９９７）で説明されている。
【００２４】
本発明の好適な実施形態に従えば、１つ以上のセッションに関連したＩＰ／ＰＰＰデータパケットは、それらは圧縮ヘッダを含むかどうかに係りなく、ＡＡＬ２ミニセルのペイロード部に挿入される。ＡＡＬミニセルは、それから、ネットワーク内の送信地点からそのネットワーク内の受信地点に送信される。
【００２５】
図８はまた、例えば、ＩＰ／ＰＰＰデータパケットヘッダ８０５のような、圧縮されたＩＰ／ＰＰＰデータパケットヘッダを一般的には有するデータフィールドを図示している。そのデータフィールドはセッションのコンテキスト或いはコネクションの識別子（ＩＤ）８５０を含んでいる。ここで、その識別子はセッションコンテキスト／コネクションＩＤとして言及されている。このデータフィールドが１つのセッション或いは１つのコネクションに属しているかどうかは、カプセルとして包まれたＩＰデータパケットがＵＤＰ／ＲＴＰデータパケットであるか、或いは、ＴＣＰデータパケットであるかに依存する。セッションコンテキスト／コネクションＩＤ８５０は、ソース／宛て先、或いは、コネクション／フローの情報を含んでおり、当業者であればすぐに理解できるように、ここでは、与えられたセッション／コネクションに関連した各ＩＰ／ＰＰＰデータパケットについてのソース／宛て先／コネクション／フローの情報は同じである。別のデータフィールドは圧縮ヘッダ制御８５５である。このデータフィールドは、一般に１つのＩＰ／ＰＰＰデータパケットから次のパケットへと一定の量（即ち、最初のオーダの変化）だけ変化するデータパケットシーケンスカウントと、圧縮ヘッダデータフィールド８６０の内容を識別するためのビットマスクとを含んでいる。
【００２６】
本発明の好適な実施形態に従えば、図３に図示されているように、ＡＡＬ２ミニセルのヘッダのあるデータフィールドは、ＰＰＰプロトコルＩＤ８１０とセッションコンテキスト／コネクションＩＤ８５０とをマッピングするために用いられても良い。特に、ＰＰＰプロトコルＩＤ８１０はユーザ対ユーザ情報（ＵＵＩ）フィールドにマップされる一方、セッションコンテキスト／コネクションＩＤはチャネル識別（ＣＩＤ）フィールド３０４にマップされても良い。その結果、セッションコンテキスト／コネクションＩＤ８５０に関連したソース／宛て先／コネクション／フローの情報は、ＩＰ／ＰＰＰデータパケットヘッダの一部として、対応するセッション／コネクションに関連した各ＩＰ／ＰＰＰデータパケット毎にそのパケットとともに送信される必要はない。同様に、ＰＰＰプロトコルＩＤ８１０情報も、そのセッション／コネクションに関連した各ＩＰ／ＰＰＰデータパケットとともに送信される必要はない。圧縮されたＩＰ／ＰＰＰデータパケットのヘッダの一部として、各ＩＰ／ＰＰＰデータパケットとともに再送信するのではなくむしろ、セッションコンテキスト／コネクションＩＤ８５０とＰＰＰプロトコルＩＤ８１０情報を夫々、ＣＩＤ３０４とＵＵＩ３０７のフィールドにマッピングすることにより、オーバヘッドはかなり低減される。数１０個の、もしそうではないなら、数１００個のＩＰ／ＰＰＰデータパケットがそのセッション／コネクションの間中ずっと送信されることになっているなら、特に、そう言える。
【００２７】
さらに、本発明の好適な実施形態に従えば、セッションコンテキスト／コネクションＩＤ８５０をＣＩＤフィールド３０４にマッピングすることは、受信地点におけるヘッダの伸長器内或いはこれに随伴して維持されるルックアップテーブルを用いて実施しても良い。例えば、各ＣＩＤコードの組み合わせがそのルックアップテーブルの特定のエントリ／アドレスを定義しても良い。もし、セッションコンテキスト／コネクションＩＤ８５０に関連したソース／宛て先／コネクション／フロー情報が、そのルックアップテーブルに以前に格納されていたなら、送信地点に位置した圧縮器での圧縮アルゴリズムは、ＡＡＬ２ミニセルが送信地点から受信地点へと送信される前に、ただ対応するアドレス或いはその一部をＡＡＬ２ミニセルヘッダのＣＩＤフィールド３０４へとコピーすることが必要なだけである。受信地点では、伸長アルゴリズムによってＣＩＤフィールド３０４を解析し、ＣＩＤフィールド３０４に格納されたアドレスに従ってルックアップテーブルをアクセスすることにより、そのルックアップテーブルからソース／宛て先／コネクション／フロー情報を取り出す。
【００２８】
もし、そのソース／宛て先／コネクション／フロー情報がルックアップテーブルに以前には格納されていなかったなら、例えば、対応するＩＰ／ＰＰＰデータパケットが与えられたセッション／コネクションに関連した一連のＩＰ／ＰＰＰデータパケットの最初のものであるなら、圧縮アルゴリズムによってルックアップテーブルの未使用のエントリを識別する。それから、その圧縮アルゴリズムは対応するＡＡＬ２ミニセルのＣＩＤデータフィールド３０４に未使用のルックアップテーブルのエントリのアドレスを挿入する。セッションコンテキスト／コネクションＩＤ８５０に関連したソース／宛て先／コネクション／フロー情報を含むフルヘッダが、そっくりそのまま、ＡＡＬ２ミニセルのペイロードへと挿入され、それから、受信地点へと転送される。伸長アルゴリズムではこのＩＰ／ＰＰＰデータパケットが新しいセッション／コネクションを開始していることを認識する。従って、その伸長アルゴリズムでは、そのとき、ＣＩＤフィールド３０４に格納された圧縮アルゴリズムのアドレスに基づいて、以前には格納されていなかったソース／宛て先／コネクション／フロー情報をルックアップテーブルに格納する。その後、同じセッション／コネクションに関連した送信されたＩＰ／ＰＰＰデータパケットは、ソース／宛て先／コネクション／フロー情報よりむしろ、ただ、対応するＡＡＬ２ミニセルヘッダのＣＩＤフィールド３０４におけるルックアップテーブルのアドレスを運ぶことが必要なだけである。
【００２９】
もし、与えられたセッション／コネクションに関連したＩＰ／ＰＰＰデータパケットが非圧縮のヘッダを含むなら、ルックアップテーブルにソース／宛て先／コネクション／フロー情報を格納する必要はない。従って、圧縮アルゴリズムではＣＩＤフィールド３０４にデフォルトコードを格納しても良い。そのデフォルトコードによって伸長アルゴリズムが、フルで非圧縮のＩＰ／ＰＰＰデータパケットヘッダを含むデータパケットとして、ＩＰ／ＰＰＰデータパケットを認識することを可能にしている。
【００３０】
従来から、ＣＩＤフィールド３０４は８ビットの長さをもっている。それゆえに、ＣＩＤフィールド３０４はルックアップテーブルに２５６個の異なるエントリをマップできる。それゆえ、２５６個の異なるセッション／コネクションが単一のＡＡＬ２リンクに多重化される。しかしながら、夫々が８ビットのＣＩＤフィールドを含んだ２つ以上のパラレルリンクを採用することも可能である。従って、２つの８ビットＣＩＤフィールドによってルックアップテーブルに６４Ｋ（即ち、６５５３６）個の異なるエントリをマップできる。それゆえに、６４Ｋ個の異なるセッション／コネクションが、２つのパラレルＡＡＬ２リンクに多重化される。また、２つ以上のパラレルリンクを採用することもできる。ここで、８ビットのＣＩＤコードは、下位側或いは最下位のアドレスバイトを反映している。一方、ＡＴＭセルヘッダの仮想パスインジケータ（ＶＰＩ）コードと結合した仮想チャネルコネクション（ＶＣＣ）コードは、上位側或いは最上位のアドレスバイトを反映している。この場合、少なくとも６４Ｋ個の異なるセッション／コネクションは２５６個のパラレルＡＡＬ２リンクに多重化される。
【００３１】
本発明に好適な実施形態に従えば、ＰＰＰプロトコルＩＤ８１０を対応するＡＡＬ２ミニセルヘッダのＵＵＩフィールド３０７にマッピングすることは、上述したようなセッションコンテキスト／コネクションＩＤ８５０と類似の方法で実施される。従って、もし、ＰＰＰプロトコルＩＤ８１０が伝送され、そして、受信地点の伸長器内或いはそれに随伴して維持されるＵＵＩルックアップテーブルに格納されるなら、圧縮アルゴリズムは、ＡＡＬ２ミニセルが送信地点から受信地点へと送信される前に、ＵＵＩルックアップテーブルの対応するアドレスをＡＡＬ２ミニセルヘッダのＵＵＩフィールド３０７へとコピーすることが必要なだけである。受信地点では、伸長アルゴリズムがＵＵＩフィールド３０７を解析する。それから、ＵＵＩフィールド３０７に格納されたＵＵＩルックアップテーブルのアドレスがＵＵＩルックアップテーブルに格納されたＰＰＰプロトコルＩＤ８１０を取り出すのに用いられる。
【００３２】
もし、ＰＰＰプロトコルＩＤ８１０がＵＵＩルックアップテーブルに以前には格納されていなかったなら、新しいＵＵＩコードがＡＡＬ２ミニセルヘッダのＵＵＩフィールド３０７に挿入され、ＰＰＰプロトコルＩＤ８１０が、そっくりそのまま、受信地点へと転送される。伸長アルゴリズムでは、そのとき、ＵＵＩフィールド３０７に格納された圧縮アルゴリズムのアドレスに従って、以前には格納されていなかったＰＰＰプロトコルＩＤ８１０をＵＵＩルックアップテーブルに格納する。それゆえ、その後、同じＰＰＰプロトコルＩＤ８１０を共有する送信されたＩＰ／ＰＰＰデータパケットは、ただ、適切なＵＵＩルックアップテーブルのアドレスを含むことが必要なだけである。
【００３３】
当業者であればすぐに認識できるように、ＵＵＩフィールド３０７は一般に、ＡＡＬ２ミニセルの長さが現在のＡＴＭセルペイロードで利用可能な空間を超えるときに用いられる情報を含んでいる。例えば、図２のセグメント化されたミニセル２１５を見られたい。ミニセルをセグメントに分割することが必要であるなら、ＵＵＩフィールド３０７は上述のようにＰＰＰプロトコルＩＤ８１０をマップするためには利用可能ではない。それゆえに、対応するミニセルがセグメント化されることになっているなら、ＰＰＰプロトコルＩＤ８１０がＩＰ／ＰＰＰデータパケットヘッダの一部として、そっくりそのまま送信され、ＵＵＩフィールド３０７にマップされないことが本発明の１つの側面となっている。しかしながら、セグメント化することは、セッションコンテキスト／コネクションＩＤ８５０をＣＩＤフィールド３０４へとマッピングすることに影響を与えるものではない。従って、たとえミニセルがセグメント化されることになっても、オーバヘッドは依然として軽減される。
【００３４】
図９は、本発明の好適な実施形態に従って、圧縮されたＩＰ／ＰＰＰデータパターンヘッダ９０５のセッションコンテキスト／コネクションＩＤ８５０が、上述のように、ＡＡＬ２ミニセルヘッダ９１０のＣＩＤフィールド３０４にマップされる様子を図示している。図９はまた、通常の環境の下で、上述のように、ＰＰＰプロトコルＩＤ８１０がＡＡＬ２ミニセルヘッダ９１０のＵＵＩフィールド３０７にマップされることを示している。しかしながら、ＩＰ／ＰＰＰデータパケットヘッダ、例えば、ＩＰ／ＰＰＰデータパケットヘッダ１００５が圧縮されていないなら、図１０に図示されているように、デフォルトコードが対応するミニセルヘッダ１０１０のＣＩＤとＵＵＩフィールドの両方に格納されても良い。
【００３５】
別の実施形態に従えば、圧縮ヘッダの循環冗長コード（ＣＲＣ）９１５が、セッションコンテキスト／コネクションＩＤ８５０が図９に図示されているようにＣＩＤフィールド３０４にマップされるとき、ＩＰ／ＰＰＰデータパケットヘッダの一部として含まれても良い。圧縮ヘッダＣＲＣ９１５の追加によって圧縮ヘッダデータ９２０についての伝送エラーからの損失保護が備えられる。しかしながら、圧縮ヘッダＣＲＣ９１５を含むことはオーバヘッドを要することになる。従って、圧縮ヘッダＣＲＣ９１５はオプションであって、適切な構成命令を実行することによって選択される。
【００３６】
図１１はミニセルのセグメント化が必要であるとき、上述のように、セッションコンテキスト／コネクションＩＤ８５０だけが、セグメント化されたＡＡＬ２ミニセルヘッダ１１０５のＣＩＤフィールド３０４にマップされることを図示している。ＰＰＰプロトコルＩＤ８１０はＵＵＩフィールド３０７にはマップされず、ＵＵＩフィールド３０７がＡＡＬ２ミニセル１１１０のセグメント化を定義するために助けが必要とされるので、図示されているように、ＰＰＰプロトコルＩＤ８１０はそっくりそのまま送信されなければならない。
【００３７】
本発明のさらに別の実施形態に従えば、上述したのと同じアプローチを用いて、マッピングが圧縮ヘッダ制御データフィールド８５５の一部にまで拡張される。わずか数個のＰＰＰプロトコルＩＤタイプがあるだけなので、ＵＵＩデータフィールド３０７は、圧縮ヘッダ制御データフィールド８５５に関連したマスキングビットとシーケンスカウントフィールドとをマップするために用いられても良い。
【００３８】
本発明をいくつかの代表的な実施形態を参照して説明した。しかしながら、当業者には、本発明を上述した代表的な実施形態とは別の具体的な形で実施することができることが明白であろう。このことは、本発明の精神から逸脱することなくなされる。これら代表的な実施形態は単に説明のためだけのものであり、これによって本発明がどのようにも限定されるものであるとは考えるべきではない。本発明の範囲は、前述の説明ではなくむしろ、添付された請求の範囲によって与えられており、その請求の範囲内にある全ての変形例や同等物はそこに含まれるものであることが意図されている。
【図面の簡単な説明】
本発明の目的及び利点は図面と関連して詳細に記述された説明を読むことにより理解できるが、その図面は次の通りである。
【図１】従来技術に従う、ＡＴＭ適合レイヤと、アプリケーションレイヤとＡＴＭレイヤの両方との間の関係を示す図である。
【図２】従来技術に従う、ＡＡＬ２処理を示す図である。
【図３】従来技術に従う、典型的なＡＡＬ２ミニセルに関するプロトコルを示す。
【図４】従来技術に従う、ＩＰ／ＰＰＰデータパケットのカプセル包み込みモデルを示す図である。
【図５】従来技術に従う、代表的なＩＰデータパケットヘッダを示す図である。
【図６】従来技術に従う、代表的なＩＰデータパケットヘッダを示す図である。
【図７】従来技術に従う、フルデータパケットヘッダを含むＩＰ／ＰＰＰデータパケットを示す図である。
【図８】従来技術に従う、圧縮データパケットヘッダを含むＩＰ／ＰＰＰデータパケットを示す図である。
【図９】本発明のマッピングの特徴を示す図である。
【図１０】本発明に従うデフォルトＣＩＤコードの挿入を示す図である。
【図１１】ＡＡＬ２ミニセルがセグメントに分割される時の本発明のマッピングの特徴を示す図である。

Claims

ネットワーク環境において、ヘッダ部を含むインターネットプロトコルデータパケットを転送する方法であって、
ルックアップテーブルのある場所に前記インターネットプロトコルデータパケットの一部を格納する工程と、
前記インターネットプロトコルデータパケットのヘッダの一部が格納された前記ルックアップテーブルの位置に対応するアドレスをＡＡＬ２ミニセルヘッダの一部に挿入することにより、前記ルックアップテーブルに格納された前記インターネットプロトコルデータパケットの一部をマッピングする工程と、
前記インターネットプロトコルデータパケットのヘッダの残りの部分を前記ＡＡＬ２ミニセルのペイロード部に挿入する工程と、
前記ＡＡＬ２ミニセルを、前記ネットワークの受信地点に送信する工程と、
前記ＡＡＬ２ミニセルヘッダに挿入されたアドレスを解析する工程と、
前記ＡＡＬ２ミニセルヘッダのアドレスに基づいて、前記ルックアップテーブルに格納された前記インターネットプロトコルデータパケットのヘッダの一部を取り出す工程とを有することを特徴とする方法。
前記ルックアップテーブルに格納された前記インターネットプロトコルデータパケットの一部は、セッションのコンテキスト／コネクションの識別子であることを特徴とする請求項１に記載の方法。
前記ルックアップテーブルのアドレスが格納されている前記ＡＡＬ２ミニセルヘッダの一部はチャネル識別データフィールドであることを特徴とする請求項１に記載の方法。
ＡＡＬ２コネクションでインターネットプロトコルデータパケットを伝送する方法であって、
ポイント−ツウ−ポイントのプロトコルを用いて、ヘッダ部を含む前記インターネットプロトコルデータパケットをカプセルに包む工程と、
前記インターネットプロトコルデータパケットのヘッダの第１データフィールドに関連したデータが第１のルックアップテーブルに以前に格納されていたかどうかを判断する工程と、
もし、前記インターネットプロトコルデータパケットのヘッダの第１データフィールドに関連したデータが前記第１のルックアップテーブルに以前に格納されていたならば、前記インターネットプロトコルデータパケットのヘッダから前記第１データフィールドを省略し、ＡＡＬ２ミニセルヘッダの第１データフィールドに、前記インターネットプロトコルデータパケットのヘッダの第１データフィールドに関連したデータが格納された前記第１のルックアップテーブルの位置に対応するアドレスを挿入する工程と、
前記カプセル化された前記ヘッダ部を含むインターネットプロトコルデータパケットを前記ＡＡＬ２ミニセルのペイロード部に挿入する工程と、
前記ＡＡＬ２ミニセルを、ネットワークの受信地点に送信する工程と、
前記ＡＡＬ２ミニセルヘッダの第１データフィールドに格納されたアドレスに従って、前記第１ルックアップテーブルから前記インターネットプロトコルデータパケットのヘッダの前記第１データフィールドに関連した前記データを取り出す工程とを有することを特徴とする方法。
前記ＡＡＬ２ミニセルはセグメントに分割されるべきかどうかを判断する工程をさらに有することを特徴とする請求項４に記載の方法。
もし、前記ＡＡＬ２ミニセルはセグメントに分割されるべきではないなら、前記インターネットプロトコルデータパケットから第２データフィールドを省略し、前記インターネットプロトコルデータパケットの前記第２データフィールドに関連したデータが格納されている第２のルックアップテーブルの場所に対応した前記ＡＡＬ２ミニセルヘッダの前記第２データフィールドに格納されたアドレスを挿入する工程と、
前記受信地点において、前記ＡＡＬ２ミニセルヘッダの前記第２データフィールドに格納されたアドレスに従って、前記第２のルックアップテーブルから、前記インターネットプロトコルデータパケットの前記第２データフィールドに関連した前記データを取り出す工程とをさらに有することを特徴とする請求項４に記載の方法。
前記インターネットプロトコルデータパケットの前記第２データフィールドは、ポイント−ツウ−ポイントのプロトコル識別子データフィールドであることを特徴とする請求項６に記載の方法。
前記ＡＡＬ２ミニセルヘッダの前記第２データフィールドは、ユーザ対ユーザの情報データフィールドであることを特徴とする請求項６に記載の方法。
前記インターネットプロトコルデータパケットのヘッダの前記第１データフィールドは、セッションのコンテキスト／コネクションの識別子のデータフィールドであることを特徴とする請求項４に記載の方法。
前記セッションのコンテキスト／コネクションの識別子のデータフィールドに関連したデータは、データパケットのルーティング情報であることを特徴とする請求項９に記載の方法。
ネットワーク環境におけるＡＡＬ２ミニセルで、ポイント−ツウ−ポイントのプロトコルで、カプセルに包まれた、ヘッダ部を含むインターネットプロトコルデータパケットを伝送する方法であって、
前記インターネットプロトコルデータパケットのヘッダが圧縮形式にあるかどうか判断する工程と、
もし、前記インターネットプロトコルデータパケットのヘッダが圧縮されていたならば、前記ＡＡＬ２ミニセルヘッダの第１データフィールドに格納されたアドレスを用いて、以前に第１のルックアップテーブルに格納された前記インターネットプロトコルデータパケットのヘッダの第１データフィールドに関連したデータをマップする工程と、
前記ＡＡＬ２ミニセルはセグメントに分割されるべきかどうかを判断する工程と、
もし、前記ＡＡＬ２ミニセルがセグメントに分割されるべきであるなら、前記ＡＡＬ２ミニセルヘッダの第２の部分に格納されたアドレスを用いて、以前に第２のルックアップテーブルに格納された前記インターネットプロトコルデータパケットの第２データフィールドに関連したデータをマップする工程と、
前記ＡＡＬ２ミニセルを前記ネットワークにおける受信地点に伝送する工程と、
前記ＡＡＬ２ミニセルヘッダの前記第１の部分に格納された前記アドレスに基づいて、前記第１のルックアップテーブルから、前記インターネットプロトコルデータパケットのヘッダの前記第１データフィールドに関連したデータと、前記ＡＡＬ２ミニセルヘッダの前記第２の部分に格納された前記アドレスに基づいて、前記第２のルックアップテーブルから、前記インターネットプロトコルデータパケットの前記第２データフィールドに関連したデータとを取り出す工程とを有することを特徴とする方法。
前記インターネットプロトコルデータパケットは、伝送制御プロトコル（ＴＣＰ）データパケットであることを特徴とする請求項１１に記載の方法。
前記インターネットプロトコルデータパケットは、ユーザデータグラムプロトコル（ＵＤＰ）データパケットであることを特徴とする請求項１１に記載の方法。
前記インターネットプロトコルデータパケットは、リアルタイム伝送プロトコル（ＲＴＰ）データパケットであることを特徴とする請求項１１に記載の方法。
前記インターネットプロトコルデータパケットのヘッダの第１フィールドに関連したデータは、データパケットルーティング情報であることを特徴とする請求項１１に記載の方法。
前記インターネットプロトコルデータパケットの前記第１データフィールドは、セッションのコンテキスト／コネクションの識別子のデータフィールドであることを特徴とする請求項１５に記載の方法。
前記インターネットプロトコルデータパケットの前記第２データフィールドに関連したデータは、インターネットプロトコルタイプのデータであることを特徴とする請求項１１に記載の方法。
ネットワーク環境におけるＡＡＬ２ミニセルで、ヘッダ部を含むインターネットプロトコルデータパケットを伝送する方法であって、
第１のインターネットプロトコルデータパケットのヘッダ部のセッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが以前にルックアップテーブルに格納されたものであるかどうかを判断する工程と、
もし、前記セッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが以前に前記ルックアップテーブルに格納されたものではないなら、第１のＡＡＬ２ミニセルのペイロード部に、フルヘッダである前記インターネットプロトコルデータパケットのヘッダを挿入する工程と、
前記ＡＡＬ２ミニセルの前記ヘッダ部に関連したデータフィールドに、未使用のルックアップテーブルアドレスを挿入する工程と、
前記第１のＡＡＬ２ミニセルを前記ネットワークにおける送信地点から受信地点に送信する工程と、
前記ＡＡＬ２ミニセルヘッダに関連したデータフィールドの前記未使用のアドレスに従って、前記ルックアップテーブルの前記セッションコンテキスト／コネクション識別子のデータフィールドに関連したデータを格納する工程と、
第２のインターネットプロトコルデータパケットのヘッダ部のセッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが以前に前記ルックアップテーブルに格納されたものであるかどうかを判断する工程と、
もし、前記第２のインターネットプロトコルデータパケットの前記セッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが以前に格納されたものであるなら、第２のＡＡＬ２ミニセルのヘッダ部に関連したデータフィールドに、前記セッションコンテキスト／コネクション識別子のデータフィールドに関連したデータが以前に格納された前記第１のルックアップテーブルの場所に対応するアドレスを格納する工程と、
前記セッションコンテキスト／コネクション識別子のデータフィールドを除く前記第２のインターネットプロトコルデータパケットのヘッダの残りの部分を前記第２のＡＡＬ２ミニセルのペイロード部に挿入する工程と、
前記第２のＡＡＬ２ミニセルを前記受信地点に送信する工程と、
前記第２のＡＡＬ２ミニセルヘッダのデータフィールドに格納された前記アドレスに基づいて、前記第２のインターネットプロトコルデータパケットのヘッダの前記セッションコンテキスト／コネクション識別子のデータフィールドに関連したデータを取り出す工程とを有することを特徴とする方法。
前記第１及び第２のミニセルヘッダにおける前記データフィールドはコネクション識別（ＣＩＤ）データフィールドであることを特徴とする請求項１８に記載の方法。
もし、前記第１のインターネットプロトコルデータパケットの前記ヘッダ部の前記セッションコンテキスト／コネクション識別子のフィールドに関連したデータが前記ルックアップテーブルに以前には格納されていないなら、前記第１のＡＡＬ２ミニセルのヘッダ部のデータフィールドに、デフォルトコードを挿入する工程をさらに有することを特徴とする請求項１８に記載の方法。