JP3649367B2 - パケット伝送制御方法および装置 - Google Patents
パケット伝送制御方法および装置 Download PDFInfo
- Publication number
- JP3649367B2 JP3649367B2 JP26193697A JP26193697A JP3649367B2 JP 3649367 B2 JP3649367 B2 JP 3649367B2 JP 26193697 A JP26193697 A JP 26193697A JP 26193697 A JP26193697 A JP 26193697A JP 3649367 B2 JP3649367 B2 JP 3649367B2
- Authority
- JP
- Japan
- Prior art keywords
- atm
- merged
- cell
- vcs
- network
- 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
- 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/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/4608—LAN interconnection over ATM networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
- H04Q11/0478—Provisions for broadband connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5646—Cell characteristics, e.g. loss, delay, jitter, sequence integrity
- H04L2012/5647—Cell loss
- H04L2012/5648—Packet discarding, e.g. EPD, PTD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5646—Cell characteristics, e.g. loss, delay, jitter, sequence integrity
- H04L2012/5652—Cell construction, e.g. including header, packetisation, depacketisation, assembly, reassembly
- H04L2012/5653—Cell construction, e.g. including header, packetisation, depacketisation, assembly, reassembly using the ATM adaptation layer [AAL]
- H04L2012/5658—Cell construction, e.g. including header, packetisation, depacketisation, assembly, reassembly using the ATM adaptation layer [AAL] using the AAL5
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5665—Interaction of ATM with other protocols
- H04L2012/5667—IP over ATM
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5672—Multiplexing, e.g. coding, scrambling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5678—Traffic aspects, e.g. arbitration, load balancing, smoothing, buffer management
- H04L2012/5681—Buffer or queue management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、パケット伝送制御方法および装置に関し、例えば、マージするバーチャルコネクションの数の多いものを優先的にマージするパケット伝送制御方法および装置に関する。
【０００２】
【従来の技術】
ATM(Asynchronous Transfer Mode)を用いて、IP(Internet Protocol)ネットワークを構築するとき、コネクションレスであるIPパケットをいかにしてコネクションオリエンティッドな技術であるATMのVirtual Connection（以下、VCと略記する）で伝送するかが問題となる。
【０００３】
一つの方法として、全ての始点ネットワークから、全ての終点ネットワークに対して、メッシュ状にVCを張り、始点ではIPのパケットを宛先IPアドレスに対応する終点ネットワークにつながるVCに送り込むという方法がある。この方法は、既存の技術のみで簡単にいますぐに実現できるというメリットがあるが、必要なVCの本数がネットワーク数の２乗のオーダになるため、スケーラビリティの問題を抱えている。
【０００４】
スケーラビリティの問題を解決するために、VCをメッシュ状に用意するのではなく、各終点ネットワークから全ての始点に対して、ツリー状にVCを用意する方法が考えられている。このときも、始点では、IPのパケットを宛先IPアドレスに対応するVCに送り込む。そのIPパケットは、ツリーにおけるVCの各合流点において、複数のVCから１つのVCに載せ替えられていき、最終的には期待する終点ネットワークにパケットを転送することができる。この方法によると、パケット転送時の分岐処理を行う必要がないため、ルータでの処理が不要となり、ATMレイヤのみで処理が可能となる。
【０００５】
以下では、複数のVCから流入してくるパケットを１つのVCに載せ替える処理をする装置をVC mergerと呼ぶことにする。VC mergerは、ATM switchに組み込まれていることもあれば、外付けのときもある。複数のVCから流入してくるパケットを１つのVCに載せ替えるとき、ATM上では、IPパケットはそれより小さなセルに分解されて転送されていることが問題となる。
【０００６】
各VC内では、セルは失われることはあっても、順序は保持され、各セルの間に新たなセルが挿入されることもない。IPパケットを複数のセルに載せるときのフォーマットは、それを前提とした簡潔なものになっている。そのため、複数のVCを流れるセルを合流させて１つのVCに載せ替えるとき、セル単位ではなく、IPのパケット単位で処理を行わないと、正しくパケットを転送することができない。また、VC mergingのために利用できるキューの数が、マージ結果のVCの数より少ないとき、早いもの勝ちでマージすべきVCを決めるようにしている。
【０００７】
ATMの転送単位であるセルは、ヘッダ５バイト、データ４８バイトの合計５３バイト固定長である。IPパケットは、ヘッダ２０バイト（オプション込みで最長６０バイト）、データ部を含めた長さは、最長６５５３５バイトの可変長である。データをセルに載せるときのフォーマットをAAL(ATM Adaptation Layer)と呼び、現在、タイプ１、タイプ３／４、およびタイプ５が定義されている。
【０００８】
IPをセルに載せるときは一般的にAAL５が用いられる。処理例は、次の通りである。
【０００９】
まず、第１のステップとして、IPパケットの前後にヘッダ、トレイラをつける。正確には、この処理は、AAL5の範囲外であり、RFC1483に従うことが多い。なお、RFC(Request for Comments)は、インターネットの研究開発機関IETF(Internet Engineering Task Force)がインターネット上のサーバ(http://ds.internic.net/)に公開しているTCP/IP仕様やサービスに関する規格書で内容ごとに通し番号が付されている。
【００１０】
次に、第２のステップとして、それに、AAL5 CPCS(Common Part Convergence Sublayer)と呼ばれる方式でトレイラが付けられる。トレイラには、長さ情報、３２ビットのCRC(cyclic redundancy check)も含まれている。この結果、全体の長さが４８バイトの倍数になる。これを、以下ではフレームと呼ぶことにする。次に、第３のステップとして、このフレームを４８バイトずつATMセルに載せていく。
【００１１】
フレームの末尾を載せるセル中の、あるビット（正確には、PTIのUser Signaling Bit)を１にする。それ以外のセルでは、そのビットは０とする。以上の処理において、正確には第２のステップおよび第３のステップにおける処理が、AAL5のための処理である。
【００１２】
ATMのセル列から、AAL5のフレームを取り出す処理の例は、次の通りである。まず、AAL5フレームの最終セルであることを示すビットの立っているセルが来るまで、セルのデータをバッファにためる。次に、長さとCRCをチェックし、異常があれば、そのフレームを破棄する。異常がなければ完了する。
【００１３】
IPをATMに載せるとき、最大IP長を制限することが多い。このとき、RFC1626に従い、最大IP長を９１８０バイトにすることが多い。ATMセルのヘッダには、１２ビット若しくは８ビットのVPI(Virtual Path Identifier)と、１６ビットのVCI(Virtual Channel Identifier)が書かれている。ATMスイッチは、複数の入出力ポートを有しており、入力ポートにおいて、VPI,VCIをキーにして、行き先テーブルを引き、出力ポートと新しいVPI,VCIを得る。一般にVPI,VCIは行き先テーブルの配列の添え字として用いられる。次に、セルのヘッダ中のVPI,VCIフィールドを書き換え、指定された出力ポートに転送する。出力ポートでは、出力すべくキューにたまっているセルの優先度その他を参考にしながら、セルを出力していく。場合によっては、VPIのみを見て、VPIのみを書き換えながら、セルを転送することがある。VPIのみで転送する経路をVirtual Path(VP)と呼ぶ。
【００１４】
ATMスイッチ間は、光ファイバで結ばれることが多い。１００Ｍｂｐｓ（メガビット／秒）のイーサネット(100BASE-TX)のMTU（Maximum Transfer Unit：最大転送可能パケットサイズ）は、１０Ｍｂｐｓのイーサネットの場合と同様に１５００バイトである。Gigabit EthernetのMTUも１５００バイトである。ただし、Gigabit Ethernetでは、約９０００バイトのパケットを転送することもできる。100BASE-TXの場合においても、約９０００バイトのパケット転送ができるようにしようという提案がされている。従って、当面は、現実的なパケットサイズの上限は、１５００バイトであるが、将来、約９０００バイトのパケットが広く利用される可能性がある。
【００１５】
【発明が解決しようとする課題】
しかしながら、バーチャルコネクション(VC)のために利用可能なキューの数が実装上の制約により、マージすべきVCの数より少ないとき、早い者勝ちでマージ処理すべきVCが決められていた。このため、VCの数を効率的に削減できない課題があった。
【００１６】
本発明はこのような状況に鑑みてなされたものであり、VCの数を効率的に削減することができるようにするものである。
【００１７】
【課題を解決するための手段】
請求項１に記載のパケット伝送制御方法は、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定する判定ステップと、判定ステップにおける判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージするマージステップとを備えることを特徴とする。
【００１８】
請求項２に記載のパケット伝送制御装置は、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定する判定手段と、判定手段による判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージするマージ手段とを備えることを特徴とする。
【００１９】
請求項１に記載のパケット伝送制御方法および請求項２に記載のパケット伝送制御装置においては、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定し、その判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージする。
【００２０】
【発明の実施の形態】
まず最初に、本出願人らが開発している広域高速ネットワーク環境を提供するAMInetについて説明する。
【００２１】
AMInetは、既存のネットワークアーキテクチャがもつ問題を解決する次世代ネットワークアーキテクチャである。コネクション指向のQoS(Quality of Service)保証、マルチキャストのサポート、識別子とアドレスの分離、非エンド間制御、ネゴシエーションによる最適プロトコルスタックの動的構築などを特徴とする。AMInetアーキテクチャに基づくネットワークはFTTH(Fiber To The Home)時代を見据え、広域バックボーンのみならず家庭内ネットワークをも対象としている。
【００２２】
現在、通信と放送の融合を目指した新しいネットワークアーキテクチャが求められている。OSI(Open Systems Interconnection)参照モデルやインターネットアーキテクチャは約20年前に設計されたものであり、動画や音声などの連続メディア通信実現への要求、携帯型コンピュータの出現による移動透過な通信への要求、ATM(Asynchronous Transfer Mode:非同期転送モード)に代表される超高速通信技術の有効利用などに対応することができない。
【００２３】
インターネットではこれらに対処するための拡張が行われているが、インターネットアーキテクチャには、
- IP(Internet Protocol)データグラムを基本とし、
- データリンクの特性を考慮せず、
- 識別子とアドレスの明確な分離がなされず、
- エンドノード間でのみトラフィック制御を行う
という問題点があり、上記の問題を解決することができない。
【００２４】
インターネットへの接続形態の現状を見ると、大企業は専用線によりインターネットに常時接続しているが、小企業や家庭はダイヤルアップによる間欠接続を利用している。常時接続の場合でも回線速度は1.5Mbps（メガビット／秒）程度であり、間欠接続の場合は128kbps（キロビット／秒）程度である。接続形態が間欠接続から常時接続になるだけでも、家庭等におけるインターネットの利用形態は大きく変化する。さらに回線速度が桁違いに速くなれば、今では想像もできないようなアプリケーションが登場するであろう。
【００２５】
AMInetアーキテクチャは、FTTH(T. Miki.Toward the Service-Rich Era.IEEE Communications Magazine, Vol.32, No.2, February 1994)やxDSL(G. T. Hawley.Systems Considerations for the Use of xDSL Technology for Data Access.IEEE Communications Magazine, Vol.35, No.3, March 1997)の実現によって家庭や企業が超高速ネットワークに対称／準対称型で常時接続される時代を見据え、インターネットアーキテクチャが持つ本質的な問題点を解決するものである。以下に、AMInetアーキテクチャおよびシステムモデルを示す。
【００２６】
今後は、動画や音声のような連続メディアを利用したアプリケーションがますます増えると考えられる。技術的には、利用できる帯域幅、伝送遅延、伝送遅延のばらつき(ジッタ)、エラー率のようなサービス品質(QoS)の保証を可能にしなければならない。
【００２７】
一方、医療用イメージ、新聞、映画フィルム全体のような大量データ転送への要求も今後高まることが予想される。このようなアプリケーションではできるだけ高速にデータ転送をしなければならない。技術的には、いわゆる”long fat pipe”問題を解決し、超高速ネットワークの帯域を有効に利用する技術を開発する必要がある。
【００２８】
現在の通信形態はほとんどが1対1通信である。今後は同一データの複数相手への送信(マルチキャスト)、移動体との移動透過な通信なども必要となる。アーキテクチャとしては識別子とアドレスの関係をどのように扱うかという問題があり、技術的にはスケーラブルな経路制御方式を確立する必要がある。さらにQoSの保証や高速大容量通信も要求される。
【００２９】
コンピュータネットワークが真に通信のインフラストラクチャとなるためには強固なセキュリティを実現しなければならない。AMInetではノード間における守秘、改竄防止、認証、トラフィック解析防止を対象とする。利用者認証などはアプリケーションプログラムの範疇であり、AMInetの対象外である。
【００３０】
以上のような特徴を持つネットワークを構築しても、インターネットと互換性がなくてはユーザをスムーズに移行させることはできない。ユーザからは実際のネットワークがAMInetであるのか既存のインターネットであるのかを意識させないようにする必要がある。
【００３１】
次に、AMInetアーキテクチャの特徴について説明する。上述したインターネットアーキテクチャの欠点に対比すると、AMInetアーキテクチャの特徴は以下のようになる。
- 最適なプロトコルスタックの動的構築
- ノード間の同位階層間およびノード内の上下階層間のネゴシエーション
- コネクション指向のQoS保証
- ノードの識別子とアドレスの分離
- 非エンド間制御
- 通信媒体に依存しないアーキテクチャ
【００３２】
OSIの階層モデルに従うと、ある階層はその下の階層の機能を抽象化し、詳細を隠蔽してしまう。現実の広域ネットワークは異なった特性をもつさまざまなデータリンクから構成されている。また移動ノードの場合、データリンクの特性が通信中に変化することもある。上下階層間のネゴシエーションにより、上位層は下位層の特性や状態を知ることができ、通信環境に動的に適応できるようになる。
【００３３】
プロトコルスタックが固定だと、異なる階層で重複した機能を実行して無駄が生じることがある。AMInetでは最適なプロトコルスタックを動的に構築する。たとえばエンドノード間のすべてのデータリンクが信頼性を保証するなら、トランスポート層で信頼性を保証するための機能を省略することができる。また、無線LANで接続しているノードが広域ネットワーク内の他のノードと通信する場合のように、通信経路においてある一部分だけデータリンクの特性が異なる場合、そのデータリンクの両側のノードだけに特別のプロトコルスタックを構成し、データリンクの特性の違いを吸収することにより、エンド間の通信を効率よく行うことも可能になる。
【００３４】
最適なプロトコルスタックを構築するためにはネゴシエーションを利用する。通常、ネゴシエーションはノード間の同位階層間で行うが、AMInetではノード内の上下階層間でもネゴシエーションを行う。
【００３５】
インターネットはIPデータグラムを基本としており、QoSを保証する場合でもネットワーク層において明確に論理コネクションを確立するという考えはない。これはネットワークの障害への耐故障性を重視するためである。これに対してAMInetではQoSの保証を重視し、QoSを保証するために、論理コネクションを積極的に利用する。
【００３６】
インターネットではIPアドレスがノードの位置を表すとともにノードの識別子の役割も果たしている。このために移動ノードとの移動透過な通信ができない。またセキュリティを確保するための処理も煩雑になる。次世代IPであるIPv6においてもノード識別子についてさかんに議論が行われたが、結局ノード識別子という考え方は採用されていない。AMInetではノードの識別子とアドレスを明確に分離することにより、移動透過な通信(F. Teraoka, K. Uehara, H. Sunahara, and J. Murai.VIP: A Protocol Providing Host Mobility.CACM, Vol.37, No.8, August 1994)を可能にし、セキュリティ処理を軽減する。
【００３７】
さらにインターネットではフロー制御、エラー回復、輻輳制御などをエンドノードのトランスポート層で行う。輻輳制御の場合、輻輳が発生しているノード(ルータ)と送信ノードの間で輻輳回復を行う方が効果的だと考えられる。
【００３８】
AMInetとインターネットに共通しているのは、アーキテクチャをデータリンクから独立させるため、すべてのノードが共通してもつ階層を導入していることである。インターネットとの互換性を保つため、実質的にはAMInetでもIP(v4およびv6)をいわゆるネットワーク層として採用する。ただしプロトコルスタックの動的な構築により、データ通信の際にはIP層はバイパスされることもある。
【００３９】
次に、プロトコル階層について説明する。AMInetは動的にプロトコルスタックを構築するが、プロトコルモジュールを機能別に階層化すると図１のようになる。最下位層はダイレクトネットワーク層である。単一の伝送媒体を介して”ダイレクト”に通信できるノード間の通信機能を提供する層である。OSI参照モデルの物理層とデータリンク層に相当する。具体的にはEthernetやATMなどのプロトコルがこの層に対応する。
【００４０】
図１はAMInetアーキテクチャを表しており、ダイレクトネットワーク層の上に仮想ネットワーク層を置く。複数の伝送媒体からなるネットワークを”仮想的”に１つの伝送媒体のように見せ、これに接続しているノード間の通信機能を提供する。プロトコルスタックの動的構築はこの階層内で行われる。OSI参照モデルのネットワーク層とトランスポート層に相当する。
【００４１】
仮想ネットワーク層の上にセッション層を置く。セッション層は仮想ネットワーク層が提供する通信機能を抽象化して最上位層であるアプリケーション層に提供する。OSI参照モデルのセッション層とは機能が異なる。抽象化とは、QoSパラメータを”テレビ品質の動画”のように数値以外で指定可能にしたり、通信相手をノードのアドレスや識別子ではなく、サービス名で指定可能にしたり、仮想ネットワーク層のコネクションが障害やノードの移動などで一時的に切断されたときも、あたかもコネクションが連続して存在するように見せることをいう。最上位のアプリケーション層はAMInetプロジェクトの対象外である。
【００４２】
図１において、水平矢印は同位階層間のネゴシエーションを、垂直矢印は上下階層間のネゴシエーションを示す。同位階層間ネゴシエーションには、エンドノード間で行われるセッションネゴシエーションおよびフローネゴシエーション、隣接ノード間で行われるホップ間ネゴシエーションがある。上下階層間ネゴシエーションには、上位層から下位層への要求を伝えるリクエストと、下位層の状態を上位層へ伝えるインディケーションがある。このようなネゴシエーションにより、エンドノード間の通信環境やダイレクトネットワーク層の特性を知り、最適なプロトコルスタックを構築する。
【００４３】
次に、システム構成について説明する。AMInetは広域ネットワークのみではなく、家庭内ネットワークも考慮している。AMInetプロジェクトが想定しているシステム構成を図２に示す。同図に示すように、全体のネットワークはバックボーン、ホームネットワーク、これらを接続する加入者ネットワークという３つの部分に分けられる。
【００４４】
図２は、AMInetのシステム構成の例を表している。バックボーンは日本全国を覆うような大規模なものを想定しており、ATMの超高速通信技術を活用する。バックボーンとなるATM網はATMスイッチ（と光ファイバ）で構成されるが、ATMスイッチのうち、高速シグナリング等のAMInet独自の機能拡張をしたものをバックボーンルータと呼ぶ。
【００４５】
バックボーンの周辺にはエッジルータを置く。エッジルータはバックボーンルータと同様にATMスイッチにAMInet独自の機能拡張を行ったものである。エッジルータは加入者線を集線してバックボーンへと接続する位置にあり、加入者の課金やホームネットワークからバックボーンへ流入するトラフィックのシェーピングも行う。加入者線としてはFTTHによって光ファイバが布設されるか、あるいは銅線を利用したADSL(Asymmetric digital subscriber line)のような技術が利用されるかもしれない。どちらの場合でも家庭までATMネットワークが届くものと考えられる。
【００４６】
家庭にはホームルータを置く。ホームルータは外部ネットワークインターフェイスとしてATMを持ち、内部ネットワークインターフェイスとしてはIEEE1394やイーサーネット(10Mbps/100Mbps)などを持つものと想定している。IEEE1394は帯域確保などのQoS保証が可能なので、エンドノード間でQoSを保証した通信が可能になるなどの利点を持つ。また将来はAV機器がIEEE1394を装備するようになるので、コンピュータのみならずAV機器もネットワークに接続されるようになるであろう。
【００４７】
次に、AMInet におけるATMとIPの統合によるリアルタイム通信の実現(ATM Control through IP for Real-Time Communication in AMInet)について説明する。ここでは、AMInetプロジェクトが前提としているバックボーン、および家庭を接続する広域ネットワークで利用される資源予約セットアッププロトコルASP (AMInet Set up Protocol) について述べる。ASPは、IPの柔軟性および適応性、また回線指向型データリンクであるATMに注目し、それらを統合することによって、高速で柔軟な資源予約を実現することを目的としている。ASPは、通常のATMのシグナリングは利用せず、IPによって転送されるメッセージを利用してATM VCを動的に確立する。ここでは、ASPの特徴、現在のプロトタイプの実装、QoSルーティングとの統合について述べる。
【００４８】
FTTH (Fiber to the Home)やxDSL(digital subscriber line)技術の進歩により、家庭でもダイアルアップとは異なる、常時接続されている高速ネットワークを利用できるようになる。このような環境ではIntegrated Services (IS)、または大容量ファイル転送などのアプリケーションを効率良く実現する必要がある。特に、ISの実現のためには資源予約が有効である。資源予約を導入することによってネットワークはQoS (Quality of Service)を保証することができる。また、バルクデータ転送アプリケーションの場合、 TCPの機能を拡張して効率良くネットワーク自身を利用することも可能になる。
【００４９】
ここでは、広域高速ネットワーク環境を提供するAMInetにおける資源予約プロトコル:AMInet Set up Protocol(ASP)について述べる。ASPは、資源予約機能を提供するために、ATM VC技術とIPを効果的に統合する。また、高速資源予約および動的QoS変更にも対応し、QoSルーティングとの統合も考慮する。
【００５０】
次に、資源予約について説明する。インターネットでは、ISに対応するため資源予約は今後必須になる。資源予約の導入はもともとパケット交換であるインターネットにコネクションの概念を導入することになる。その結果、データリンクとしてATMを利用することは整合がよく、ATMによってQoSの保証も容易にできる。
【００５１】
AMInetでもATMに注目し、IPのデータリンクの１つとして扱っている。本稿では主にATMを用いた実現に関して述べる。現在、インターネットの標準化団体であるIETFでは、RSVP(Resource Reservation Protocol)を資源予約プロトコルとしてproposed standardの標準化を行っている。しかし、RSVPを利用した場合、現在規定されているインターネットドラフトではATMのSVC(Switched Virtual Channel)を利用した形態を前提としている。したがって、ATMシグナリングを利用してVC(Virtual Channel)を確立する必要がある。しかし、現在のATMシングナリング処理は重く、時間がかかるため、アプリケーション、およびネットワークにも悪影響を及ぼす可能性が高い。中には、シングナリングに必要な処理を分割し、並列に処理するシステムも提案されている。
【００５２】
その他にも同時に複数の経路に沿って資源予約を行い、クランクバックによるオーバーヘッドを削減するための研究もある。現状で、一般に購入できるATMスイッチではSVCを利用するとシグナリングの処理時間は通常のIPなどのデータ通信では利用できないオーダーになってしまう。これは主にATMスイッチは音声データ、すなわち、従来の電話におけるコネクション確立時間を基準として設計されたところにある。また現在のシングナリングを利用するだけでは動的にQoSを変更することはできない。
【００５３】
AMInetでは、上記の問題点を解決するため柔軟性の高いIPをセットアップメッセージの転送に利用し、ATM VCを直接確立することにより QoSを保証する。
【００５４】
AMInet Set up Protocol (ASP) は、広域ネットワーク、特に AMInetアーキテクチャに基づくルータからなる環境で動作する資源予約セットアッププロトコルである。AMInet はATMスイッチング機能をもつルータからなり、バックボーンとその境界にあるエッジルータから構成されている。予約する資源は、ATM VC、またはパケット処理時に利用されるキューなどである。特にATMとの統合の場合、通常のATMシグナリングを利用せず、ATMスイッチまたはATM機能をもつルータにおいてVCを確立する。IPを使ってセットアップメッセージを転送するので、高速資源予約が実現できる。したがって、通常、ATMスイッチではSVCと呼ばれるVCは全く利用せず、IPを利用したメッセージによって、VCを動的に確立する。このようなVCのことをPVC-on-demandと呼ぶ。ASPを利用することによって通常のSVCとは異なる形態でVCを動的に確立、または切断できる。
【００５５】
ASPを利用する場合でもデータは通常のIPで転送される。そこで、IPパケットは特定の予約された資源にマッピングされる。そのため、今まで利用されてきたアプリケーションから今後出て来る可能性のある新しいアプリケーションにもASPは簡単に対応できる。このマッピングは、ソースとデスティネーションIPアドレス、ソースとデスティネーションポート番号、およびプロトコル識別子フィールドなどを参照することによって行われる。通常のIPトラフィック、すなわちベストエフォートトラフィック(BE)は、あらかじめ設定されたデフォルトBE VCを通して転送される。ASPを使って予約された資源はBEトラフィックによって影響されない。また、資源の節約などを考えて１つのVCにまとめられたフローも、BEトラフィックに影響されず共存できる。
【００５６】
次に、柔軟なセットアップ機構について説明する。ASPでは効率良く資源を利用するために、またはアプリケーションの要求にあった予約を行うため、さまざまな形態で資源を予約できる。インターネットやATM環境ではではさまざまな種類のアプリケーションが存在する。テレビ会議、遠隔診断、ビデオオンデマンド (VoD)、MBoneを利用するマルチキャストアプリケーションなどの放送型のものから双方向にデータを送信する対話型のものがある。いずれの場合も、QoSパラメータを下位層の資源予約パラメータに効率良く、かつスケーラブルにマッピングする必要がある。
【００５７】
例えば、VoD の場合、サーバとクライアントの間においてVCを双方向に確立する必要はない。データは必ずサーバからクライアントに向かって流れるからである。ASPを用いた場合、ASP固有のメッセージのやりとり、アプリケーションが必要とするデータ転送以外の制御のやりとり(VoDの場合だと見る映画を途中で変更するためのクライアント側からの要求など)、さらに上位層（例えば、トランスポート層）などが必要とするやりとりは、他の専用VCを利用してもよいが、デフォルトBE VCを利用するだけでよい。ASPメッセージはデフォルトBE VCまたは指定された専用VCを通して転送される。
【００５８】
一方、対話型であるテレビ会議アプリケーションの場合は双方向VCが必要である。ASPは一方向、双方向の両方に対応している。さらに、対話型の場合、上流と下流トラフィックに対して、異なるQoSを設定できる非対象なモデルをサポートする。
【００５９】
ASPではRSVPまたはST-2+(Stream Transport Protocol-2+)の場合と同様に、資源予約要求は受信側からも可能である上、送信側からの発行も可能である。アプリケーション、または環境に応じて、資源予約を行う際に必要なQoS情報を送信側が持っている場合と、受信側が持っている場合がある。どちらの場合でも、ASPでは１パスで全ての予約を行うように設定できる。さらに、必要に応じて予約が完了したことを伝える応答メッセージを待つことも可能である。
【００６０】
図３に一般的な資源予約要求メッセージを受信側が発行している例を示す。これは、ビデオの放送型アプリケーションなどがASPを利用した場合を表す。すなわち、データはサーバ（送信側）１からクライアント（受信側）７の方向にしか転送されない。
【００６１】
受信側７では、まずQoSパラメータが解釈され、このコネクションで用いられるVPI/VCIを決定し、必要に応じてATM NIC(Network Interface Card)を設定する。またこの情報を含む ASPメッセージを作成し、バックボーンに隣接しているエッジルータに向けてこのメッセージを転送する。このメッセージはIPで転送され、IPのホップ毎に処理される。図３の例の場合、エッジルータにメッセージが届くと、ルータでは受信側に向けてVPI/VCIパラメータを設定する。VPI/VCIは各ノードで個別に管理されている。このようにASPメッセージは送信者１に向かって上流に転送され、各ルータ２乃至６では、このメッセージが転送される方向と逆方向に向けてVCが設定される。図には示されていないが、送信側１にメッセージが転送され、予約が実質的に完了すると、必要に応じて、受信側７に対して返答メッセージが転送される。この時点で、最低限バックボーンにおいては、送信側１から受信側７に向けてVCが確立される。すなわち、エッジを結ぶこのVCを利用することによって、データ転送時にIPをカットスルーし、ATMのみで通信できる。
【００６２】
図３はASPにおける柔軟なセットアップの一形態しか表していない。例えば、送信側１のみがQoS情報をもっていて、しかもマルチキャストアプリケーションで受信側７から予約要求を発行する場合、上記の例の返答が返る第２パスでVCの設定を行うようにメッセージを作成できる。さらに、双方向のVCを第１パスのみで確立してしまうことも可能となる。
【００６３】
次に、動的QoS変更について説明する。ASPでは独自のセットアップ機構によりATM VCを確立するので予め他のVCを用意する必要がなく、既に予約された資源のQoSを動的に変更できる。また、アプリケーションは簡単にサービスレベルをアップグレードすることもできる。例えば、単純にBEからISに移行する場合、データフローはデフォルトBE VCから図３などに示す新たなVCにマップし直すことも容易にできる。
【００６４】
次に、QoSルーティングとの統合について説明する。ASPでは、VCセットアップ時にQoSルーティングによる経路選択のサポートが考慮されている。具体的には、資源を予約する時に、従来のIPレベルでのルーティングテーブルを利用するのではなく、ISを必要とするフローのための独自ルーティングテーブルを管理するモジュールより経路情報の提供を受ける。これにより、QoS要求やネットワークの利用可能な資源状況に合わせて、フロー毎に異なる経路を利用できる。
【００６５】
また、従来の資源予約プロトコルとルーティング機構はそれぞれ独立したものを前提として考えられてきたが、ASPではQoSルーティングとの統合を目指している。これは、QoSルーティングのモジュールに対して、ASPが保持している資源予約情報をフィードバックすることによって行う。これにより、予約が失敗した場合の代替経路の選択が容易になる。また、予約する資源をネットワーク中に分散させることができ、１つの経路に資源予約を集中させることなくネットワーク全体を効率良く利用できる。
【００６６】
次に、プロトタイプ実装について説明する。ASPは、UNIXのデーモンプロセス(aspd)としてユーザ空間で実装されている。プロトタイプはFreeBSD 2.2.1で動作中であり、ATMスイッチを制御するためのライブラリ(swctl lib)とATM NICの設定を行うモジュール(afmap)と統合されている (図４参照)。現在、3つのタイプのルータがサポートされており、ホームルータは100Base-T EthernetとATMインタフェースをもつ。エッジルータは現在は複数のATMインタフェースをもつルータとして実現されている。バックボーンルータは、ATMスイッチとそれを制御するためのIPエンジンを含むPCからなる。現在のプロトタイプでは、Adaptec社とEfficient Networks社のPCIバス用ATMインタフェースカードと、Fore ASX-200WG ATMスイッチを利用している。ASP メッセージは raw IPを使って実装されている。
【００６７】
バックボーンルータは、装備されているスイッチにおいてPVC-on-demandを設定するため前述したスイッチ制御ライブラリを利用する。ISを必要とするIPフローはCBRのVCにマッピングされる。また、現在、ASPはATMスイッチで一対多のマルチキャストVCを作成することによって、マルチキャストに対応している。リーフによるジョイン、および資源予約もサポートしている。
【００６８】
VCIなどの識別子をはじめとするATM資源のスケーラビリティを考慮すると、IPフローをアプリケーション単位でVCにマッピングすることは効率が悪い。ASP を利用することにより、動的にフローをVCにまとめることが容易になる。しかし、フローをVCにまとめる基準については今後検討する必要がある。
【００６９】
最後に QoSルーティングモジュールについては、現在設計中であり、シミュレーションを通してその有効性を検討している。
【００７０】
次に、プロトタイプの性能について説明する。図５に、ASPの現在の実装における資源予約確立および解除の性能を示す。asp_openが資源予約要求を発行し、正常終了した場合に要する時間を表す(予約が成功したことに対して返答を待つ時間まで含まれる)。asp_closeは、その反対で予約を解除するための時間を示す。これらの測定は単一送信者および受信者の間にルータを１つ設けた際の受信側から各々の要求をユニキャスト通信に対して発行した場合を表す。送信者と受信者は各々ATM NICを装備していて、図の中のASPと表記されている時間には、ASPに必要な処理およびNICに対してフローをマップする作業も含まれる。swctl_libは、前節で述べたATMスイッチ制御ライブラリにおいて必要な処理時間を示す。また、switchは、ATMスイッチ制御ライブラリを用いてATMスイッチをSNMPで設定するために必要な時間を表す。
【００７１】
図５から分かるように、ほとんどのオーバヘッドはATMスイッチをSNMPで設定する処理にある(switchで表記)。スイッチにもよるが、この処理に要する時間はかなり不安定で、40msecから110msecまで分散する。安定している場合でも40msecから50msecは最低でもかかってしまう。今回利用しているスイッチはこのような使い方を目的として設計されていない。また、スイッチ内部構造の仕様は公開されていないので、この不安定な動作については検討することができない。結果としてスイッチ内部におけるSNMP処理、またはVCセットアップ処理、または両方とも遅い可能性がある。現在の性能では 1秒あたり20から25VCの処理しかできないがスイッチ内部処理の高速化ができれば、かなりの性能向上が得られることが分かる。現在、ASPをハードウェアと統合することを検討しており、1秒あたり数百個のVCを設定することが可能であると予想している。
【００７２】
ここでは AMInet における資源予約プロトコルASPについて述べた。ASPは独自のセットアップ機構を導入し、IPの柔軟性とATMのVCによるQoS保証を統合した。それにより、動的QoS変更、QoSルーティングとの統合、柔軟なセットアップを実現し、プロトタイプ実装により高速セットアップを実現できることも明らかになった。今後は、プロトタイプを独自のスイッチハードウェアと統合、フローアグリゲーションとQoSルーティングの実装を予定している。
【００７３】
図６は、ベストエフォート通信の概念を表している。同図に示すように、VCの各合流点において、複数のVCをマージし、１つのVCに載せ替えていくことにより、最終的に所望の終点ネットワークにパケットを転送することができる。例えば、AAL5レベルでハードウェア的に多重し、複数のVCを流れるセルを１つのVCに載せ替えることができる。
【００７４】
図７は、VC merger２２（判定手段、マージ手段）の動作を示している。コネクション毎にVCを設定すると、大規模なネットワークにおいて、VC数が増大する。そこで、VC merger２２は、同一対地へのAAL５フレームを同一VCへマージする。この例の場合、VCIが３００の２つのAAL5フレームが、VC merger２２において１つのVCに載せ替えられている。
【００７５】
図８は、RFC1483(Multiprotocol Encapsulation over ATM Adaptation Layer 5)におけるLLCカプセル化(LLC Encapsulation)のデータフォーマットの例を示している。LLC,OUI,Ether Typeがヘッダであり、それ以降がデータである。
【００７６】
図９は、ATM Adaptation Layer(AAL)のAAL5 CPCS(Common Part Convergence Sublayer)のデータフォーマットを示している。図９（Ａ）は、最後のセルのフォーマットを表しており、データ＋パディングデータを合わせた計４０バイトのデータの後に、８バイトのトレイラが付けられている。即ち、１バイトのUU(User-to-User Indication),１バイトのCPI(Common Part Indication),２バイトのLength,４バイトのCRC-32より構成されるトレイラが付けられる。図９（Ｂ）は他のセルのフォーマットを表している。この例の場合、４８バイト以下の大きさのセルで構成されている。
【００７７】
図１０は、セルを分割する前のパケットのフォーマットを表している。即ち、パケットは、ヘッダ、ＩＰ、パディングデータ、およびトレイラより構成される。
【００７８】
図１１（Ａ）は、NNI(Network-Network Interface)のフォーマットを示している。最初の１２ビットはVPI(Virtual Path Identifier)であり、次の１６ビットはVCI(Virtual Channel Identifier)である。次の３ビットがPTI(Payload Type Identifier)であり、次の１ビットがCLP(Cell Loss Priority)、次の８ビットがCRC(Cyclic Redundancy Check)である。そして、次の４８バイトがPayloadである。また、図１１（Ｂ）は、UNI(User-Network Interface)のフォーマットを示している。最初の４バイトはGFC(Generic Flow Control)であり、次の８ビットはVPI(Virtual Path Identifier)である。それ以降のフォーマットは、図１１（Ａ）の場合と同様であるのでその説明は省略する。
【００７９】
図１２は、SDH(Synchronous Digital Hierarchy)と各伝送速度の標準を示している。このように、OC-1(Optical Channel-1、光キャリア−レベル１、世界で最初の光速度標準）、OC-1の３倍のOC-3（１５５．５２Ｍｂｐｓ、SDH（Synchronous Digital Hierarchy、同期ディジタル・ハイアラーキ）のSTM-1(Synchronous Transfer Module-1)に相当）、さらに、OC-3の４倍のOC-12（６２２．０８Ｍｂｐｓ）、その２倍のOC-24（１２４４．１６Ｍｂｐｓ）、さらにその２倍のOC-48（２４８８．３２Ｍｂｐｓ）などが標準化されている。
【００８０】
次に、図１３のフローチャートを参照して、ファイバ内、若しくはVP内における同一フレームの先頭セルと最終セルの間隔を一定値以下に抑える処理手順について説明する。最初に、ステップＳ１において、所定のカウンタに所定の値が設定される。次に、ステップＳ２において、いま送出しようとしているフレームの他に、送出すべき優先度の高い他のフレームのセルがあるか否かが判定される。即ち、予約されたトラフィックなどの優先度の高いセルが届いたか否かが判定される。優先度の高い他のフレームのセルがあると判定された場合、ステップＳ４に進み、カウンタ値と送出中のフレームのセル数が等しいか否かが判定される。カウンタ値とセル数が等しくないと判定された場合、ステップＳ５に進み、優先度の高いセルが送出される。
【００８１】
一方、ステップＳ４において、カウンタ値とセル数が等しいと判定された場合、ステップＳ８に進み、残りのセルをどのトラフィックよりも優先的に送出し、処理を終了する。
【００８２】
また、ステップＳ２において、送出すべき優先度の高いセルが存在しないと判定された場合、ステップＳ３に進み、いま送出中のフレームのセルを送出する。ステップＳ３の処理、またはステップＳ５における処理が終了した場合、ステップＳ６に進み、カウンタ値が１だけデクリメントされる。次に、ステップＳ７に進み、セルの送出が終了したか否かが判定される。
【００８３】
セルの送出が終了していないと判定された場合、ステップＳ２に戻り、ステップＳ２以降の処理が繰り返し実行される。一方、セルの送出が終了したと判定された場合、処理を終了する。
【００８４】
以上のようにして、セルが次に到着するVC merger２２において、各フレームの全セルが到着するための時間の期待値を小さくすることができ、VC merger２２あたりのディレイを抑制することができる。また、VC merger２２において、全セルの到着待ちをしているフレームの数の平均値を小さく抑えることができる。これにより、全てのセルが届く時間の最大値を小さく抑えることができるため、タイムアウト値を小さく抑えることができる。また、管理すべきキュー数の平均値や必要なバッファ量を小さく抑えることができる。
【００８５】
また、同一フレームのセルをファイバ内若しくはVP内で連続して送出するようにすることができる。即ち、ベストエフォート用に最低限の帯域を確保し、その帯域の範囲で同一フレームの優先度が等しいセルを１つ１つ連続して送出するようにすることができる。これにより、最終セルが来る前に、他のVPI/VCI、若しくはVCIが到着した場合、受信未完了のフレームを即座に捨てることができるため、管理すべきキューの数の平均値や必要なバッファ容量を小さくすることができる。
【００８６】
また、VPI若しくはVCIの特定のまたは複数のビット値によって、パケットの種類を分類し、パケットの種類に応じてATMスイッチ２１若しくはVC merger２２に異なる動作をさせるようにすることができる。即ち、ベストエフォート・トラフィック用と資源予約トラフィック用のVPI,VCI管理テーブルを別々に持つようにすることができる。例えば、VCI16bitのうちのいずれかのビットのオンまたはオフで、両パケットを区別するようにすることができる。
【００８７】
これにより、資源を予約したトラフィックのセルを容易に判別することができ、連続メディアをはじめ、ジッタを嫌うトラフィックのセルを同一ファイバ若しくはVP内でバッファリングなしで通過させる処理を簡単に実現することができる。
【００８８】
また、バックボーンに使用されているイーサネットの転送可能な最大のパケット長を越えると、パケットが分割されてしまう。そこで、フレームサイズの最大値を、例えば、２０４８バイトとすることができる。この２０４８という値は、図１４に示すグラフから求めることができる。
【００８９】
このグラフは、http://www.nlanr.net/NA/Learn/packetsizes.htmlのURLより取得したもので、１９９７年７月２５日の１６時頃の５分間、米国のMCIのOC3バックボーンにおけるパケット長の分布を示したものである。横軸はパケット長を表し、縦軸は、横軸で表されるパケット長以下のパケットの個数の全パケットの個数に対する比率を表している。例えば、パケット長が１５００バイト以下のパケットの個数は全パケットの個数に対して９９．９９９６パーセント（％）であり、パケット長が２０４８バイト以下のパケットの個数は全パケットの個数の９９．９９９８％となっている。
【００９０】
このように、パケットの最大長を２０４８バイトに制限しても、この影響を受けるパケットはほとんど存在しないことがわかる。これにより、タイムアウト処理に要する時間を短縮することができ、必要なバッファ容量を小さくすることができる。従って、フレームのstore-and-forward処理におけるディレイの最大値を小さく抑えることができ、バッファの管理を容易にすることができる。
【００９１】
次に、図１５および図１６のフローチャートを参照して、タイムアウト処理について説明する。最初に、ステップＳ１１において、到着したセルがフレームの先頭のセルであるか否かが判定される。フレームの先頭のセルであると判定された場合、ステップＳ１２に進み、フレーム用のバッファが用意される。次に、ステップＳ１３において、バッファの先頭に到着時刻が記録され、ステップＳ１４において、図１７に示すように、タイムアウト管理用リストの末尾につながれる。
【００９２】
ステップＳ１４における処理が終了すると、ステップＳ１１に戻り、ステップＳ１１以降の処理が繰り返し実行される。
【００９３】
一方、ステップＳ１１において、到着したフレームのセルが先頭のセルではないと判定された場合、ステップＳ１５に進み、到着したセルがフレームの末尾のセルであるか否かが判定される。フレームの末尾のセルであると判定された場合、ステップＳ１６に進み、タイムアウト管理用リストからそのフレームのバッファが削除される。ステップＳ１６における処理が終了した場合、またはステップＳ１５において、到着したセルがフレームの末尾のセルではないと判定された場合、ステップＳ１１に戻り、ステップＳ１１以降の処理が繰り返し実行される。
【００９４】
次に、図１６のフローチャートを参照して、フレームを破棄する場合の処理手順について説明する。最初に、ステップＳ２１において、所定の変数Ｎに値１を設定する。次に、ステップＳ２２において、タイムアウト管理用リストのＮ番目のバッファに記録されているセルの到着時刻と現在の時刻の差が所定の基準時間を越えているか否かが判定される。
【００９５】
タイムアウト管理用リストのＮ番目のバッファに記録されているセルの到着時刻と現在の時刻の差が所定の基準時間を越えていると判定された場合、ステップＳ２３に進み、Ｎ番目のバッファに対応するフレームが破棄される。次に、ステップＳ２４において、Ｎの値が１だけインクリメントされ、ステップＳ２２に戻り、ステップＳ２２以降の処理が繰り返し実行される。ステップＳ２２において、タイムアウト管理用リストのＮ番目のバッファに記録されているセルの到着時刻と現在の時刻の差が所定の基準時間を越えていないと判定された場合、即ち、タイムアウト処理が不必要なフレームを見つけたところで、その回のタイムアウト処理を終了する。
【００９６】
このように、タイムアウト管理をVC毎ではなく、１つのリストだけで行うことができるようになり、タイムアウト管理のオーバヘッドを小さくすることができる。
【００９７】
次に、図１８のフローチャートを参照して、フレームの最終セルが落ちた場合の処理手順について説明する。最初に、ステップＳ３１において、フレームを構成するセルを受信する。次に、受信中のフレームの大きさが上限を越えたか否かが判定される。受信中のフレームの大きさが上限を越えていないと判定された場合、ステップＳ３１に戻り、ステップＳ３１以降の処理が繰り返し実行される。
【００９８】
一方、受信中のフレームの大きさが上限を越えたと判定された場合、ステップＳ３３に進む。ステップＳ３３においては、すでにそのフレームが破棄されたか否かが判定される。そのフレームが破棄されていないと判定された場合、ステップＳ３４に進み、そのフレームを破棄する。その後、ステップＳ３１に戻り、ステップＳ３１以降の処理が繰り返し実行される。
【００９９】
また、ステップＳ３３において、そのフレームがすでに破棄されていると判定された場合、ステップＳ３５に進み、受信したセルが最終セルであるか否かが判定される。最終セルではないと判定された場合、ステップＳ３６において、そのセルが破棄される。その後、ステップＳ３１に戻り、ステップＳ３１以降の処理が繰り返し実行される。一方、ステップＳ３５において受信したセルが最終セルであると判定された場合、ステップＳ３７において、そのセルを破棄した後、処理を終了する。
【０１００】
例えば、フレームサイズの上限を２ｋＢに設定し、受信中のフレームが上限を越えた場合、最終セルが落ちたものとみなして、そのフレームを破棄し、次に、最終セルを受信するまで、受信した全てのセルを破棄するようにすることができる。
【０１０１】
また、AAL5においては、長さフィールドから本来のセル数を計算し、フレームを構成するセル数と異なる場合、そのセルを破棄するようにすることができる。これにより、それ以上転送しても仕方のないフレームを破棄することができる。
【０１０２】
次に、図１９および図２０のフローチャートを参照して、マージするVCの数の多いものを優先的にマージ処理する処理手順について説明する。まず、図２１に示すように、マージするVCの数毎にリスト［１］を作成する。次に、それらを、マージするVC数の順に並べてリスト［２］を作成する。そして、新しくマージすべきVCができたときは、以下のような処理を行う。
【０１０３】
最初に、ステップＳ４１において、新しいVCをマージするVCの数に応じたリストの末尾に登録する。次に、ステップＳ４２に進み、リスト［２］の先頭から、（マージするVCの数）×（リスト中の要素数）を演算し、演算結果Ａとする。
【０１０４】
ステップＳ４３においては、演算結果Ａがマージ可能なVCの数より大きいかまたは等しいか否かが判定される。演算結果Ａがマージ可能なVCの数より小さいと判定された場合、ステップＳ４４に進み、リスト［２］の次のリストについて、（マージするVCの数）×（リスト中の要素数）を演算し、演算結果Ａとする。次に、ステップＳ４５において、演算結果Ａがマージ可能なVCの数より大きいかまたは等しいか否かが判定される。
【０１０５】
演算結果Ａがマージ可能なVCの数より小さいと判定された場合、ステップＳ４４に戻り、ステップＳ４４以降の処理が繰り返し実行される。一方、ステップＳ４３またはステップＳ４５において、演算結果Ａがマージ可能なVCの数より大きいかまたは等しいと判定された場合、ステップＳ４６に進み、計算を停止し、ステップＳ４７に進む。
【０１０６】
ステップＳ４７においては、新しくVCが登録されたリスト［１］より小さな順位のところで計算が停止したか否かが判定される。新しくVCが登録されたリスト［１］より小さな順位のところで計算が停止していないと判定された場合、ステップＳ４８に進み、新しくVCが登録されたリスト［１］のところで計算が停止されたか否かが判定される。新しくVCが登録されたところで計算が停止されていないと判定された場合、ステップＳ５３に進む。一方、新しくVCが登録されたところで計算が停止されたと判定された場合、ステップＳ４９に進む。
【０１０７】
ステップＳ４９においては、リスト［１］の先頭からマージ可能な範囲のVCが調べられる。そして、ステップＳ５０において、新しく追加されたVCが、マージ可能な範囲に入っているか否かが判定される。新しく追加されたVCが、マージ可能な範囲に入っていると判定された場合、ステップＳ５１に進む。
【０１０８】
ステップＳ５１においては、リスト［２］における次のリスト［１］のVCのうち、マージされていたもののマージが取りやめられる。その後、ステップＳ５２において、新しいVCのマージを開始する命令がVC margerに送られ、処理を終了する。一方、ステップＳ５０において、新しく追加されたVCがマージ可能な範囲に入っていないと判定された場合、処理を終了する。
【０１０９】
ステップＳ５３においては、新しくVCが登録されたリスト［１］より大きな順位のところで、計算が停止したか否かが判定される。新しくVCが登録されたリスト［１］より大きな順位のところで、計算が停止したと判定された場合、ステップＳ５４に進み、リスト［１］の先頭からマージ可能な範囲のVCが調べられる。そして、ステップＳ５５において、いままでマージされていたが、今回からマージができなくなったVCのマージが取りやめられ、新しいVCのマージを開始する命令がVC mergerに送られる。
【０１１０】
ステップＳ５５における処理が終了した場合、または、ステップＳ５３において、新しくVCが登録されたリスト［１］より大きな順位のところで、計算が停止していないと判定された場合、処理を終了する。
【０１１１】
このように、マージするVCの数の多いものを優先的にマージ処理することにより、VCの数を効果的に減少させることができる。
【０１１２】
なお、上記実施の形態においては、本発明をATMネットワークに応用した場合について説明したが、その他のネットワークに本発明を適用することも可能である。
【０１１３】
【発明の効果】
請求項１に記載のパケット伝送制御方法、および請求項２に記載のパケット伝送制御装置によれば、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定し、その判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージするようにしたので、バーチャルコネクションの数を効率的に削減することができる。
【図面の簡単な説明】
【図１】 AMInetアーキテクチャの例を示す図である。
【図２】 AMInetのシステム構成の例を示す図である。
【図３】資源予約要求メッセージを受信側が発行している様子を示す図である。
【図４】 ASPのプロトタイプの構成例を示す図である。
【図５】 ASPの現在の実装における資源予約確立および解除の性能を表す図である。
【図６】ベストエフォート通信の概略を示す図である。
【図７】同一VCにマージする様子を示す図である。
【図８】 RFC1483のLLCカプセル化のデータフォーマットを示す図である。
【図９】 AAL5 CPCSのデータフォーマットを示す図である。
【図１０】セル分割前のフォーマットを示す図である。
【図１１】 NNIおよびUNIのフォーマットを示す図である。
【図１２】 SDHと各伝送速度の標準を示す図である。
【図１３】同一フレームのセルを連続して送出する処理手順を説明するフローチャートである。
【図１４】パケット長の分布を示すグラフである。
【図１５】タイムアウト処理を説明するフローチャートである。
【図１６】タイムアウト処理を説明するフローチャートである。
【図１７】タイムアウト管理用リストの構成例を示す図である。
【図１８】最終セルが落ちたときの処理手順を説明するフローチャートである。
【図１９】マージするVC数の多いものを優先的にマージ処理する手順を説明するフローチャートである。
【図２０】マージするVC数の多いものを優先的にマージ処理する手順を説明するフローチャートである。
【図２１】リスト［１］およびリスト［２］を示す図である。
【符号の説明】
１ 送信側， ２，６ エッジルータ， ３乃至５ ＩＰ， ７ 受信側， ２１ ATスイッチ， ２２ VC merger
【発明の属する技術分野】
本発明は、パケット伝送制御方法および装置に関し、例えば、マージするバーチャルコネクションの数の多いものを優先的にマージするパケット伝送制御方法および装置に関する。
【０００２】
【従来の技術】
ATM(Asynchronous Transfer Mode)を用いて、IP(Internet Protocol)ネットワークを構築するとき、コネクションレスであるIPパケットをいかにしてコネクションオリエンティッドな技術であるATMのVirtual Connection（以下、VCと略記する）で伝送するかが問題となる。
【０００３】
一つの方法として、全ての始点ネットワークから、全ての終点ネットワークに対して、メッシュ状にVCを張り、始点ではIPのパケットを宛先IPアドレスに対応する終点ネットワークにつながるVCに送り込むという方法がある。この方法は、既存の技術のみで簡単にいますぐに実現できるというメリットがあるが、必要なVCの本数がネットワーク数の２乗のオーダになるため、スケーラビリティの問題を抱えている。
【０００４】
スケーラビリティの問題を解決するために、VCをメッシュ状に用意するのではなく、各終点ネットワークから全ての始点に対して、ツリー状にVCを用意する方法が考えられている。このときも、始点では、IPのパケットを宛先IPアドレスに対応するVCに送り込む。そのIPパケットは、ツリーにおけるVCの各合流点において、複数のVCから１つのVCに載せ替えられていき、最終的には期待する終点ネットワークにパケットを転送することができる。この方法によると、パケット転送時の分岐処理を行う必要がないため、ルータでの処理が不要となり、ATMレイヤのみで処理が可能となる。
【０００５】
以下では、複数のVCから流入してくるパケットを１つのVCに載せ替える処理をする装置をVC mergerと呼ぶことにする。VC mergerは、ATM switchに組み込まれていることもあれば、外付けのときもある。複数のVCから流入してくるパケットを１つのVCに載せ替えるとき、ATM上では、IPパケットはそれより小さなセルに分解されて転送されていることが問題となる。
【０００６】
各VC内では、セルは失われることはあっても、順序は保持され、各セルの間に新たなセルが挿入されることもない。IPパケットを複数のセルに載せるときのフォーマットは、それを前提とした簡潔なものになっている。そのため、複数のVCを流れるセルを合流させて１つのVCに載せ替えるとき、セル単位ではなく、IPのパケット単位で処理を行わないと、正しくパケットを転送することができない。また、VC mergingのために利用できるキューの数が、マージ結果のVCの数より少ないとき、早いもの勝ちでマージすべきVCを決めるようにしている。
【０００７】
ATMの転送単位であるセルは、ヘッダ５バイト、データ４８バイトの合計５３バイト固定長である。IPパケットは、ヘッダ２０バイト（オプション込みで最長６０バイト）、データ部を含めた長さは、最長６５５３５バイトの可変長である。データをセルに載せるときのフォーマットをAAL(ATM Adaptation Layer)と呼び、現在、タイプ１、タイプ３／４、およびタイプ５が定義されている。
【０００８】
IPをセルに載せるときは一般的にAAL５が用いられる。処理例は、次の通りである。
【０００９】
まず、第１のステップとして、IPパケットの前後にヘッダ、トレイラをつける。正確には、この処理は、AAL5の範囲外であり、RFC1483に従うことが多い。なお、RFC(Request for Comments)は、インターネットの研究開発機関IETF(Internet Engineering Task Force)がインターネット上のサーバ(http://ds.internic.net/)に公開しているTCP/IP仕様やサービスに関する規格書で内容ごとに通し番号が付されている。
【００１０】
次に、第２のステップとして、それに、AAL5 CPCS(Common Part Convergence Sublayer)と呼ばれる方式でトレイラが付けられる。トレイラには、長さ情報、３２ビットのCRC(cyclic redundancy check)も含まれている。この結果、全体の長さが４８バイトの倍数になる。これを、以下ではフレームと呼ぶことにする。次に、第３のステップとして、このフレームを４８バイトずつATMセルに載せていく。
【００１１】
フレームの末尾を載せるセル中の、あるビット（正確には、PTIのUser Signaling Bit)を１にする。それ以外のセルでは、そのビットは０とする。以上の処理において、正確には第２のステップおよび第３のステップにおける処理が、AAL5のための処理である。
【００１２】
ATMのセル列から、AAL5のフレームを取り出す処理の例は、次の通りである。まず、AAL5フレームの最終セルであることを示すビットの立っているセルが来るまで、セルのデータをバッファにためる。次に、長さとCRCをチェックし、異常があれば、そのフレームを破棄する。異常がなければ完了する。
【００１３】
IPをATMに載せるとき、最大IP長を制限することが多い。このとき、RFC1626に従い、最大IP長を９１８０バイトにすることが多い。ATMセルのヘッダには、１２ビット若しくは８ビットのVPI(Virtual Path Identifier)と、１６ビットのVCI(Virtual Channel Identifier)が書かれている。ATMスイッチは、複数の入出力ポートを有しており、入力ポートにおいて、VPI,VCIをキーにして、行き先テーブルを引き、出力ポートと新しいVPI,VCIを得る。一般にVPI,VCIは行き先テーブルの配列の添え字として用いられる。次に、セルのヘッダ中のVPI,VCIフィールドを書き換え、指定された出力ポートに転送する。出力ポートでは、出力すべくキューにたまっているセルの優先度その他を参考にしながら、セルを出力していく。場合によっては、VPIのみを見て、VPIのみを書き換えながら、セルを転送することがある。VPIのみで転送する経路をVirtual Path(VP)と呼ぶ。
【００１４】
ATMスイッチ間は、光ファイバで結ばれることが多い。１００Ｍｂｐｓ（メガビット／秒）のイーサネット(100BASE-TX)のMTU（Maximum Transfer Unit：最大転送可能パケットサイズ）は、１０Ｍｂｐｓのイーサネットの場合と同様に１５００バイトである。Gigabit EthernetのMTUも１５００バイトである。ただし、Gigabit Ethernetでは、約９０００バイトのパケットを転送することもできる。100BASE-TXの場合においても、約９０００バイトのパケット転送ができるようにしようという提案がされている。従って、当面は、現実的なパケットサイズの上限は、１５００バイトであるが、将来、約９０００バイトのパケットが広く利用される可能性がある。
【００１５】
【発明が解決しようとする課題】
しかしながら、バーチャルコネクション(VC)のために利用可能なキューの数が実装上の制約により、マージすべきVCの数より少ないとき、早い者勝ちでマージ処理すべきVCが決められていた。このため、VCの数を効率的に削減できない課題があった。
【００１６】
本発明はこのような状況に鑑みてなされたものであり、VCの数を効率的に削減することができるようにするものである。
【００１７】
【課題を解決するための手段】
請求項１に記載のパケット伝送制御方法は、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定する判定ステップと、判定ステップにおける判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージするマージステップとを備えることを特徴とする。
【００１８】
請求項２に記載のパケット伝送制御装置は、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定する判定手段と、判定手段による判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージするマージ手段とを備えることを特徴とする。
【００１９】
請求項１に記載のパケット伝送制御方法および請求項２に記載のパケット伝送制御装置においては、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定し、その判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージする。
【００２０】
【発明の実施の形態】
まず最初に、本出願人らが開発している広域高速ネットワーク環境を提供するAMInetについて説明する。
【００２１】
AMInetは、既存のネットワークアーキテクチャがもつ問題を解決する次世代ネットワークアーキテクチャである。コネクション指向のQoS(Quality of Service)保証、マルチキャストのサポート、識別子とアドレスの分離、非エンド間制御、ネゴシエーションによる最適プロトコルスタックの動的構築などを特徴とする。AMInetアーキテクチャに基づくネットワークはFTTH(Fiber To The Home)時代を見据え、広域バックボーンのみならず家庭内ネットワークをも対象としている。
【００２２】
現在、通信と放送の融合を目指した新しいネットワークアーキテクチャが求められている。OSI(Open Systems Interconnection)参照モデルやインターネットアーキテクチャは約20年前に設計されたものであり、動画や音声などの連続メディア通信実現への要求、携帯型コンピュータの出現による移動透過な通信への要求、ATM(Asynchronous Transfer Mode:非同期転送モード)に代表される超高速通信技術の有効利用などに対応することができない。
【００２３】
インターネットではこれらに対処するための拡張が行われているが、インターネットアーキテクチャには、
- IP(Internet Protocol)データグラムを基本とし、
- データリンクの特性を考慮せず、
- 識別子とアドレスの明確な分離がなされず、
- エンドノード間でのみトラフィック制御を行う
という問題点があり、上記の問題を解決することができない。
【００２４】
インターネットへの接続形態の現状を見ると、大企業は専用線によりインターネットに常時接続しているが、小企業や家庭はダイヤルアップによる間欠接続を利用している。常時接続の場合でも回線速度は1.5Mbps（メガビット／秒）程度であり、間欠接続の場合は128kbps（キロビット／秒）程度である。接続形態が間欠接続から常時接続になるだけでも、家庭等におけるインターネットの利用形態は大きく変化する。さらに回線速度が桁違いに速くなれば、今では想像もできないようなアプリケーションが登場するであろう。
【００２５】
AMInetアーキテクチャは、FTTH(T. Miki.Toward the Service-Rich Era.IEEE Communications Magazine, Vol.32, No.2, February 1994)やxDSL(G. T. Hawley.Systems Considerations for the Use of xDSL Technology for Data Access.IEEE Communications Magazine, Vol.35, No.3, March 1997)の実現によって家庭や企業が超高速ネットワークに対称／準対称型で常時接続される時代を見据え、インターネットアーキテクチャが持つ本質的な問題点を解決するものである。以下に、AMInetアーキテクチャおよびシステムモデルを示す。
【００２６】
今後は、動画や音声のような連続メディアを利用したアプリケーションがますます増えると考えられる。技術的には、利用できる帯域幅、伝送遅延、伝送遅延のばらつき(ジッタ)、エラー率のようなサービス品質(QoS)の保証を可能にしなければならない。
【００２７】
一方、医療用イメージ、新聞、映画フィルム全体のような大量データ転送への要求も今後高まることが予想される。このようなアプリケーションではできるだけ高速にデータ転送をしなければならない。技術的には、いわゆる”long fat pipe”問題を解決し、超高速ネットワークの帯域を有効に利用する技術を開発する必要がある。
【００２８】
現在の通信形態はほとんどが1対1通信である。今後は同一データの複数相手への送信(マルチキャスト)、移動体との移動透過な通信なども必要となる。アーキテクチャとしては識別子とアドレスの関係をどのように扱うかという問題があり、技術的にはスケーラブルな経路制御方式を確立する必要がある。さらにQoSの保証や高速大容量通信も要求される。
【００２９】
コンピュータネットワークが真に通信のインフラストラクチャとなるためには強固なセキュリティを実現しなければならない。AMInetではノード間における守秘、改竄防止、認証、トラフィック解析防止を対象とする。利用者認証などはアプリケーションプログラムの範疇であり、AMInetの対象外である。
【００３０】
以上のような特徴を持つネットワークを構築しても、インターネットと互換性がなくてはユーザをスムーズに移行させることはできない。ユーザからは実際のネットワークがAMInetであるのか既存のインターネットであるのかを意識させないようにする必要がある。
【００３１】
次に、AMInetアーキテクチャの特徴について説明する。上述したインターネットアーキテクチャの欠点に対比すると、AMInetアーキテクチャの特徴は以下のようになる。
- 最適なプロトコルスタックの動的構築
- ノード間の同位階層間およびノード内の上下階層間のネゴシエーション
- コネクション指向のQoS保証
- ノードの識別子とアドレスの分離
- 非エンド間制御
- 通信媒体に依存しないアーキテクチャ
【００３２】
OSIの階層モデルに従うと、ある階層はその下の階層の機能を抽象化し、詳細を隠蔽してしまう。現実の広域ネットワークは異なった特性をもつさまざまなデータリンクから構成されている。また移動ノードの場合、データリンクの特性が通信中に変化することもある。上下階層間のネゴシエーションにより、上位層は下位層の特性や状態を知ることができ、通信環境に動的に適応できるようになる。
【００３３】
プロトコルスタックが固定だと、異なる階層で重複した機能を実行して無駄が生じることがある。AMInetでは最適なプロトコルスタックを動的に構築する。たとえばエンドノード間のすべてのデータリンクが信頼性を保証するなら、トランスポート層で信頼性を保証するための機能を省略することができる。また、無線LANで接続しているノードが広域ネットワーク内の他のノードと通信する場合のように、通信経路においてある一部分だけデータリンクの特性が異なる場合、そのデータリンクの両側のノードだけに特別のプロトコルスタックを構成し、データリンクの特性の違いを吸収することにより、エンド間の通信を効率よく行うことも可能になる。
【００３４】
最適なプロトコルスタックを構築するためにはネゴシエーションを利用する。通常、ネゴシエーションはノード間の同位階層間で行うが、AMInetではノード内の上下階層間でもネゴシエーションを行う。
【００３５】
インターネットはIPデータグラムを基本としており、QoSを保証する場合でもネットワーク層において明確に論理コネクションを確立するという考えはない。これはネットワークの障害への耐故障性を重視するためである。これに対してAMInetではQoSの保証を重視し、QoSを保証するために、論理コネクションを積極的に利用する。
【００３６】
インターネットではIPアドレスがノードの位置を表すとともにノードの識別子の役割も果たしている。このために移動ノードとの移動透過な通信ができない。またセキュリティを確保するための処理も煩雑になる。次世代IPであるIPv6においてもノード識別子についてさかんに議論が行われたが、結局ノード識別子という考え方は採用されていない。AMInetではノードの識別子とアドレスを明確に分離することにより、移動透過な通信(F. Teraoka, K. Uehara, H. Sunahara, and J. Murai.VIP: A Protocol Providing Host Mobility.CACM, Vol.37, No.8, August 1994)を可能にし、セキュリティ処理を軽減する。
【００３７】
さらにインターネットではフロー制御、エラー回復、輻輳制御などをエンドノードのトランスポート層で行う。輻輳制御の場合、輻輳が発生しているノード(ルータ)と送信ノードの間で輻輳回復を行う方が効果的だと考えられる。
【００３８】
AMInetとインターネットに共通しているのは、アーキテクチャをデータリンクから独立させるため、すべてのノードが共通してもつ階層を導入していることである。インターネットとの互換性を保つため、実質的にはAMInetでもIP(v4およびv6)をいわゆるネットワーク層として採用する。ただしプロトコルスタックの動的な構築により、データ通信の際にはIP層はバイパスされることもある。
【００３９】
次に、プロトコル階層について説明する。AMInetは動的にプロトコルスタックを構築するが、プロトコルモジュールを機能別に階層化すると図１のようになる。最下位層はダイレクトネットワーク層である。単一の伝送媒体を介して”ダイレクト”に通信できるノード間の通信機能を提供する層である。OSI参照モデルの物理層とデータリンク層に相当する。具体的にはEthernetやATMなどのプロトコルがこの層に対応する。
【００４０】
図１はAMInetアーキテクチャを表しており、ダイレクトネットワーク層の上に仮想ネットワーク層を置く。複数の伝送媒体からなるネットワークを”仮想的”に１つの伝送媒体のように見せ、これに接続しているノード間の通信機能を提供する。プロトコルスタックの動的構築はこの階層内で行われる。OSI参照モデルのネットワーク層とトランスポート層に相当する。
【００４１】
仮想ネットワーク層の上にセッション層を置く。セッション層は仮想ネットワーク層が提供する通信機能を抽象化して最上位層であるアプリケーション層に提供する。OSI参照モデルのセッション層とは機能が異なる。抽象化とは、QoSパラメータを”テレビ品質の動画”のように数値以外で指定可能にしたり、通信相手をノードのアドレスや識別子ではなく、サービス名で指定可能にしたり、仮想ネットワーク層のコネクションが障害やノードの移動などで一時的に切断されたときも、あたかもコネクションが連続して存在するように見せることをいう。最上位のアプリケーション層はAMInetプロジェクトの対象外である。
【００４２】
図１において、水平矢印は同位階層間のネゴシエーションを、垂直矢印は上下階層間のネゴシエーションを示す。同位階層間ネゴシエーションには、エンドノード間で行われるセッションネゴシエーションおよびフローネゴシエーション、隣接ノード間で行われるホップ間ネゴシエーションがある。上下階層間ネゴシエーションには、上位層から下位層への要求を伝えるリクエストと、下位層の状態を上位層へ伝えるインディケーションがある。このようなネゴシエーションにより、エンドノード間の通信環境やダイレクトネットワーク層の特性を知り、最適なプロトコルスタックを構築する。
【００４３】
次に、システム構成について説明する。AMInetは広域ネットワークのみではなく、家庭内ネットワークも考慮している。AMInetプロジェクトが想定しているシステム構成を図２に示す。同図に示すように、全体のネットワークはバックボーン、ホームネットワーク、これらを接続する加入者ネットワークという３つの部分に分けられる。
【００４４】
図２は、AMInetのシステム構成の例を表している。バックボーンは日本全国を覆うような大規模なものを想定しており、ATMの超高速通信技術を活用する。バックボーンとなるATM網はATMスイッチ（と光ファイバ）で構成されるが、ATMスイッチのうち、高速シグナリング等のAMInet独自の機能拡張をしたものをバックボーンルータと呼ぶ。
【００４５】
バックボーンの周辺にはエッジルータを置く。エッジルータはバックボーンルータと同様にATMスイッチにAMInet独自の機能拡張を行ったものである。エッジルータは加入者線を集線してバックボーンへと接続する位置にあり、加入者の課金やホームネットワークからバックボーンへ流入するトラフィックのシェーピングも行う。加入者線としてはFTTHによって光ファイバが布設されるか、あるいは銅線を利用したADSL(Asymmetric digital subscriber line)のような技術が利用されるかもしれない。どちらの場合でも家庭までATMネットワークが届くものと考えられる。
【００４６】
家庭にはホームルータを置く。ホームルータは外部ネットワークインターフェイスとしてATMを持ち、内部ネットワークインターフェイスとしてはIEEE1394やイーサーネット(10Mbps/100Mbps)などを持つものと想定している。IEEE1394は帯域確保などのQoS保証が可能なので、エンドノード間でQoSを保証した通信が可能になるなどの利点を持つ。また将来はAV機器がIEEE1394を装備するようになるので、コンピュータのみならずAV機器もネットワークに接続されるようになるであろう。
【００４７】
次に、AMInet におけるATMとIPの統合によるリアルタイム通信の実現(ATM Control through IP for Real-Time Communication in AMInet)について説明する。ここでは、AMInetプロジェクトが前提としているバックボーン、および家庭を接続する広域ネットワークで利用される資源予約セットアッププロトコルASP (AMInet Set up Protocol) について述べる。ASPは、IPの柔軟性および適応性、また回線指向型データリンクであるATMに注目し、それらを統合することによって、高速で柔軟な資源予約を実現することを目的としている。ASPは、通常のATMのシグナリングは利用せず、IPによって転送されるメッセージを利用してATM VCを動的に確立する。ここでは、ASPの特徴、現在のプロトタイプの実装、QoSルーティングとの統合について述べる。
【００４８】
FTTH (Fiber to the Home)やxDSL(digital subscriber line)技術の進歩により、家庭でもダイアルアップとは異なる、常時接続されている高速ネットワークを利用できるようになる。このような環境ではIntegrated Services (IS)、または大容量ファイル転送などのアプリケーションを効率良く実現する必要がある。特に、ISの実現のためには資源予約が有効である。資源予約を導入することによってネットワークはQoS (Quality of Service)を保証することができる。また、バルクデータ転送アプリケーションの場合、 TCPの機能を拡張して効率良くネットワーク自身を利用することも可能になる。
【００４９】
ここでは、広域高速ネットワーク環境を提供するAMInetにおける資源予約プロトコル:AMInet Set up Protocol(ASP)について述べる。ASPは、資源予約機能を提供するために、ATM VC技術とIPを効果的に統合する。また、高速資源予約および動的QoS変更にも対応し、QoSルーティングとの統合も考慮する。
【００５０】
次に、資源予約について説明する。インターネットでは、ISに対応するため資源予約は今後必須になる。資源予約の導入はもともとパケット交換であるインターネットにコネクションの概念を導入することになる。その結果、データリンクとしてATMを利用することは整合がよく、ATMによってQoSの保証も容易にできる。
【００５１】
AMInetでもATMに注目し、IPのデータリンクの１つとして扱っている。本稿では主にATMを用いた実現に関して述べる。現在、インターネットの標準化団体であるIETFでは、RSVP(Resource Reservation Protocol)を資源予約プロトコルとしてproposed standardの標準化を行っている。しかし、RSVPを利用した場合、現在規定されているインターネットドラフトではATMのSVC(Switched Virtual Channel)を利用した形態を前提としている。したがって、ATMシグナリングを利用してVC(Virtual Channel)を確立する必要がある。しかし、現在のATMシングナリング処理は重く、時間がかかるため、アプリケーション、およびネットワークにも悪影響を及ぼす可能性が高い。中には、シングナリングに必要な処理を分割し、並列に処理するシステムも提案されている。
【００５２】
その他にも同時に複数の経路に沿って資源予約を行い、クランクバックによるオーバーヘッドを削減するための研究もある。現状で、一般に購入できるATMスイッチではSVCを利用するとシグナリングの処理時間は通常のIPなどのデータ通信では利用できないオーダーになってしまう。これは主にATMスイッチは音声データ、すなわち、従来の電話におけるコネクション確立時間を基準として設計されたところにある。また現在のシングナリングを利用するだけでは動的にQoSを変更することはできない。
【００５３】
AMInetでは、上記の問題点を解決するため柔軟性の高いIPをセットアップメッセージの転送に利用し、ATM VCを直接確立することにより QoSを保証する。
【００５４】
AMInet Set up Protocol (ASP) は、広域ネットワーク、特に AMInetアーキテクチャに基づくルータからなる環境で動作する資源予約セットアッププロトコルである。AMInet はATMスイッチング機能をもつルータからなり、バックボーンとその境界にあるエッジルータから構成されている。予約する資源は、ATM VC、またはパケット処理時に利用されるキューなどである。特にATMとの統合の場合、通常のATMシグナリングを利用せず、ATMスイッチまたはATM機能をもつルータにおいてVCを確立する。IPを使ってセットアップメッセージを転送するので、高速資源予約が実現できる。したがって、通常、ATMスイッチではSVCと呼ばれるVCは全く利用せず、IPを利用したメッセージによって、VCを動的に確立する。このようなVCのことをPVC-on-demandと呼ぶ。ASPを利用することによって通常のSVCとは異なる形態でVCを動的に確立、または切断できる。
【００５５】
ASPを利用する場合でもデータは通常のIPで転送される。そこで、IPパケットは特定の予約された資源にマッピングされる。そのため、今まで利用されてきたアプリケーションから今後出て来る可能性のある新しいアプリケーションにもASPは簡単に対応できる。このマッピングは、ソースとデスティネーションIPアドレス、ソースとデスティネーションポート番号、およびプロトコル識別子フィールドなどを参照することによって行われる。通常のIPトラフィック、すなわちベストエフォートトラフィック(BE)は、あらかじめ設定されたデフォルトBE VCを通して転送される。ASPを使って予約された資源はBEトラフィックによって影響されない。また、資源の節約などを考えて１つのVCにまとめられたフローも、BEトラフィックに影響されず共存できる。
【００５６】
次に、柔軟なセットアップ機構について説明する。ASPでは効率良く資源を利用するために、またはアプリケーションの要求にあった予約を行うため、さまざまな形態で資源を予約できる。インターネットやATM環境ではではさまざまな種類のアプリケーションが存在する。テレビ会議、遠隔診断、ビデオオンデマンド (VoD)、MBoneを利用するマルチキャストアプリケーションなどの放送型のものから双方向にデータを送信する対話型のものがある。いずれの場合も、QoSパラメータを下位層の資源予約パラメータに効率良く、かつスケーラブルにマッピングする必要がある。
【００５７】
例えば、VoD の場合、サーバとクライアントの間においてVCを双方向に確立する必要はない。データは必ずサーバからクライアントに向かって流れるからである。ASPを用いた場合、ASP固有のメッセージのやりとり、アプリケーションが必要とするデータ転送以外の制御のやりとり(VoDの場合だと見る映画を途中で変更するためのクライアント側からの要求など)、さらに上位層（例えば、トランスポート層）などが必要とするやりとりは、他の専用VCを利用してもよいが、デフォルトBE VCを利用するだけでよい。ASPメッセージはデフォルトBE VCまたは指定された専用VCを通して転送される。
【００５８】
一方、対話型であるテレビ会議アプリケーションの場合は双方向VCが必要である。ASPは一方向、双方向の両方に対応している。さらに、対話型の場合、上流と下流トラフィックに対して、異なるQoSを設定できる非対象なモデルをサポートする。
【００５９】
ASPではRSVPまたはST-2+(Stream Transport Protocol-2+)の場合と同様に、資源予約要求は受信側からも可能である上、送信側からの発行も可能である。アプリケーション、または環境に応じて、資源予約を行う際に必要なQoS情報を送信側が持っている場合と、受信側が持っている場合がある。どちらの場合でも、ASPでは１パスで全ての予約を行うように設定できる。さらに、必要に応じて予約が完了したことを伝える応答メッセージを待つことも可能である。
【００６０】
図３に一般的な資源予約要求メッセージを受信側が発行している例を示す。これは、ビデオの放送型アプリケーションなどがASPを利用した場合を表す。すなわち、データはサーバ（送信側）１からクライアント（受信側）７の方向にしか転送されない。
【００６１】
受信側７では、まずQoSパラメータが解釈され、このコネクションで用いられるVPI/VCIを決定し、必要に応じてATM NIC(Network Interface Card)を設定する。またこの情報を含む ASPメッセージを作成し、バックボーンに隣接しているエッジルータに向けてこのメッセージを転送する。このメッセージはIPで転送され、IPのホップ毎に処理される。図３の例の場合、エッジルータにメッセージが届くと、ルータでは受信側に向けてVPI/VCIパラメータを設定する。VPI/VCIは各ノードで個別に管理されている。このようにASPメッセージは送信者１に向かって上流に転送され、各ルータ２乃至６では、このメッセージが転送される方向と逆方向に向けてVCが設定される。図には示されていないが、送信側１にメッセージが転送され、予約が実質的に完了すると、必要に応じて、受信側７に対して返答メッセージが転送される。この時点で、最低限バックボーンにおいては、送信側１から受信側７に向けてVCが確立される。すなわち、エッジを結ぶこのVCを利用することによって、データ転送時にIPをカットスルーし、ATMのみで通信できる。
【００６２】
図３はASPにおける柔軟なセットアップの一形態しか表していない。例えば、送信側１のみがQoS情報をもっていて、しかもマルチキャストアプリケーションで受信側７から予約要求を発行する場合、上記の例の返答が返る第２パスでVCの設定を行うようにメッセージを作成できる。さらに、双方向のVCを第１パスのみで確立してしまうことも可能となる。
【００６３】
次に、動的QoS変更について説明する。ASPでは独自のセットアップ機構によりATM VCを確立するので予め他のVCを用意する必要がなく、既に予約された資源のQoSを動的に変更できる。また、アプリケーションは簡単にサービスレベルをアップグレードすることもできる。例えば、単純にBEからISに移行する場合、データフローはデフォルトBE VCから図３などに示す新たなVCにマップし直すことも容易にできる。
【００６４】
次に、QoSルーティングとの統合について説明する。ASPでは、VCセットアップ時にQoSルーティングによる経路選択のサポートが考慮されている。具体的には、資源を予約する時に、従来のIPレベルでのルーティングテーブルを利用するのではなく、ISを必要とするフローのための独自ルーティングテーブルを管理するモジュールより経路情報の提供を受ける。これにより、QoS要求やネットワークの利用可能な資源状況に合わせて、フロー毎に異なる経路を利用できる。
【００６５】
また、従来の資源予約プロトコルとルーティング機構はそれぞれ独立したものを前提として考えられてきたが、ASPではQoSルーティングとの統合を目指している。これは、QoSルーティングのモジュールに対して、ASPが保持している資源予約情報をフィードバックすることによって行う。これにより、予約が失敗した場合の代替経路の選択が容易になる。また、予約する資源をネットワーク中に分散させることができ、１つの経路に資源予約を集中させることなくネットワーク全体を効率良く利用できる。
【００６６】
次に、プロトタイプ実装について説明する。ASPは、UNIXのデーモンプロセス(aspd)としてユーザ空間で実装されている。プロトタイプはFreeBSD 2.2.1で動作中であり、ATMスイッチを制御するためのライブラリ(swctl lib)とATM NICの設定を行うモジュール(afmap)と統合されている (図４参照)。現在、3つのタイプのルータがサポートされており、ホームルータは100Base-T EthernetとATMインタフェースをもつ。エッジルータは現在は複数のATMインタフェースをもつルータとして実現されている。バックボーンルータは、ATMスイッチとそれを制御するためのIPエンジンを含むPCからなる。現在のプロトタイプでは、Adaptec社とEfficient Networks社のPCIバス用ATMインタフェースカードと、Fore ASX-200WG ATMスイッチを利用している。ASP メッセージは raw IPを使って実装されている。
【００６７】
バックボーンルータは、装備されているスイッチにおいてPVC-on-demandを設定するため前述したスイッチ制御ライブラリを利用する。ISを必要とするIPフローはCBRのVCにマッピングされる。また、現在、ASPはATMスイッチで一対多のマルチキャストVCを作成することによって、マルチキャストに対応している。リーフによるジョイン、および資源予約もサポートしている。
【００６８】
VCIなどの識別子をはじめとするATM資源のスケーラビリティを考慮すると、IPフローをアプリケーション単位でVCにマッピングすることは効率が悪い。ASP を利用することにより、動的にフローをVCにまとめることが容易になる。しかし、フローをVCにまとめる基準については今後検討する必要がある。
【００６９】
最後に QoSルーティングモジュールについては、現在設計中であり、シミュレーションを通してその有効性を検討している。
【００７０】
次に、プロトタイプの性能について説明する。図５に、ASPの現在の実装における資源予約確立および解除の性能を示す。asp_openが資源予約要求を発行し、正常終了した場合に要する時間を表す(予約が成功したことに対して返答を待つ時間まで含まれる)。asp_closeは、その反対で予約を解除するための時間を示す。これらの測定は単一送信者および受信者の間にルータを１つ設けた際の受信側から各々の要求をユニキャスト通信に対して発行した場合を表す。送信者と受信者は各々ATM NICを装備していて、図の中のASPと表記されている時間には、ASPに必要な処理およびNICに対してフローをマップする作業も含まれる。swctl_libは、前節で述べたATMスイッチ制御ライブラリにおいて必要な処理時間を示す。また、switchは、ATMスイッチ制御ライブラリを用いてATMスイッチをSNMPで設定するために必要な時間を表す。
【００７１】
図５から分かるように、ほとんどのオーバヘッドはATMスイッチをSNMPで設定する処理にある(switchで表記)。スイッチにもよるが、この処理に要する時間はかなり不安定で、40msecから110msecまで分散する。安定している場合でも40msecから50msecは最低でもかかってしまう。今回利用しているスイッチはこのような使い方を目的として設計されていない。また、スイッチ内部構造の仕様は公開されていないので、この不安定な動作については検討することができない。結果としてスイッチ内部におけるSNMP処理、またはVCセットアップ処理、または両方とも遅い可能性がある。現在の性能では 1秒あたり20から25VCの処理しかできないがスイッチ内部処理の高速化ができれば、かなりの性能向上が得られることが分かる。現在、ASPをハードウェアと統合することを検討しており、1秒あたり数百個のVCを設定することが可能であると予想している。
【００７２】
ここでは AMInet における資源予約プロトコルASPについて述べた。ASPは独自のセットアップ機構を導入し、IPの柔軟性とATMのVCによるQoS保証を統合した。それにより、動的QoS変更、QoSルーティングとの統合、柔軟なセットアップを実現し、プロトタイプ実装により高速セットアップを実現できることも明らかになった。今後は、プロトタイプを独自のスイッチハードウェアと統合、フローアグリゲーションとQoSルーティングの実装を予定している。
【００７３】
図６は、ベストエフォート通信の概念を表している。同図に示すように、VCの各合流点において、複数のVCをマージし、１つのVCに載せ替えていくことにより、最終的に所望の終点ネットワークにパケットを転送することができる。例えば、AAL5レベルでハードウェア的に多重し、複数のVCを流れるセルを１つのVCに載せ替えることができる。
【００７４】
図７は、VC merger２２（判定手段、マージ手段）の動作を示している。コネクション毎にVCを設定すると、大規模なネットワークにおいて、VC数が増大する。そこで、VC merger２２は、同一対地へのAAL５フレームを同一VCへマージする。この例の場合、VCIが３００の２つのAAL5フレームが、VC merger２２において１つのVCに載せ替えられている。
【００７５】
図８は、RFC1483(Multiprotocol Encapsulation over ATM Adaptation Layer 5)におけるLLCカプセル化(LLC Encapsulation)のデータフォーマットの例を示している。LLC,OUI,Ether Typeがヘッダであり、それ以降がデータである。
【００７６】
図９は、ATM Adaptation Layer(AAL)のAAL5 CPCS(Common Part Convergence Sublayer)のデータフォーマットを示している。図９（Ａ）は、最後のセルのフォーマットを表しており、データ＋パディングデータを合わせた計４０バイトのデータの後に、８バイトのトレイラが付けられている。即ち、１バイトのUU(User-to-User Indication),１バイトのCPI(Common Part Indication),２バイトのLength,４バイトのCRC-32より構成されるトレイラが付けられる。図９（Ｂ）は他のセルのフォーマットを表している。この例の場合、４８バイト以下の大きさのセルで構成されている。
【００７７】
図１０は、セルを分割する前のパケットのフォーマットを表している。即ち、パケットは、ヘッダ、ＩＰ、パディングデータ、およびトレイラより構成される。
【００７８】
図１１（Ａ）は、NNI(Network-Network Interface)のフォーマットを示している。最初の１２ビットはVPI(Virtual Path Identifier)であり、次の１６ビットはVCI(Virtual Channel Identifier)である。次の３ビットがPTI(Payload Type Identifier)であり、次の１ビットがCLP(Cell Loss Priority)、次の８ビットがCRC(Cyclic Redundancy Check)である。そして、次の４８バイトがPayloadである。また、図１１（Ｂ）は、UNI(User-Network Interface)のフォーマットを示している。最初の４バイトはGFC(Generic Flow Control)であり、次の８ビットはVPI(Virtual Path Identifier)である。それ以降のフォーマットは、図１１（Ａ）の場合と同様であるのでその説明は省略する。
【００７９】
図１２は、SDH(Synchronous Digital Hierarchy)と各伝送速度の標準を示している。このように、OC-1(Optical Channel-1、光キャリア−レベル１、世界で最初の光速度標準）、OC-1の３倍のOC-3（１５５．５２Ｍｂｐｓ、SDH（Synchronous Digital Hierarchy、同期ディジタル・ハイアラーキ）のSTM-1(Synchronous Transfer Module-1)に相当）、さらに、OC-3の４倍のOC-12（６２２．０８Ｍｂｐｓ）、その２倍のOC-24（１２４４．１６Ｍｂｐｓ）、さらにその２倍のOC-48（２４８８．３２Ｍｂｐｓ）などが標準化されている。
【００８０】
次に、図１３のフローチャートを参照して、ファイバ内、若しくはVP内における同一フレームの先頭セルと最終セルの間隔を一定値以下に抑える処理手順について説明する。最初に、ステップＳ１において、所定のカウンタに所定の値が設定される。次に、ステップＳ２において、いま送出しようとしているフレームの他に、送出すべき優先度の高い他のフレームのセルがあるか否かが判定される。即ち、予約されたトラフィックなどの優先度の高いセルが届いたか否かが判定される。優先度の高い他のフレームのセルがあると判定された場合、ステップＳ４に進み、カウンタ値と送出中のフレームのセル数が等しいか否かが判定される。カウンタ値とセル数が等しくないと判定された場合、ステップＳ５に進み、優先度の高いセルが送出される。
【００８１】
一方、ステップＳ４において、カウンタ値とセル数が等しいと判定された場合、ステップＳ８に進み、残りのセルをどのトラフィックよりも優先的に送出し、処理を終了する。
【００８２】
また、ステップＳ２において、送出すべき優先度の高いセルが存在しないと判定された場合、ステップＳ３に進み、いま送出中のフレームのセルを送出する。ステップＳ３の処理、またはステップＳ５における処理が終了した場合、ステップＳ６に進み、カウンタ値が１だけデクリメントされる。次に、ステップＳ７に進み、セルの送出が終了したか否かが判定される。
【００８３】
セルの送出が終了していないと判定された場合、ステップＳ２に戻り、ステップＳ２以降の処理が繰り返し実行される。一方、セルの送出が終了したと判定された場合、処理を終了する。
【００８４】
以上のようにして、セルが次に到着するVC merger２２において、各フレームの全セルが到着するための時間の期待値を小さくすることができ、VC merger２２あたりのディレイを抑制することができる。また、VC merger２２において、全セルの到着待ちをしているフレームの数の平均値を小さく抑えることができる。これにより、全てのセルが届く時間の最大値を小さく抑えることができるため、タイムアウト値を小さく抑えることができる。また、管理すべきキュー数の平均値や必要なバッファ量を小さく抑えることができる。
【００８５】
また、同一フレームのセルをファイバ内若しくはVP内で連続して送出するようにすることができる。即ち、ベストエフォート用に最低限の帯域を確保し、その帯域の範囲で同一フレームの優先度が等しいセルを１つ１つ連続して送出するようにすることができる。これにより、最終セルが来る前に、他のVPI/VCI、若しくはVCIが到着した場合、受信未完了のフレームを即座に捨てることができるため、管理すべきキューの数の平均値や必要なバッファ容量を小さくすることができる。
【００８６】
また、VPI若しくはVCIの特定のまたは複数のビット値によって、パケットの種類を分類し、パケットの種類に応じてATMスイッチ２１若しくはVC merger２２に異なる動作をさせるようにすることができる。即ち、ベストエフォート・トラフィック用と資源予約トラフィック用のVPI,VCI管理テーブルを別々に持つようにすることができる。例えば、VCI16bitのうちのいずれかのビットのオンまたはオフで、両パケットを区別するようにすることができる。
【００８７】
これにより、資源を予約したトラフィックのセルを容易に判別することができ、連続メディアをはじめ、ジッタを嫌うトラフィックのセルを同一ファイバ若しくはVP内でバッファリングなしで通過させる処理を簡単に実現することができる。
【００８８】
また、バックボーンに使用されているイーサネットの転送可能な最大のパケット長を越えると、パケットが分割されてしまう。そこで、フレームサイズの最大値を、例えば、２０４８バイトとすることができる。この２０４８という値は、図１４に示すグラフから求めることができる。
【００８９】
このグラフは、http://www.nlanr.net/NA/Learn/packetsizes.htmlのURLより取得したもので、１９９７年７月２５日の１６時頃の５分間、米国のMCIのOC3バックボーンにおけるパケット長の分布を示したものである。横軸はパケット長を表し、縦軸は、横軸で表されるパケット長以下のパケットの個数の全パケットの個数に対する比率を表している。例えば、パケット長が１５００バイト以下のパケットの個数は全パケットの個数に対して９９．９９９６パーセント（％）であり、パケット長が２０４８バイト以下のパケットの個数は全パケットの個数の９９．９９９８％となっている。
【００９０】
このように、パケットの最大長を２０４８バイトに制限しても、この影響を受けるパケットはほとんど存在しないことがわかる。これにより、タイムアウト処理に要する時間を短縮することができ、必要なバッファ容量を小さくすることができる。従って、フレームのstore-and-forward処理におけるディレイの最大値を小さく抑えることができ、バッファの管理を容易にすることができる。
【００９１】
次に、図１５および図１６のフローチャートを参照して、タイムアウト処理について説明する。最初に、ステップＳ１１において、到着したセルがフレームの先頭のセルであるか否かが判定される。フレームの先頭のセルであると判定された場合、ステップＳ１２に進み、フレーム用のバッファが用意される。次に、ステップＳ１３において、バッファの先頭に到着時刻が記録され、ステップＳ１４において、図１７に示すように、タイムアウト管理用リストの末尾につながれる。
【００９２】
ステップＳ１４における処理が終了すると、ステップＳ１１に戻り、ステップＳ１１以降の処理が繰り返し実行される。
【００９３】
一方、ステップＳ１１において、到着したフレームのセルが先頭のセルではないと判定された場合、ステップＳ１５に進み、到着したセルがフレームの末尾のセルであるか否かが判定される。フレームの末尾のセルであると判定された場合、ステップＳ１６に進み、タイムアウト管理用リストからそのフレームのバッファが削除される。ステップＳ１６における処理が終了した場合、またはステップＳ１５において、到着したセルがフレームの末尾のセルではないと判定された場合、ステップＳ１１に戻り、ステップＳ１１以降の処理が繰り返し実行される。
【００９４】
次に、図１６のフローチャートを参照して、フレームを破棄する場合の処理手順について説明する。最初に、ステップＳ２１において、所定の変数Ｎに値１を設定する。次に、ステップＳ２２において、タイムアウト管理用リストのＮ番目のバッファに記録されているセルの到着時刻と現在の時刻の差が所定の基準時間を越えているか否かが判定される。
【００９５】
タイムアウト管理用リストのＮ番目のバッファに記録されているセルの到着時刻と現在の時刻の差が所定の基準時間を越えていると判定された場合、ステップＳ２３に進み、Ｎ番目のバッファに対応するフレームが破棄される。次に、ステップＳ２４において、Ｎの値が１だけインクリメントされ、ステップＳ２２に戻り、ステップＳ２２以降の処理が繰り返し実行される。ステップＳ２２において、タイムアウト管理用リストのＮ番目のバッファに記録されているセルの到着時刻と現在の時刻の差が所定の基準時間を越えていないと判定された場合、即ち、タイムアウト処理が不必要なフレームを見つけたところで、その回のタイムアウト処理を終了する。
【００９６】
このように、タイムアウト管理をVC毎ではなく、１つのリストだけで行うことができるようになり、タイムアウト管理のオーバヘッドを小さくすることができる。
【００９７】
次に、図１８のフローチャートを参照して、フレームの最終セルが落ちた場合の処理手順について説明する。最初に、ステップＳ３１において、フレームを構成するセルを受信する。次に、受信中のフレームの大きさが上限を越えたか否かが判定される。受信中のフレームの大きさが上限を越えていないと判定された場合、ステップＳ３１に戻り、ステップＳ３１以降の処理が繰り返し実行される。
【００９８】
一方、受信中のフレームの大きさが上限を越えたと判定された場合、ステップＳ３３に進む。ステップＳ３３においては、すでにそのフレームが破棄されたか否かが判定される。そのフレームが破棄されていないと判定された場合、ステップＳ３４に進み、そのフレームを破棄する。その後、ステップＳ３１に戻り、ステップＳ３１以降の処理が繰り返し実行される。
【００９９】
また、ステップＳ３３において、そのフレームがすでに破棄されていると判定された場合、ステップＳ３５に進み、受信したセルが最終セルであるか否かが判定される。最終セルではないと判定された場合、ステップＳ３６において、そのセルが破棄される。その後、ステップＳ３１に戻り、ステップＳ３１以降の処理が繰り返し実行される。一方、ステップＳ３５において受信したセルが最終セルであると判定された場合、ステップＳ３７において、そのセルを破棄した後、処理を終了する。
【０１００】
例えば、フレームサイズの上限を２ｋＢに設定し、受信中のフレームが上限を越えた場合、最終セルが落ちたものとみなして、そのフレームを破棄し、次に、最終セルを受信するまで、受信した全てのセルを破棄するようにすることができる。
【０１０１】
また、AAL5においては、長さフィールドから本来のセル数を計算し、フレームを構成するセル数と異なる場合、そのセルを破棄するようにすることができる。これにより、それ以上転送しても仕方のないフレームを破棄することができる。
【０１０２】
次に、図１９および図２０のフローチャートを参照して、マージするVCの数の多いものを優先的にマージ処理する処理手順について説明する。まず、図２１に示すように、マージするVCの数毎にリスト［１］を作成する。次に、それらを、マージするVC数の順に並べてリスト［２］を作成する。そして、新しくマージすべきVCができたときは、以下のような処理を行う。
【０１０３】
最初に、ステップＳ４１において、新しいVCをマージするVCの数に応じたリストの末尾に登録する。次に、ステップＳ４２に進み、リスト［２］の先頭から、（マージするVCの数）×（リスト中の要素数）を演算し、演算結果Ａとする。
【０１０４】
ステップＳ４３においては、演算結果Ａがマージ可能なVCの数より大きいかまたは等しいか否かが判定される。演算結果Ａがマージ可能なVCの数より小さいと判定された場合、ステップＳ４４に進み、リスト［２］の次のリストについて、（マージするVCの数）×（リスト中の要素数）を演算し、演算結果Ａとする。次に、ステップＳ４５において、演算結果Ａがマージ可能なVCの数より大きいかまたは等しいか否かが判定される。
【０１０５】
演算結果Ａがマージ可能なVCの数より小さいと判定された場合、ステップＳ４４に戻り、ステップＳ４４以降の処理が繰り返し実行される。一方、ステップＳ４３またはステップＳ４５において、演算結果Ａがマージ可能なVCの数より大きいかまたは等しいと判定された場合、ステップＳ４６に進み、計算を停止し、ステップＳ４７に進む。
【０１０６】
ステップＳ４７においては、新しくVCが登録されたリスト［１］より小さな順位のところで計算が停止したか否かが判定される。新しくVCが登録されたリスト［１］より小さな順位のところで計算が停止していないと判定された場合、ステップＳ４８に進み、新しくVCが登録されたリスト［１］のところで計算が停止されたか否かが判定される。新しくVCが登録されたところで計算が停止されていないと判定された場合、ステップＳ５３に進む。一方、新しくVCが登録されたところで計算が停止されたと判定された場合、ステップＳ４９に進む。
【０１０７】
ステップＳ４９においては、リスト［１］の先頭からマージ可能な範囲のVCが調べられる。そして、ステップＳ５０において、新しく追加されたVCが、マージ可能な範囲に入っているか否かが判定される。新しく追加されたVCが、マージ可能な範囲に入っていると判定された場合、ステップＳ５１に進む。
【０１０８】
ステップＳ５１においては、リスト［２］における次のリスト［１］のVCのうち、マージされていたもののマージが取りやめられる。その後、ステップＳ５２において、新しいVCのマージを開始する命令がVC margerに送られ、処理を終了する。一方、ステップＳ５０において、新しく追加されたVCがマージ可能な範囲に入っていないと判定された場合、処理を終了する。
【０１０９】
ステップＳ５３においては、新しくVCが登録されたリスト［１］より大きな順位のところで、計算が停止したか否かが判定される。新しくVCが登録されたリスト［１］より大きな順位のところで、計算が停止したと判定された場合、ステップＳ５４に進み、リスト［１］の先頭からマージ可能な範囲のVCが調べられる。そして、ステップＳ５５において、いままでマージされていたが、今回からマージができなくなったVCのマージが取りやめられ、新しいVCのマージを開始する命令がVC mergerに送られる。
【０１１０】
ステップＳ５５における処理が終了した場合、または、ステップＳ５３において、新しくVCが登録されたリスト［１］より大きな順位のところで、計算が停止していないと判定された場合、処理を終了する。
【０１１１】
このように、マージするVCの数の多いものを優先的にマージ処理することにより、VCの数を効果的に減少させることができる。
【０１１２】
なお、上記実施の形態においては、本発明をATMネットワークに応用した場合について説明したが、その他のネットワークに本発明を適用することも可能である。
【０１１３】
【発明の効果】
請求項１に記載のパケット伝送制御方法、および請求項２に記載のパケット伝送制御装置によれば、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定し、その判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージするようにしたので、バーチャルコネクションの数を効率的に削減することができる。
【図面の簡単な説明】
【図１】 AMInetアーキテクチャの例を示す図である。
【図２】 AMInetのシステム構成の例を示す図である。
【図３】資源予約要求メッセージを受信側が発行している様子を示す図である。
【図４】 ASPのプロトタイプの構成例を示す図である。
【図５】 ASPの現在の実装における資源予約確立および解除の性能を表す図である。
【図６】ベストエフォート通信の概略を示す図である。
【図７】同一VCにマージする様子を示す図である。
【図８】 RFC1483のLLCカプセル化のデータフォーマットを示す図である。
【図９】 AAL5 CPCSのデータフォーマットを示す図である。
【図１０】セル分割前のフォーマットを示す図である。
【図１１】 NNIおよびUNIのフォーマットを示す図である。
【図１２】 SDHと各伝送速度の標準を示す図である。
【図１３】同一フレームのセルを連続して送出する処理手順を説明するフローチャートである。
【図１４】パケット長の分布を示すグラフである。
【図１５】タイムアウト処理を説明するフローチャートである。
【図１６】タイムアウト処理を説明するフローチャートである。
【図１７】タイムアウト管理用リストの構成例を示す図である。
【図１８】最終セルが落ちたときの処理手順を説明するフローチャートである。
【図１９】マージするVC数の多いものを優先的にマージ処理する手順を説明するフローチャートである。
【図２０】マージするVC数の多いものを優先的にマージ処理する手順を説明するフローチャートである。
【図２１】リスト［１］およびリスト［２］を示す図である。
【符号の説明】
１ 送信側， ２，６ エッジルータ， ３乃至５ ＩＰ， ７ 受信側， ２１ ATスイッチ， ２２ VC merger
Claims (2)
- パケットの伝送を制御するパケット伝送制御方法であって、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定する判定ステップと、
前記判定ステップにおける判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージするマージステップと
を備えることを特徴とするパケット伝送制御方法。 - パケットの伝送を制御するパケット伝送制御装置であって、複数のバーチャルコネクションを１つのバーチャルコネクションにマージする場合において、バーチャルコネクションのマージングのために利用可能なキューバッファの数が、マージすべきバーチャルコネクションの数より少ないか否かを判定する判定手段と、
前記判定手段による判定結果に応じて、マージするバーチャルコネクションの数が多いものを優先的にマージするマージ手段と
を備えることを特徴とするパケット伝送制御装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP26193697A JP3649367B2 (ja) | 1997-09-26 | 1997-09-26 | パケット伝送制御方法および装置 |
| US09/160,554 US6195355B1 (en) | 1997-09-26 | 1998-09-24 | Packet-Transmission control method and packet-transmission control apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP26193697A JP3649367B2 (ja) | 1997-09-26 | 1997-09-26 | パケット伝送制御方法および装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11103298A JPH11103298A (ja) | 1999-04-13 |
| JP3649367B2 true JP3649367B2 (ja) | 2005-05-18 |
Family
ID=17368753
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP26193697A Expired - Fee Related JP3649367B2 (ja) | 1997-09-26 | 1997-09-26 | パケット伝送制御方法および装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6195355B1 (ja) |
| JP (1) | JP3649367B2 (ja) |
Families Citing this family (62)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9603582D0 (en) | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
| JPH11261589A (ja) * | 1998-03-13 | 1999-09-24 | Fujitsu Ltd | Ａｔｍネットワーク装置 |
| US6539000B1 (en) | 1998-07-21 | 2003-03-25 | Kabushiki Kaisha Toshiba | Multicast communication method and apparatus |
| US6563793B1 (en) * | 1998-11-25 | 2003-05-13 | Enron Warpspeed Services, Inc. | Method and apparatus for providing guaranteed quality/class of service within and across networks using existing reservation protocols and frame formats |
| US7664115B1 (en) * | 1999-04-30 | 2010-02-16 | Alcatel-Lucent Canada, Inc. | Method and apparatus for merging virtual connections |
| US6526034B1 (en) | 1999-09-21 | 2003-02-25 | Tantivy Communications, Inc. | Dual mode subscriber unit for short range, high rate and long range, lower rate data communications |
| US7106756B1 (en) | 1999-10-12 | 2006-09-12 | Mci, Inc. | Customer resources policy control for IP traffic delivery |
| US7369536B2 (en) * | 1999-11-02 | 2008-05-06 | Verizon Business Global Llc | Method for providing IP telephony with QoS using end-to-end RSVP signaling |
| US6970930B1 (en) | 1999-11-05 | 2005-11-29 | Mci, Inc. | Method and system of providing differentiated services |
| JP3614059B2 (ja) | 1999-11-30 | 2005-01-26 | 日本電気株式会社 | 通信コネクションマージ方法及びそれを用いるノード |
| AU2001268652A1 (en) * | 2000-06-24 | 2002-01-08 | Motorola, Inc. | A communication system that provides access queuing for communication services |
| US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
| US6993046B1 (en) * | 2000-10-16 | 2006-01-31 | Lucent Technologies Inc. | Mapping of block-encoded data formats onto a bit/byte synchronous transport medium |
| US6886038B1 (en) * | 2000-10-24 | 2005-04-26 | Microsoft Corporation | System and method for restricting data transfers and managing software components of distributed computers |
| US7113900B1 (en) * | 2000-10-24 | 2006-09-26 | Microsoft Corporation | System and method for logical modeling of distributed computer systems |
| US7606898B1 (en) * | 2000-10-24 | 2009-10-20 | Microsoft Corporation | System and method for distributed management of shared computers |
| US7000011B1 (en) * | 2000-11-06 | 2006-02-14 | Hewlett-Packard Development Company, Lp. | Designing interconnect fabrics |
| US6973035B2 (en) * | 2000-12-29 | 2005-12-06 | Nortel Networks Limited | Method and system for a routing mechanism to support two-way RSVP reservations |
| US7069337B2 (en) * | 2001-03-20 | 2006-06-27 | Mci, Inc. | Policy-based synchronization of per-class resources between routers in a data network |
| US7796608B2 (en) * | 2001-03-20 | 2010-09-14 | Verizon Business Global Llc | Edge-based per-flow QoS admission control in a data network |
| US7209439B2 (en) * | 2001-03-20 | 2007-04-24 | Mci, Llc | Pool-based resource management in a data network |
| US6798784B2 (en) | 2001-06-04 | 2004-09-28 | Caux Networks, Inc. | Concurrent switching of synchronous and asynchronous traffic |
| US7035294B2 (en) | 2001-06-04 | 2006-04-25 | Calix Networks, Inc. | Backplane bus |
| US7006497B2 (en) * | 2001-06-04 | 2006-02-28 | Calix Networks, Inc. | Traffic merging system |
| US6888849B2 (en) * | 2001-06-15 | 2005-05-03 | Lucent Technologies Inc. | Method for evaluating capacity utilization of a terminus in a communication system |
| US7349406B1 (en) * | 2001-10-18 | 2008-03-25 | Network Equipment Technologies Inc. | Method and apparatus for virtual network connection merging |
| US20030145294A1 (en) * | 2002-01-25 | 2003-07-31 | Ward Julie Ann | Verifying interconnect fabric designs |
| US9009004B2 (en) * | 2002-01-31 | 2015-04-14 | Hewlett-Packasrd Development Comany, L.P. | Generating interconnect fabric requirements |
| US20030231615A1 (en) * | 2002-06-12 | 2003-12-18 | Adc Telecommunications Israel Ltd. | Virtual Connections for voice over digital subscriber lines |
| US7272150B2 (en) * | 2002-08-19 | 2007-09-18 | World Wide Packets, Inc. | System and method for shaping traffic from a plurality of data streams using hierarchical queuing |
| US7272149B2 (en) | 2002-08-19 | 2007-09-18 | World Wide Packets, Inc. | Bandwidth allocation systems and methods |
| US7277389B2 (en) * | 2002-08-29 | 2007-10-02 | World Wide Packets, Inc. | Systems and methods for grouping of bandwidth allocations |
| US7269180B2 (en) * | 2002-11-04 | 2007-09-11 | World Wide Packets, Inc. | System and method for prioritizing and queuing traffic |
| US8122106B2 (en) | 2003-03-06 | 2012-02-21 | Microsoft Corporation | Integrating design, deployment, and management phases for systems |
| US7890543B2 (en) | 2003-03-06 | 2011-02-15 | Microsoft Corporation | Architecture for distributed computing system and automated design, deployment, and management of distributed applications |
| US20040210623A1 (en) * | 2003-03-06 | 2004-10-21 | Aamer Hydrie | Virtual network topology generation |
| US7689676B2 (en) * | 2003-03-06 | 2010-03-30 | Microsoft Corporation | Model-based policy application |
| US7072807B2 (en) | 2003-03-06 | 2006-07-04 | Microsoft Corporation | Architecture for distributed computing system and automated design, deployment, and management of distributed applications |
| US7636917B2 (en) * | 2003-06-30 | 2009-12-22 | Microsoft Corporation | Network load balancing with host status information |
| US7606929B2 (en) * | 2003-06-30 | 2009-10-20 | Microsoft Corporation | Network load balancing with connection manipulation |
| US7567504B2 (en) * | 2003-06-30 | 2009-07-28 | Microsoft Corporation | Network load balancing with traffic routing |
| US7613822B2 (en) * | 2003-06-30 | 2009-11-03 | Microsoft Corporation | Network load balancing with session information |
| US7590736B2 (en) * | 2003-06-30 | 2009-09-15 | Microsoft Corporation | Flexible network load balancing |
| US7778422B2 (en) | 2004-02-27 | 2010-08-17 | Microsoft Corporation | Security associations for devices |
| US20050246529A1 (en) * | 2004-04-30 | 2005-11-03 | Microsoft Corporation | Isolated persistent identity storage for authentication of computing devies |
| WO2006011193A1 (ja) * | 2004-07-26 | 2006-02-02 | Mitsubishi Denki Kabushiki Kaisha | データ送信装置 |
| US7535926B1 (en) * | 2005-01-07 | 2009-05-19 | Juniper Networks, Inc. | Dynamic interface configuration for supporting multiple versions of a communication protocol |
| US7539205B1 (en) | 2005-01-07 | 2009-05-26 | Juniper Networks, Inc. | Service-specific logical interfaces for providing VPN customers access to external multicast content |
| US7150689B2 (en) * | 2005-03-21 | 2006-12-19 | Balingit Ronald F | Pitching practice apparatus |
| US7797147B2 (en) | 2005-04-15 | 2010-09-14 | Microsoft Corporation | Model-based system monitoring |
| US7802144B2 (en) | 2005-04-15 | 2010-09-21 | Microsoft Corporation | Model-based system monitoring |
| US8489728B2 (en) | 2005-04-15 | 2013-07-16 | Microsoft Corporation | Model-based system monitoring |
| US8549513B2 (en) * | 2005-06-29 | 2013-10-01 | Microsoft Corporation | Model-based virtual system provisioning |
| US7941309B2 (en) * | 2005-11-02 | 2011-05-10 | Microsoft Corporation | Modeling IT operations/policies |
| US7606232B1 (en) | 2005-11-09 | 2009-10-20 | Juniper Networks, Inc. | Dynamic virtual local area network (VLAN) interface configuration |
| FI119166B (fi) * | 2005-11-30 | 2008-08-15 | Tellabs Oy | Menetelmä ja laitteisto palvelunlaatuluokasta riippuvan reitityspäätöksen muodostamiseksi |
| US7808994B1 (en) | 2006-02-22 | 2010-10-05 | Juniper Networks, Inc. | Forwarding traffic to VLAN interfaces built based on subscriber information strings |
| US7492766B2 (en) * | 2006-02-22 | 2009-02-17 | Juniper Networks, Inc. | Dynamic building of VLAN interfaces based on subscriber information strings |
| IL176288A0 (en) * | 2006-06-13 | 2007-07-04 | Imagine Comm Ltd | Synchronous transmission over packet based network |
| US20080288622A1 (en) * | 2007-05-18 | 2008-11-20 | Microsoft Corporation | Managing Server Farms |
| US8726007B2 (en) * | 2009-03-31 | 2014-05-13 | Novell, Inc. | Techniques for packet processing with removal of IP layer routing dependencies |
| US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2012868C (en) * | 1989-03-23 | 1994-03-22 | Shin-Ichiro Hayano | Call control with transmission priority in a packet communication network of an atm type |
| US5418781A (en) * | 1993-07-23 | 1995-05-23 | Digital Equipment Corporation | Architecture for maintaining the sequence of packet cells transmitted over a multicast, cell-switched network |
| US5768271A (en) * | 1996-04-12 | 1998-06-16 | Alcatel Data Networks Inc. | Virtual private network |
| US5884064A (en) * | 1996-09-04 | 1999-03-16 | Lucent Technologies Inc. | System for emulating a virtual path in an ATM network |
| US5903559A (en) * | 1996-12-20 | 1999-05-11 | Nec Usa, Inc. | Method for internet protocol switching over fast ATM cell transport |
-
1997
- 1997-09-26 JP JP26193697A patent/JP3649367B2/ja not_active Expired - Fee Related
-
1998
- 1998-09-24 US US09/160,554 patent/US6195355B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11103298A (ja) | 1999-04-13 |
| US6195355B1 (en) | 2001-02-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3649367B2 (ja) | パケット伝送制御方法および装置 | |
| US6496479B1 (en) | Network resource reservation control method and apparatus, receiving terminal, sending terminal, and relay apparatus | |
| US6598080B1 (en) | Network interconnection apparatus network node apparatus and packet transfer method for high speed large capacity inter-network communication | |
| Newman | ATM local area networks | |
| JP3923533B2 (ja) | Ａｔｍの部分的なカットスルー | |
| US6473430B2 (en) | Systems and methods for connecting frame relay devices via an ATM network using a frame relay proxy signaling agent | |
| WO2000056113A1 (en) | Internet protocol switch and method | |
| US20020159391A1 (en) | Packet-transmission control method and packet-transmission control apparatus | |
| US7366176B1 (en) | Method to provide effective connection grooming in PNNI | |
| JPH10341236A (ja) | パケットスイッチングネットワーク及びパケットスイッチ装置 | |
| Cisco | Configuring ATM | |
| JP3426646B2 (ja) | ネットワークシステム、通信方法及び通信装置 | |
| Cisco | Configuring ATM | |
| Cisco | Configuring ATM | |
| Cisco | Configuring ATM | |
| Cisco | Configuring ATM | |
| EP0905994A2 (en) | Packet-transmission control method and packet-transmission control apparatus | |
| Hagsand et al. | ATM as a Link in an ST-2 Internet | |
| JP2007184681A (ja) | Ａｔｍコンバータ | |
| Graf et al. | An internetworking architecture for multimedia communication over heterogeneous networks | |
| JP2000253018A (ja) | Ａｔｍ優先制御ｉｐゲートウェイ装置およびａｔｍ優先制御ｉｐルーティング装置ならびにそれらの処理方法 | |
| Ahamed | THE ROLE OF ATM TECHNOLOGY IN FUTURE DATA COMMUNICATION SYSTEMS. | |
| Camarda et al. | A router for the interconnection of Ethernet local area networks via an ATM network | |
| JP3557200B2 (ja) | Ａｔｍ通信システム | |
| JPH09181726A (ja) | Ａｔｍネットワークで接続を結合する方法及びシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050125 |
|
| 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: 20050128 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050210 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080225 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090225 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100225 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100225 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110225 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120225 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |