JP3529541B2 - ルータ装置及びパケット転送方法 - Google Patents

ルータ装置及びパケット転送方法

Info

Publication number
JP3529541B2
JP3529541B2 JP08024096A JP8024096A JP3529541B2 JP 3529541 B2 JP3529541 B2 JP 3529541B2 JP 08024096 A JP08024096 A JP 08024096A JP 8024096 A JP8024096 A JP 8024096A JP 3529541 B2 JP3529541 B2 JP 3529541B2
Authority
JP
Japan
Prior art keywords
message
node
dedicated
packet
router
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
Application number
JP08024096A
Other languages
English (en)
Other versions
JPH09270816A (ja
Inventor
健一 永見
久子 田中
泰弘 勝部
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP08024096A priority Critical patent/JP3529541B2/ja
Priority to US08/825,935 priority patent/US6515999B1/en
Publication of JPH09270816A publication Critical patent/JPH09270816A/ja
Application granted granted Critical
Publication of JP3529541B2 publication Critical patent/JP3529541B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/10Routing in connection-oriented networks, e.g. X.25 or ATM
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/38Flow based routing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は、仮想コネクション
ネットワーク同士を接続することのできるルータ装置、
ルータ装置を介し異なる論理ネットワークをまたがって
パケットを転送する方法、及び、ルータ装置を介しマル
チキャストのパケット転送を行うための仮想的転送路を
形成する方法に関する。
【0002】
【従来の技術】ルータ装置は、LAN(Local Area Networ
k) 間を接続する際に用いられるもので、一方のLAN か
ら他方のLAN にパケットを転送する役割を果たす。パケ
ットには、転送すべき通信情報データに加えて、その送
信元および最終宛先のネットワーク層アドレスが記載さ
れており、ルータ装置では、そのアドレス情報を用い
て、パケットの出力インターフェイスおよび次の転送ノ
ードを決定している。
【0003】このルータ装置は、1つの発信元から1つ
の最終宛先にパケットを転送するユニキャスト通信のみ
でなく、1つの発信元から多数の最終宛先にパケットを
送信するマルチキャスト通信も行うことができる。
【0004】さて、近年、音声や画像をパケットを用い
て転送する試みが行われている。現状では、音声画像の
データと他のデータがルータで同様に送られるため、音
声がとぎれとぎれになったら、映像が乱れたりしてい
る。そこで、ルータで資源予約を行うことで、音声画像
の転送を優先的に行うことで聞きやすい音声と見易い画
像になる。ここでは、音声画像を例に取ったが、優先的
に流したいデータの場合は、資源予約することにより、
メリットがある。
【0005】このようにルータ装置で資源予約をするた
めには、ルータ装置間で資源予約の情報をやり取りする
必要があり、そのプロトコルとして、RSVP(Resource Re
SerVation Protocol) が開発されている。このプロトコ
ルは、ユニキャストとマルチキャストの両方に対応して
いる。
【0006】RSVPでは、データを受信している下流側の
ノードから情報の発信元である上流ノードへ資源予約を
行う。具体的には、情報の発信元からデータの宛先と同
じ宛先に向かってPATHメッセージを送出し、情報がどの
経路を通っているかを経路上のルータに記憶させる。PA
THメッセージには、資源予約すべきデータを特定する識
別子と、PATHメッセージを送出するノードのIPアドレス
が書かれている。
【0007】データの受信ノードは、PATHメッセージを
受信すると、PATHメッセージを送信した上流ノードにRE
SVメッセージを送出することで、資源予約の意思を表示
する。RESVメッセージには、資源予約すべきデータを特
定する識別子と、受信ノードが要求するQOS (サービス
品質)が書かれている。
【0008】このRESVメッセージを受信したルータは、
資源予約するだけの能力がネットワークレイヤ(IP)処
理部にある場合は、ネットワークレイヤのスケジューリ
ングを行って、RESVを上流に転送する。資源予約が出来
ない場合は、RESV Errorを下流のノードに送信する。こ
れを繰り返すことにより、上流ノードまで資源予約が出
来る。
【0009】
【発明が解決しようとする課題】本発明の一つは、ネッ
トワークレイヤ処理部の能力が比較的低いルータが、ネ
ットワークレイヤのスケジューリングのみによっては、
資源予約のためのメッセージに示される要求サービス品
質を満たすことができない場合にも、要求された資源の
予約を可能とし、かつ、自ノードで資源予約が行えたか
否かを正しく他のノードに伝える機構を提供することを
目的とする。
【0010】本発明は、また、ルータがネットワークレ
イヤより下位のレイヤでの仮想コネクションのスイッチ
ング機能を利用してマルチキャスト通信を行う際に、こ
の通信のためのコネクション及びルータ内の設定を効率
よく行う手法を提供することを目的とする。
【0011】本発明は、また、ルータ間にスイッチの存
在するシステムでマルチキャスト通信を行う際に、この
通信のためのコネクションを両端のルータで一意に識別
し、必要なコネクション及びルータ内の設定を効率よく
行う手法を提供することを目的とする。
【0012】
【課題を解決するための手段】本発明の第一の発明は、
仮想コネクション型ネットワークとの物理インタフェー
スを有し、少なくとも2つの論理ネットワークを接続す
るルータ装置において、一方の前記論理ネットワークか
らの受信に使用される仮想的転送路と他方の前記論理ネ
ットワークへの送信に使用される仮想的転送路との対応
関係を記憶する記憶手段と、この記憶された対応関係に
従って、パケットの転送を行う転送手段と、資源予約の
ためのメッセージを受信者側の論理ネットワークから受
信する受信手段と、この受信した資源予約のためのメッ
セージに基づき、前記受信者側の論理ネットワークへの
前記転送手段を介することが可能なパケット送信用の仮
想的転送路の存在、及び、送信者側の論理ネットワーク
からの前記転送手段を介することが可能なパケット受信
用の仮想的転送路の存在の有無に応じて、資源予約のた
めのメッセージを前記送信者側の論理ネットワークへ送
信する送信手段とを具備したことを特徴とする。
【0013】本発明の第二の発明は、仮想コネクション
型ネットワークとの物理インタフェースを有し、少なく
とも2つの論理ネットワークを接続するルータ装置にお
いて、一方の前記論理ネットワークからの受信に使用さ
れる仮想的転送路と他方の前記論理ネットワークへの送
信に使用される仮想的転送路との対応関係を記憶する記
憶手段と、この記憶された対応関係に従って、パケット
の転送を行う転送手段と、資源予約のためのメッセージ
を受信者側の論理ネットワークから受信する受信手段
と、この受信した資源予約のためのメッセージに基づ
き、資源予約のためのメッセージを送信者側の論理ネッ
トワークへ送信する送信手段と、前記受信者側の論理ネ
ットワークへの前記転送手段を介することが可能なパケ
ット送信用の仮想的転送路の存在、及び、前記送信者側
の論理ネットワークからの前記転送手段を介することが
可能なパケット受信用の仮想的転送路の存在の有無に応
じて、前記送信手段により送信した資源予約のためのメ
ッセージの取り消しを通知する通知手段とを具備したこ
とを特徴とする。
【0014】本発明の第三の発明は、例えば第一の発明
に係るルータ装置を用いて実現されるものであり、第1
のノードから送信されるパケットを、前記第1のノード
とは異なる論理ネットワークに属する第2のノードへ転
送するパケット転送方法において、資源予約のためのメ
ッセージを前記第2のノードから受信し、前記第1のノ
ードから前記第2のノードへネットワークレイヤレベル
の転送処理の一部又は全部を行わずにパケット転送を行
うことを可能とするように設定された、前記第1のノー
ドからのパケットを受信可能な仮想的転送路と、前記第
2のノードへのパケットを送信可能な仮想的転送路とが
存在する(ことを確認した)場合に、これら仮想的転送
路の対応関係を記憶すると共に、資源予約のためのメッ
セージを前記第1のノードへ送信し、パケットを受信し
た場合に、この受信に用いられた仮想的転送路について
の前記対応関係が記憶されているならば、この対応関係
に従って前記パケットを転送することを特徴とする。
【0015】本発明の第四の発明は、例えば第二の発明
に係るルータ装置を用いて実現されるものであり、第1
のノードから送信されるパケットを、前記第1のノード
とは異なる論理ネットワークに属する第2のノードへ転
送するパケット転送方法において、資源予約のためのメ
ッセージを前記第2のノードから受信し、この受信を受
けて、資源予約のためのメッセージを前記第1のノード
へ送信し、前記第1のノードから前記第2のノードへネ
ットワークレイヤレベルの転送処理の一部又は全部を行
わずにパケット転送を行うことを可能とするように設定
された、前記第1のノードからのパケットを受信可能な
仮想的転送路と、前記第2のノードへのパケットを送信
可能な仮想的転送路との少なくとも一方が存在しない
(ことを確認した)場合に、送信した前記資源予約のた
めのメッセージの取り消しを前記第1のノードに通知
し、前記両仮想的転送路が存在する場合に、これら仮想
的転送路の対応関係を記憶し、パケットを受信した場合
に、この受信に用いられた仮想的転送路についての前記
対応関係が記憶されているならば、この対応関係に従っ
て前記パケットを転送することを特徴とする。
【0016】ここで、記憶された対応関係に従ってパケ
ットを転送することは、ネットワークレイヤレベルの転
送処理の一部又は全部を省略してパケットを転送するこ
とを意味する。少なくとも省略される処理は、パケット
の宛先アドレスから、次に転送すべき先のノードを決定
し、この決定されたノードへのパケット送信に用いる仮
想的転送路を特定する処理(ネットワークレイヤレベル
の解析)である。
【0017】また、ネットワークレイヤレベルの転送処
理の一部又は全部を行わずにパケット転送を行うことを
可能とするように設定された仮想的転送路は、異なる論
理ネットワークに属するノード間でネットワークレイヤ
レベルの転送処理を行ってパケットを転送するように既
に設定されている仮想的転送路とは別の仮想的転送路で
あることが望ましい。
【0018】このように、上記第一乃至第四の発明で
は、ルータ装置がネットワークレイヤより下位のレイヤ
での仮想的転送路のスイッチング機能を一部利用して
(これら仮想的転送路の対応関係を記憶してこの対応関
係に従って)パケット転送を行うことにより、従来のル
ータ装置よりも多くの場合に資源の予約を行うことがで
きる。
【0019】さらに、上記第一又は第三の発明によれ
ば、下流から資源予約のためのメッセージ(例えばRSVP
のResvメッセージ)を受けたとき、これを受けたノード
(ルータ装置)の上流及び下流に、ネットワークレイヤ
レベルの転送処理の一部又は全部を省略してパケットを
転送するように使用することのできる仮想的転送路(例
えば専用VC)が存在し、これらの仮想的転送路の対応関
係を記憶してこれに従ってパケット転送を行う(例えば
直結する)ことによりはじめて資源予約のためのメッセ
ージに示される要求サービス品質を満たすことができる
場合に、両仮想的転送路の存在を確認してから上流へ資
源予約のためのメッセージを送信するため、これを受け
た上流のノードは、次ノードから下流については確実に
資源予約が行えたと解釈して動作することができる。
【0020】さらに、上述の場合に、少なくともいずれ
かの仮想的転送路の不存在を確認したならば、下流に資
源予約に失敗した旨のメッセージ(例えばRESV Error)
を送信することにより、これを受けた下流のノードは、
自ノードの要求した資源予約が拒否されたことを知って
動作することができる。
【0021】この発明を、例えば、資源予約のためのメ
ッセージを受信したノードが、自ノードの上流に専用VC
を設定するよう要求する場合に適用すると、専用VCを直
結することによりはじめて受信側から要求された資源予
約が行える場合には、まず、自ノードの下流に専用VCが
存在しないならば、上流へ資源予約のためのメッセージ
を送信することはせず(下流に資源予約の失敗を伝
え)、自ノードの下流に専用VCが存在するならば、要求
して上流に専用VCが設定されてから、上流へ資源予約の
ためのメッセージを送信することになる。
【0022】なお、自ノードの下流に専用VCが存在しな
いという場合を減らすため、専用VCを直結せずに要求さ
れた資源予約が行える場合でも、上流に専用VCを設定す
るよう要求しても良い。そして、両側に専用VCが存在す
るならば、ネットワークレイヤの資源を他の用途に利用
できるように、専用VCを直結せずに要求された資源予約
が行える場合でも、直結しても良い。
【0023】一方、上記第二又は第四の発明によれば、
下流から資源予約のためのメッセージを受けたとき、こ
れを受けたノード(ルータ装置)の上流及び下流の仮想
的転送路(例えば専用VC)の対応関係を記憶してこれに
従ってパケット転送を行う(例えば直結する)ことをし
なければ資源予約のためのメッセージに示される要求サ
ービス品質を満たすことができない場合であっても、上
流に資源予約のためのメッセージを送信しておき、少な
くともいずれかの仮想的転送路の不存在を確認したなら
ば、これの取り消しを通知する(例えばRESV Tear を送
る)ため、上流のノードは、次ノードから下流について
資源予約が行えたか否かを確実に知って動作することが
できる。
【0024】さらに、上述の場合に、少なくともいずれ
かの仮想的転送路の不存在を確認したならば、下流に資
源予約に失敗した旨のメッセージ(例えばRESV Error)
を送信することにより、これを受けた下流のノードは、
自ノードの要求した資源予約が拒否されたことを知って
動作することができる。
【0025】この発明を、例えば、資源予約のためのメ
ッセージを受信したノードが、自ノードの下流に専用VC
を設定する場合に適用すると、専用VCを直結することに
よりはじめて受信側から要求された資源予約が行える場
合には、まず、自ノードの下流に専用VCを設定し、上流
のノードが自ノードの送信した資源予約のためのメッセ
ージをきっかけとして専用VCを設定するのを待つ。そし
て、上流に専用VCが設定されなければ、上流へ資源予約
を取り消すメッセージを送信し(下流に資源予約の失敗
を伝え)ることになる。
【0026】ここで、上流に資源予約のためのメッセー
ジを送信するタイミングは、下流に専用VCを設定する前
でも後でも良いが、前とする場合は、下流に専用VCが設
定できなかったときも、上流へ資源予約を取り消すメッ
セージを送信する。
【0027】なお、自ノードの上流に専用VCが設定され
ないという場合を減らすため、専用VCを直結せずに要求
された資源予約が行える場合でも、下流に専用VCを設定
するようにしても良い。そして、両側に専用VCが存在す
るならば、ネットワークレイヤの資源を他の用途に利用
できるように、専用VCを直結せずに要求された資源予約
が行える場合でも、直結しても良い。
【0028】本発明の第五の発明は、第1のノードから
送信されるパケットを、前記第1のノードとは異なる論
理ネットワークに属する複数の第2のノードへ、ルータ
装置を介して転送するための仮想的転送路を形成する方
法において、前記第1のノードから前記ルータ装置へ
の、及び、前記ルータ装置から前記第2のノードへの、
ポイント−マルチポイントとなり得る通常コネクション
(例えばデフォルトVC)を設定し、前記ルータ装置は、
前記第1のノードとの間に設定された前記通常コネクシ
ョン上に送信されたパケットを、ネットワークレイヤレ
ベルの解析を行って、前記第2のノードとの間に設定さ
れた前記通常コネクション上に転送し、前記第1のノー
ドから前記ルータ装置への、及び、前記ルータ装置から
前記複数の第2のノードのうち所定の条件を満たすもの
への、ポイント−マルチポイントとなり得る専用コネク
ション(例えば専用VC)を設定し、前記ルータ装置は、
前記第1のノードとの間に設定された前記専用コネクシ
ョン上に送信されたパケットを、ネットワークレイヤレ
ベルの解析を行わずに、前記第2のノードとの間に設定
された前記専用コネクション上に転送し、前記専用コネ
クションの設定される前記第1のノードと前記ルータ装
置間、及び、前記専用コネクションの設定される前記ル
ータ装置と前記第2のノード間に、ポイント−ポイント
の通常コネクションを設定し、この通常コネクションを
用いて、前記専用コネクションの保持を行うことを特徴
とする。
【0029】ここで、ネットワークレイヤレベルの解析
を行わないということは、ネットワークレイヤレベルの
転送処理の一部又は全部を省略してパケットを転送する
ことを意味する。少なくとも省略される処理は、パケッ
トの宛先アドレスから、次に転送すべき先のノードを決
定し、この決定されたノードへのパケット送信に用いる
仮想的転送路を特定する処理であり、これに代わってネ
ットワークレイヤより下位のレイヤで記憶された対応関
係に従ってパケットが転送される。
【0030】この発明によれば、マルチキャスト用の通
常の品質で転送が行われる通常コネクションと、マルチ
キャスト用の高品質で転送が行われる専用コネクション
と、ポイント−ポイントの通常コネクションが設定さ
れ、専用コネクションの保持がポイント−ポイントの通
常コネクションを用いて行われる(例えば、保持のため
のメッセージが下流ノードから定期的に送られる)た
め、マルチキャスト通信において、ルータ装置がネット
ワークレイヤより下位のレイヤでの仮想的転送路のスイ
ッチング機能を一部利用してパケット転送を行うこと
を、効率よく実現することができる。
【0031】例えば、専用コネクションを設定するきっ
かけとして、資源予約のためのメッセージを下流から受
信したときや、データパケットを上流から受信したとき
が想定されるが、前者の場合は、資源予約のためのメッ
セージ受信に、ポイント−ポイントの通常コネクション
を用いれば良く、後者の場合は、データパケットの受信
に、マルチキャスト用の通常コネクションを用いれば良
い。
【0032】また、例えば、専用コネクションの設定
を、自ノードの上流に要求して設定する場合や、自ノー
ドの下流に設定する場合が想定されるが、前者の場合
は、設定を要求するメッセージの送信に、後者の場合
は、設定したことを通知するメッセージの送信に、ポイ
ント−ポイントの通常コネクションを用いれば良い。
【0033】なお、専用コネクションはマルチキャスト
用であるから、同じマルチキャストグループに対応する
ノードへの専用コネクションの設定は、既に存在する専
用コネクションにリーフをを追加することにより行われ
る。そして、ポイント−ポイントの通常コネクションを
用いて保持されるのは、専用コネクションの対応するリ
ーフであることになる。
【0034】本発明の第六の発明は、第1のノードから
送信されるパケットを、前記第1のノードとは異なる論
理ネットワークに属する複数の第2のノードへ、ルータ
装置を介して転送するための仮想的転送路を形成する方
法において、前記ルータ装置から前記複数の第2のノー
ドへの、ポイント−マルチポイントとなり得る専用コネ
クションを設定し、前記ルータ装置と前記第2のノード
それぞれとの間に、ポイント−ポイントの通常コネクシ
ョンを設定し、前記専用コネクションを表す前記論理ネ
ットワーク内でユニークな識別情報を、前記ルータ装置
から前記専用コネクションを用いて送信し、前記第2の
ノードから前記通常コネクションを用いて、前記識別情
報を確認するメッセージを送信することを特徴とする。
【0035】この発明によれば、マルチキャスト用の専
用コネクションと、ポイント−ポイントの通常コネクシ
ョンが設定され、専用コネクションを両端のノードで一
意に識別するための情報が、上流ノードから専用コネク
ションで提案され、下流ノードから通常コネクションで
確認されるため、マルチキャストグループに受信者が参
加してくる毎に、対応する各ノードにおいて、専用コネ
クションを一意に識別することを、効率よく実現するこ
とができる。
【0036】
【発明の実施の形態】
(実施形態1)本実施形態では、CSR(Cell Switch Rout
er) の技術を用いて、ATM(Asynchronous Transfer Mod
e) 上で資源予約プロトコルであるRSVP(resource ReSeV
ation Protocol) を実現するための方法を述べる。
【0037】RSVPは、送信元アドレス/ポートと宛先ア
ドレス/ポートの組(宛先アドレス/ポートだけでもよ
い)等で識別するフローに属するパケット転送のQOS
(サービス品質)をルータで保証するものである。この
フローを識別する識別子をここでは、Flow ID と呼ぶこ
とにする。このQOS 保証は、ルータ内部でパケット転送
のスケジューリングを行うことにより、資源を予約して
いるパケットについては、早めに転送を行うようにする
ことにより、実現される。
【0038】CSR は、通常のルータと同じIPパケット単
位で転送する動作を行う他に、ルータ内部にATM スイッ
チ機能を持つことにより、より高速なATM セル単位の転
送を行うことができるルータである。
【0039】図1 を使って、CSR の簡単な動作を説明す
る。X.1 からCSR を通してY.1 にパケットを転送する場
合を考える。通常と同じIPパケット転送の動作を行うた
めには、X.1 からCSR に色々な宛先のパケットを転送す
るために設定されているATMコネクションでパケットを
送信する。ここでは、このATM コネクションをデフォル
トVC(Virtual Connection)と呼ぶ。CSR では、IPパケッ
トの宛先を見て次に配送するノードを決定する。ここで
は、次のノードは、Y.1 になるので、デフォルトVCにパ
ケットを送出することによりY.1 へとパケットが転送さ
れる。
【0040】次に、ATM セル転送の動作を説明する。Y.
1 へのパケット転送専用のX.1 からCSR へのATM コネク
ションとCSR からY.1 へのATM コネクションとが設定さ
れているとする。ここでは、このATM コネクションを専
用VCと呼ぶ。さらに、これら2つの専用VCをCSR 内のAT
M スイッチ機能でATM セル単位で転送できるように設定
しておく。すなわち、X.1 からCSR への専用VCのCSR の
受信ポートでのVPI/VCI と、CSR からY.1 への専用VCの
CSR の送信ポートでのVPI/VCI との対応関係を、ATM レ
ベルのルーティングテーブルとして記憶しておく。この
ような設定を行うことで、二つの論理ネットワーク(IP
Subnet )に属する専用VCを直結するバイパスパイプが
形成されたことになる。
【0041】X.1 からY.1 へのパケット転送を行うに
は、X.1 からY.1 用の専用VCにパケットを送信すること
により、X.1 からCSR に送られ、CSR でATM レベルのル
ーティングテーブルを参照することによりATM セルのま
まCSR からY.1 への専用VCに転送されて、その専用VCで
Y.1 へ送られる。
【0042】なお、ここでは、専用VCにて送信されるパ
ケットをATM セル単位で転送することを、専用VCの直結
として説明したが、専用VCにて送信されるパケットをAA
L(ATM Adaptation Layer) フレーム単位で転送すること
で、専用VCの直結としても良い。この場合も、上記のAT
M レベルのルーティングテーブルを参照することによ
り、AAL フレーム転送が行える。以上の場合はいずれ
も、ネットワークレイヤ(例えばIP)レベルの解析処理
を行わずに、パケットが転送されることになる。
【0043】また、専用VCにて送信されるパケットに対
し、パケットの最終宛先アドレスから出力先とすべきVC
を決定するネットワークレイヤレベルのルーティングテ
ーブル参照処理は行わず、その他のネットワークレイヤ
レベルの処理(IPの場合はTTL(Time To Live) を減らす
処理やチェックサム計算等)は行って、次段ノードへの
専用VCに転送することを、上記専用VCの直結としても良
い。この場合も、上記のATM レベルのルーティングテー
ブルを参照することにより、出力先とすべきVCが決定で
き、パケット転送が行える。この場合は、ネットワーク
レイヤレベルの処理を一部だけ行って、パケットが転送
されることになる。
【0044】本発明は、CSR の動作が以上に説明したい
ずれのものであっても、適用可能である。さて、RSVPで
資源予約を行う場合は、ルータ内でIP転送のスケジュー
リングを行う必要があるが、ルータにCSR を用いると、
パケット転送をATM セル単位でATM スイッチ機能で転送
できるので、パケット転送のスケジューリングをATM ス
イッチ機能で行うことができる。すなわち、資源を予約
しているパケットについては、ATM スイッチ機能(ATM
セル転送、AAL フレーム転送、IP処理の一部を省略した
パケット転送のいずれでも良い)を用いることにより高
速に転送を行うことができる。以下では、RSVPを用いた
時の専用VCの設定手順を述べる。
【0045】(具体例1)本例では、ATM コネクション
がSVC(Switched Virtual Connection)であり、ユニキャ
ストを想定した場合について説明する。
【0046】図2 の様なネットワークトポロジーを例に
とり専用VCの設定の手順を述べる。H1,H2 はホストを示
し、R1,R2,R3はルータを示している。これらの全てのノ
ード間にはデフォルトVCがあらかじめ設定されていると
仮定する。
【0047】以下の手順では、R1,R2,R3を取り出して、
その間で行われる手順を説明する。H1とR1間やR3とH2間
のようなホストとルータ間(ホストもルータもいずれも
ノードである)の手順も、仮想コネクション型ネットワ
ークで接続されているならば、ルータ同士の手順と同じ
なので、ここでは、省略する。
【0048】(具体例1−1)本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをアウトバンドで流す場合について説明する。
図3 のようにルータ1,2,3(R1,R2,R3)が存在している場
合に、ルータ2 での資源予約の方法を述べる。初期状態
として、ルータ1 からルータ2 へ、ルータ2 からルータ
3 へのデフォルトVCとルータ2 からルータ3 への専用VC
が設定されている状況を考える。以下では、メッセージ
交換の様子を示す図(図3 )と、下流側のルータ(図3
ではR2)内部の動作図(図4 、図5 )と、上流側のルー
タ(図3ではR1)内部の動作図(図6 )を用いて説明す
る。
【0049】はじめに、図3 のようにルータ3 からRSVP
の予約(RESV)メッセージがルータ2 に到着したとす
る。RESVメッセージには、どのパケットに対して予約す
べきか示すためのFlow ID と予約したいQOS が書かれて
いる。Flow ID には、発信元IPアドレス/ポート、宛先
IPアドレス/ポートの組、あるいは、IPv6 のFlow ID
が書かれている。QOS には、帯域の情報や遅延の情報が
書かれている。
【0050】RESVメッセージを受信したルータ2は、図
4 及び図5 のフローチャートに従い、RSVPメッセージ中
のFlow ID 用の下流側の専用VCがあるかチェックする
(S1)。この例では、専用VCが存在するので専用VC依
頼メッセージを上流側のノード(R1)に送出する(S
2)。このメッセージには、RESVメッセージの内容と同
じFlow ID とQOS の情報を持つ。もしくは、RESVのQOS
からATM レベルの品質を求めてこれをQOS の情報として
専用VC依頼メッセージに書き込んでも良い。
【0051】もし、下流側に専用VCが無い場合は、IP処
理部で要求された資源を確保できるか判断し(S3)、
資源予約できる場合には、IP転送のスケジューリングを
行うことにより資源予約して上流にRESVメッセージを送
出する(S5)と共に、専用VC依頼メッセージを上流に
送出し(S2)、資源予約できない場合には、RESV ERR
ORを下流ノードに送出する(S4)。
【0052】なお、自ルータでは下流に専用VCがなくて
も資源予約できる場合であっても、専用VC依頼メッセー
ジを上流に送出するのは、自ルータより上流のノード群
の中に、専用VCの直結を行わないと要求された資源が確
保できないノードが存在する可能性があることに対処す
るためである。特に、宛先ノード(ホストH2)、もしく
は、宛先ノードが非仮想コネクション型ネットワークに
接続されている場合の、非仮想コネクション型ネットワ
ークと仮想コネクション型ネットワークとの境界に位置
するルータは、専用VCの直結は行わないが、専用VC依頼
メッセージは上流に送出するようにする。
【0053】専用VC依頼メッセージを受信したルータ1
は、図6 のフローチャートに従い、ATM シグナリングを
用いて、専用VC依頼メッセージを送信したノード(ルー
タ2)への、要求QOS を満たせるATM コネクション(専
用VC)を設定する(S21)。
【0054】ATM コネクションの設定が終わるとこのコ
ネクションを両端で一意に識別できるようにVCIDという
識別子を付ける。これは、ルータ1 及び2 の属する論理
ネットワーク内でユニークな識別子である。このVCIDの
付け方は、例えば、グローバルユニークなホストのIDと
そのホストで発行したVCIDのシーケンス番号を付けるこ
とで、一意なVCIDを付けることができる。このように作
ったVCIDを、VCID提案メッセージを新しくつくったATM
コネクション(専用VC)に流すことで、下流ノードに運
ぶ(S22)。
【0055】このメッセージには、送信者側(ルータ1
)が提案するVCIDと、ターゲットIPアドレス(ルータ2
のIPアドレス)とが入っている。ターゲットIPアドレ
スは、後述するように専用VCをポイント−マルチポイン
ト化することに対処するために、書き込まれる。
【0056】このVCID提案メッセージを受信したノード
(ルータ2 )は、このメッセージに含まれるターゲット
IPアドレスが自ノードのIPアドレスであるか否かを調べ
(S11)、そうである場合は、このVCIDを許容するな
らば、VCID ACKをデフォルトVCで上流ノード(ルータ1
)に送信する(S12)。VCID ACKは、少なくとも送
信者側が提案し自ノードが許容したVCIDが入っている。
この手続きにより、VCIDの交換が終了する。
【0057】VCID交換が終了し、専用VCが使用可能であ
ることを下流側のノード(ルータ2)に知らせるため
に、ルータ1 からルータ2 へ専用VC通知メッセージを送
信する(S23)。このメッセージは、デフォルトVC
(すなわちパケット送信に用いられる専用VCとは異なる
VC)にて、送信する。このメッセージには、Flow ID と
VCIDが含まれる。
【0058】この専用VC通知メッセージを受信したノー
ド(ルータ2 )は、そのVCIDで特定される専用VCは、そ
のFlow ID で特定されるフロー専用に使えることが分か
るので、同じFlow ID を持つ下流側の専用VCがある(S
13ある)ならば、上流側の専用VCと下流側の専用VCと
を直結する(S14)。すなわち、ATM レベルのルーテ
ィングテーブルに専用VC同士の対応関係を記憶する。こ
うして専用VCが使用可能になると、上流側にリダイレク
トメッセージを送出する(S15)。リダイレクトメッ
セージは、Flow ID とVCIDを含み、デフォルトVCにより
送信される。
【0059】上流側のノード(ルータ1 )は、リダイレ
クトメッセージを受信すると、そのFlow ID を今までデ
フォルトVCで送出していて(S24Yes )、同じFlow I
D を持つ上流側の専用VCがない(S26ない)ならば、
IP処理部がそのFlow ID に関わるパケットを専用VCに流
すようにする(S25)。すなわち、さらに上流側のノ
ード(H1)からデフォルトVCにて送信されてくるパケッ
トをルータ2 への専用VCに転送するよう、IP処理部で用
いるルーティング情報を書き替える。
【0060】なお、ルータ1 の上流に同じFlow ID を持
つ専用VCが存在する(S26ある)場合は、その上流側
の専用VCとルータ2 への専用VCを直結する(S27)。
専用VC通知メッセージを受信したノード(ルータ2 )
は、下流側にFlow ID 用の専用VCがない(S13ない)
場合には、上流側の専用VCから受信したパケットをIP処
理部に渡すように設定する(S16)。このステップ
は、直結せずに資源予約できるが、上流に専用VC依頼メ
ッセージを送出し、それにより上流側に専用VCが設定さ
れた場合に対応する。
【0061】最後に、ルータ2 でRSVPのQOS 要求を満足
することができるので、ルータ2 からルータ1 へ、デフ
ォルトVCでRESVの送出を行う(S17)。なお、S15
のリダイレクト及びS17のRESVの送信順序は逆でも構
わない。
【0062】以上により、ルータ2 の資源予約が終了す
る。なお、上記リダイレクトメッセージを、ルータ2 か
らルータ1 へ適当なタイミングで定期的に送出すること
により、対応する専用VCを保持する。この保持のための
メッセージは、上記RESVメッセージによって代用しても
構わない。リダイレクトメッセージ(代用する場合はRE
SVメッセージ)が送信されてこなくなったルータへの専
用VCは解放する。
【0063】(具体例1−2)本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをインバンドで流す場合について説明する。具
体例1−1で説明した手順では、専用VC依頼メッセージ
を送信し、ATM シグナリングを行った後、VCID提案、VC
ID ACK、専用VC通知と3つのメッセージを送信していた
が、専用VC通知メッセージを新たに作ったATM コネクシ
ョン(専用VC)に流すことで、VCID提案メッセージとVC
ID ACKを省略することが可能である。
【0064】具体的なシーケンス図を図7 で示し、下流
側のノードのフローチャートを図4、図8 に、上流側の
ノードのフローチャートを図9 に示す。具体例1−1か
ら変更した点を説明すると、図7 では、VCID提案メッセ
ージとVCID ACKメッセージが無くなったことと、専用VC
通知メッセージを新たに作ったATM コネクション(専用
VC)で転送することが異なる。また、本例での専用VC通
知メッセージには、Flow ID とVCIDの他に、具体例1−
1ではVCID提案メッセージに含ませていたターゲットIP
アドレスを含ませる。
【0065】メッセージが2つ不要となったことに伴っ
て、上流側のノード(図9 )は、VCID ACKメッセージを
受信したときの動作(S23)が無くなり、新たに作っ
たATM コネクションに、VCID提案ではなく、上述した専
用VC通知を送信することになる(S31)。下流側のノ
ードは、RESVを受信したときの動作は図4 の通りであ
り、VCID ACK提案を受信したときの動作(S12)が無
くなり、専用VC通知メッセージを受信したときは、図8
に示すように、このメッセージに含まれるターゲットIP
アドレスが自分のアドレスであるか否かチェックした
後、図5(b)と同様の動作を行う。
【0066】(具体例2)本例では、ATM コネクション
がVP(Virtual Path)のコネクションであり、ユニキャス
トを想定した場合について説明する。図10のようにルー
タ1,2,3(R1,R2,R3)が存在している場合に、ルータ2 で
の資源予約の方法を述べる。初期状態として、ルータ1
からルータ2 へ、ルータ2 からルータ3 へのデフォルト
VCとルータ2 からルータ3 への専用VCが設定されている
状況を考える。以下では、メッセージ交換の様子を示す
図(図10)と下流側のルータ内部の動作図(図11、図1
2)と上流側のルータ内部の動作(図13)を用いて説明
する。
【0067】はじめに、図10のようにルータ3 からRSVP
の予約(RESV)メッセージがルータ2 に到着したとす
る。RESVメッセージには、どのパケットに対して予約す
べきか示すためのFlow ID と予約したいQOS が書かれて
いる。
【0068】RESVメッセージを受信したルータ2は、図
11のフローチャートに従い、RSVPメッセージ中のFlow I
D 用の下流側の専用VCがあるかチェックする(S4
1)。この例では、専用VCが存在するので、上流側のル
ータからの(R1からR2への)未使用VCのうち適当なもの
を選んでこれを専用VCとして使用することを決定し(S
42)、この決定した上流の専用VCと下流に存在する専
用VCとを直結(ATM レベルのルーティングテーブルに対
応関係を記憶)し(S43)、リダイレクトメッセージ
をデフォルトVCで上流側のノード(R1)に送出する(S
44)。
【0069】このメッセージには、RESVメッセージの内
容と同じFlow ID と、VCIDの情報を持つ。VCIDは、VP中
の使用していないVCI (上記のように選んだ専用VCのVC
I )を使用し、VPI/VCI の組をVCIDの値とする。もし、
下流側に専用VCが無い場合は、IP処理部で要求された資
源を確保できるか判断し(S45)、資源予約できる場
合には、IP転送のスケジューリングを行うことにより資
源予約して上流にRESVメッセージを送出する(S46)
と共に、上流側のルータとの間の未使用VCのうち適当な
ものを選んでこれを専用VCとして使用することを決定し
(S47)、この専用VCで受信したパケットをIP処理部
に渡すように設定し(S48)、リダイレクトメッセー
ジを上流に送出する(S44)。資源予約できない場合
には、RESV ERRORを下流ノード(R3)に送出する(S4
9)。
【0070】リダイレクトメッセージを受信したルータ
1は、図13のフローチャートに従い、図6(c)と同様にFl
ow ID に関するパケット転送をデフォルトVCを使う転送
から専用VCによる転送に切り替え、下流側のノードにデ
フォルトVC(もしくは専用VC)で専用VC通知メッセージ
を送出する(S51)。このメッセージには、 FlowID
(とVCID)の情報が含まれる。
【0071】下流側のノード(ルータ2)が専用VC通知
メッセージを受信すると、図12のフローチャートに従い
動作する。すなわち、 VCID で特定される専用VCは、Fl
ow ID 専用に使えることが分かり、ルータ2 でRSVPのQO
S 要求を満足することができるので、ルータ2 からルー
タ1 へ、デフォルトVCでRESVの送出を行う(S52)。
【0072】以上により、ルータ2 の資源予約が終了す
る。なお、上記リダイレクトメッセージを、ルータ2 か
らルータ1 へ適当なタイミングで定期的に送出すること
により、対応する専用VCを保持する。この保持のための
メッセージは、上記RESVメッセージによって代用しても
構わない。リダイレクトメッセージ(代用する場合はRE
SVメッセージ)が送信されてこなくなったルータへ専用
VCは解放する。
【0073】(具体例3)本例では、ATM コネクション
がSVC であり、マルチキャストを想定した場合について
説明する。図14のようにルータ1,2,3,4(R1,R2,R3,R4)
が存在している場合に、ルータ4での資源予約の方法を
述べる。ホストH2,H3 がマルチキャストグループG に参
加しているため、ルータ2 からルータ3 とルータ4へ、
ポイント−マルチポイント( 以下p-mpと言う) のデフォ
ルトVCが設定されている。また、上流のルータから下流
のルータへデータパケット等を流すために設定されてい
るデフォルトVCはマルチキャスト用(p-mpとなり得るも
の)であり、このマルチキャスト用デフォルトVCとは別
に、下流から上流に制御パケット等を流すためにポイン
ト−ポイント( 以下p-p と言う) のデフォルトVCが、必
要に応じて設定される。
【0074】(具体例3−1)本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをアウトバンドで流す場合について説明する。
初期状態として、図15のように、ルータ2 からルータ3
とルータ4へ、マルチキャスト用のデフォルトVC(p-mp
となり得る( ここでは既になっている)VC )が設定さ
れ、ルータ2 からルータ3 へのp-mpとなり得る(ここで
はまだなっていない)専用VCが設定され、ホスト3 とル
ータ4 間に(p-p の)デフォルトVCが設定されている状
況を考える。ルータ2 からルータ3 への専用VCは、マル
チキャストグループG の専用VCとする。
【0075】ここで、ルータ1 からルータ2 への専用VC
や、ルータ2 からルータ3 への専用VCは、具体例1−1
で説明した手順により設定されたものである。但し、具
体例1−1で説明したRESV、VCID ACK、専用VC通知、リ
ダイレクトの各メッセージは、p-p のデフォルトVCを用
いて送信される。
【0076】以下では、メッセージ交換の様子を示す図
(図15)と、下流側のルータ(図15ではR4)内部の動作
図(図4 、図5 )と、上流側のルータ(図15ではR2)内
部の動作図(図6 )を用いて、ルータ4 がマルチキャス
トグループG のパケットのための資源予約を行う手順を
述べる。
【0077】はじめに、図15のようにホスト3 からデフ
ォルトVCで、RSVPの予約(RESV)メッセージがルータ4
に到着したとする。なお、これはマルチキャスト用のデ
フォルトVCを用いて上流から下流へ転送されたRSVPのPa
thメッセージに応答してホスト3 が送信したものであ
る。
【0078】RESVメッセージには、どのパケットに対し
て予約すべきか示すためのFlow IDと予約したいQOS が
書かれている。Flow ID には、発信元IPアドレス/ポー
ト、宛先IPアドレス/ポートの組、あるいは、IPv6 の
Flow ID が書かれている。QOS には、帯域の情報や遅延
の情報が書かれている。
【0079】RESVメッセージを受信したルータ4は、図
4 及び図5 のフローチャートに従い、RSVPメッセージ中
のFlow ID 用の下流側の専用VCがあるかチェックする
(S1)。この例では、下流側に専用VCが無いので、IP
処理部で要求された資源を確保できるか判断し(S
3)、資源予約できる場合には専用VC依頼メッセージを
上流に送出し(S2)、資源予約できない場合には、RE
SV ERRORを下流ノードに送出する(S4)。ここでは、
資源予約が出来たとして話を進める。
【0080】専用VC依頼メッセージを受信したルータ2
は、図6 のフローチャートに従い、ATM シグナリングを
用いて、専用VC依頼メッセージを送信したノード(ルー
タ2)への、要求QOS を満たせるATM コネクション(専
用VC)を設定する(S21)。この場合のシグナリング
は、ADD PARTY であり、ルータ2からルータ3への専用
VCが経由するスイッチのいずれかから分岐してルータ4
に達する新たなリンクを既に存在する専用VCに追加する
ことになる。
【0081】ATM コネクションの設定が終わると、この
コネクションを両端で一意に識別できるように、ルータ
2からルータ3への専用VCを設定したときに定めたVCID
を、VCID提案メッセージを新しくリーフを追加したATM
コネクション(専用VC)に流すことで、下流ノードに運
ぶ(S22)。このメッセージには、送信者側(ルータ
2)が提案するVCIDと、ターゲットIPアドレス(ルータ
4のIPアドレス)とが入っている。
【0082】このVCID提案メッセージを受信したノード
(ルータ3、ルータ4 )は、このメッセージに含まれる
ターゲットIPアドレスが自ノードのIPアドレスであるか
否かを調べ(S11)、そうである場合は、このVCIDを
許容するならば、VCID ACKをp-p のデフォルトVCで上流
ノード(ルータ2)に送信する(S12)。VCID ACK
は、少なくとも送信者側が提案し自ノードが許容したVC
IDが入っている。この手続きにより、VCIDの交換が終了
する。ここでは、ルータ4がターゲットであるので、ル
ータ4 のみVCID ACKを上流ノードに送信する。
【0083】VCID交換が終了し、専用VCが使用可能であ
ることを下流側のノード(ルータ4)に知らせるため
に、ルータ2 からルータ4 へ専用VC通知メッセージ
を送信する(S23)。このメッセージは、p-p のデフ
ォルトVC(すなわちパケット送信に用いられる専用VCと
は異なるVC)にて、送信する。このメッセージには、Fl
ow ID とVCIDが含まれる。
【0084】この専用VC通知メッセージを受信したノー
ド(ルータ4)は、そのVCIDで特定される専用VCは、そ
のFlow ID で特定されるフロー専用に使えることが分か
る。下流側のFlow ID 用の専用VCがあることをチェック
して、専用VCが無いことが分かるので(S13ない)、
上流側の専用VCで受信したパケットをIP処理部に渡すよ
うに設定する(S16)。なお、専用VCがある場合は、
直結する。
【0085】なお、ルータ4には、ADD PARTY によって
専用VCに自分へのリーフが追加された時点から、パケッ
トが送信されてくるが、専用VC通知メッセージを受信す
るまでは、このパケットの扱いが分からないため無視
し、専用VC通知を受けて必要な設定がされるまでは、マ
ルチキャスト用デフォルトVCにて送信されてくるパケッ
トをIP処理部に渡してホスト3への転送を行っている。
【0086】こうして専用VCが使用可能になると、上流
側にリダイレクトメッセージを送出する(S15)。リ
ダイレクトメッセージは、Flow ID とVCIDを含み、p-p
のデフォルトVCにより送信される。
【0087】上流側のノード(ルータ2)は、リダイレ
クトメッセージを受信すると、そのFlow ID は今まで専
用VCで送出していたので(S24No)、何もしない。な
お、マルチキャストの場合の上流側のノードの動作のう
ち、図6(c)のS25は、今までマルチキャスト用デフォ
ルトVCに流していたそのFlow ID に関わるパケットを専
用VCに流すようにしたとき、マルチキャストデフォルト
VCにも同じパケットを流し続けるようにする。これは、
マルチキャストの場合は受信者毎に異なるQOS を要求す
る可能性があり、専用VCを設定せずマルチキャスト用デ
フォルトVCにてパケットを受け取っているノードが存在
するかもしれないことに対処するためである。
【0088】最後に、ルータ4でRSVPのQOS 要求を満足
することができるので、ルータ4からルータ2へ、p-p
のデフォルトVCでRESVの送出を行う(S17)。なお、
S15及びS17の順序は逆でも構わない。
【0089】以上により、ルータ4の資源予約が終了す
る。なお、上記リダイレクトメッセージを、ルータ4か
らルータ2へ適当なタイミングで定期的に送出すること
により、対応する専用VCのリーフを保持する。この保持
のためのメッセージは、上記RESVメッセージによって代
用しても構わない。リダイレクトメッセージ(代用する
場合はRESVメッセージ)が送信されてこなくなったルー
タへのリーフは削除する。
【0090】(具体例3−2)本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをインバンドで流す場合について説明する。初
期状態として、図15と同様な状況を考える。ここで、ル
ータ1 からルータ2への専用VCや、ルータ2 からルータ3
への専用VCは、具体例1−2で説明した手順により設
定されたものである。但し、具体例1−2で説明したRE
SV、リダイレクトの各メッセージは、p-p のデフォルト
VCを用いて送信される。
【0091】メッセージ交換の様子を示す図(図16)
と、下流側のルータ(図16ではR4)内部の動作図(図4
、図8 )と、上流側のルータ(図16ではR2)内部の動
作図(図9 )を用いて、ルータ4 がマルチキャストグル
ープG のパケットのための資源予約を行う手順を述べ
る。
【0092】具体例3−1から変更した点を説明する
と、図16では、VCID提案メッセージとVCID ACKメッセー
ジが無くなったことと、専用VC通知メッセージを新たに
リーフを追加したATM コネクション(専用VC)で転送す
ることが異なる。また、本例での専用VC通知メッセージ
には、Flow ID とVCIDの他に、具体例3−1ではVCID提
案メッセージに含ませていたターゲットIPアドレスを含
ませる。これにより、ルータ4 への専用VC通知を受け取
ってしまうルータ3 は、これを無視することができる。
【0093】メッセージが2つ不要となったことに伴っ
て、上流側のノード(図9 )は、VCID ACKメッセージを
受信したときの動作(S23)が無くなり、新たにリー
フを追加したATM コネクションに、VCID提案ではなく、
上述した専用VC通知を送信することになる(S31)。
下流側のノードは、RESVを受信したときの動作は図4の
通りであり、、VCID ACK提案を受信したときの動作(S
12)が無くなり、専用VC通知メッセージを受信したと
きは、図8 に示すように、このメッセージに含まれるタ
ーゲットIPアドレスが自分のアドレスであるか否かチェ
ックした後、図5(b)と同様の動作を行う。
【0094】以上の説明では、RSVPをきっかけとしてCS
R の技術を生かした資源予約を行う方法を述べたが、上
述したようにRSVPのRESVメッセージをトリガとして専用
VCを設定するのではなく、データパケットをトリガとし
て専用VCを設定することも、同様にして実現できる。
【0095】上述したRSVPをきっかけとする場合と異な
る点は、以下の2つである。一つは、RSVP有りの場合
は、RESVメッセージを受信すると専用VC依頼メッセージ
を送出したが、RSVPが無い場合は、データパケットが来
たときに、専用VC依頼メッセージを送出する点である。
その後、専用VCを設定し、これをデータパケット転送の
ために使用可能とする(直結するかもしくはIP処理をし
て転送するようにする)動作を行うことは同様である。
もう一つの違いは、専用VC通知メッセージを受信したと
きに、RESVメッセージを上流に送信しないことである。
【0096】具体的には、例えば図2のルータ2が、デ
フォルトVCにてデータパケットを受信すると、そのデー
タパケットをデフォルトVC(もしくは専用VC)にて次段
のノード(ルータ3)に転送した後、パケットに関係あ
るFlow ID を持つ専用VCを上流側に設定するよう、専用
VC依頼メッセージを上流(ルータ1)へ送出する。この
とき、上記データパケットに書かれた送信元アドレス/
ポートと宛先アドレス/ポートの組(宛先アドレス/ポ
ートだけでもよい)等をFlow ID とし、このFlow ID を
専用VC依頼メッセージに含ませる。
【0097】そして、ルータ1との間に専用VCが設定さ
れたことを専用VC通知メッセージにより知ると、そのパ
ケットに関係あるFlow ID を持つ下流側の(ルータ3へ
の)専用VCがあるならば、直結し、なければ、ルータ1
から専用VCで転送されてきたパケットをルータ3へのデ
フォルトVCで転送するようにする。また、ルータ1は、
ルータ2が専用VCを使用可能となったことをリダイレク
トメッセージにより知ると、今までデフォルトVCで転送
していたデータパケットを、専用VCで転送するようにす
る。
【0098】また、例えば図14のルータ4が、マルチ
キャスト用のデフォルトVCにてデータパケットを受信す
る(ルータ1はこの時点でルータ3のための専用VCによ
る転送とルータ4のためのデフォルトVCによる転送とを
行っている)と、そのデータパケットをデフォルトVC
(もしくは専用VC)にて次段のノード(ホスト3)に転
送した後、そのデータパケットから求めたFlow ID (こ
の場合のアドレスはマルチキャストアドレス)を持つ専
用VCを上流側に設定するよう、専用VC依頼メッセージを
p-p のデフォルトVCにて上流(ルータ2)へ送出する。
【0099】そして、ルータ2からルータ3への専用VC
にルータ4へのリーフが追加されたことを専用VC通知メ
ッセージにより知ると、そのパケットに関係あるFlow I
D を持つ下流側の専用VCがあるならば、直結し、なけれ
ば、ルータ1から専用VCで転送されてきたパケットをホ
スト3へのデフォルトVCで転送するようにする。なお、
ルータ1は、ルータ3、4からそれぞれのp-p デフォル
トVCにてリダイレクトメッセージが定期的に送信されて
くる間は、p-mp専用VCのそれぞれに対応するリーフを維
持する(リダイレクトメッセージが送信されてこなくな
ったルータへのリーフは削除する)。
【0100】なお、このようにデータパケットをきっか
けとする場合、データパケットに含まれる情報に基づい
て、上記手順を起動するデータパケット(が属するフロ
ー)を選択するようにしても良い。
【0101】(実施形態2)本実施形態では、CSR の技
術を用いて、ATM 上で資源予約プロトコルであるRSVPを
実現するための、別の方法を述べる。実施形態1では、
RSVPのRESVメッセージが到着したノードから上流側に専
用VCを設定する手順を説明したが、ここでは、RESVメッ
セージが到着したときに下流側に専用VCを設定する手順
を説明する。
【0102】(具体例1)本例では、ATM コネクション
がSVC(Switched Virtual Connection)であり、ユニキャ
ストを想定した場合について説明する。
【0103】(具体例1−1)本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをアウトバンドで流す場合について説明する。
【0104】図17のようにルータ1,2,3(R1,R2,R3)が存
在している場合に、ルータ2 での資源予約の方法を述べ
る。初期状態として、ルータ1 からルータ2 へ、ルータ
2 からルータ3 へのデフォルトVCが設定されている状況
を考える。以下では、メッセージ交換の様子を示す図
(図17)と、下流側のルータ(図17ではR2)内部の動作
図(図22、図23)と、上流側のルータ(図17ではR1)内
部の動作図(図18、図19、図20、図21)を用いて説明す
る。
【0105】はじめに、図17のようにルータ3からRSVP
のRESVメッセージがルータ2に到着したとする。RESVメ
ッセージには、Flow ID と予約したいQOS が書かれてい
る。ルータ2 は、RESVメッセージに書かれた予約したい
QOS を実現する資源予約がIPスケジューラで行えるか否
かを判断し(S61)、できる場合には、IPスケジュー
ラで資源予約する(S62)と共に、RESVメッセージを
デフォルトVCで上流側に(ルータ1 へ)転送する(S6
3)。できない場合にも、ルータ2 では今は資源予約が
できていないが、後で上流側と下流側の両方に専用VCが
設定されて直結を行うことにより資源予約ができること
を見越して、RESVメッセージを上流側に送出する(S6
3)。
【0106】RESVを送出すると、下流側に(ルータ3
へ)専用VCを設定するための動作を行う。なお、RESVメ
ッセージは、下流側の専用VCが設定された(ルータ3 か
らリダイレクトメッセージが返ってきた)後に、上流側
に送出することとしても構わない。
【0107】ここで、IPスケジューラで資源予約できる
場合にも、下流側に専用VCを設定するための動作を行う
のは、後で上流側と下流側の両方に専用VCが設定されて
直結を行うことができた場合に、このフローのための資
源予約をIPスケジューラではなくATM スイッチ機能にて
行うことで、IPスケジューラの資源になるべく余裕を持
たせ、他のフローがIPスケジューラの資源を使えるよう
にしておくためである。
【0108】RESVメッセージを受信したルータ2の動作
手順は、図18に示すように、RESVメッセージを上流に送
信した(S63)後、ATM シグナリングでATM コネクシ
ョン(専用VC)を次段ノード(ルータ3 )へ設定した
後、VCID提案メッセージをこの専用VCにて送信する(S
65)。
【0109】VCID提案メッセージを受信した下流ノード
(ルータ3)は、図22にしたがって、ターゲットIPが自
分のアドレスかチェックして(S71)、自分のアドレ
スの場合は、VCID ACKをデフォルトVCにて送信する(S
72)。
【0110】VCID ACKを受信した上流ノード(ルータ
2)は、図19にしたがって、下流側に専用VC通知をデフ
ォルトVCにて送信する(S66)。専用VC通知を受信し
た下流ノード(ルータ3)は、図23にしたがって、同じ
Flow ID を持つ下流側の(ホスト2 への)専用VCがある
かチェックして(S73)、無い場合は、上流側の(ル
ータ2 からの)専用VCで受信したパケットをIP処理部に
渡すように設定する(S74)。ある場合は、上流側の
専用VCと下流側の専用VCを直結する(S75)。最後
に、自ノードが専用VCを使用可能になったことを上流に
知らせるため、リダイレクトメッセージをデフォルトVC
で上流ノードに送信する(S76)。
【0111】リダイレクトメッセージを受信した上流ノ
ード(ルータ2)は、図20及び21にしたがって、デフォ
ルト転送を行っていない(後述するマルチキャストのよ
うに既にその専用VC上へパケット転送を行っている)場
合は(S81No)、終了する。
【0112】デフォルト転送を行っている場合は、同じ
Flow ID を持つ上流側の(ルータ1からの)専用VCがあ
るかチェックして(S82)、専用VCがある場合は、上
流側の専用VCと下流側の(ルータ3 への)専用VCを直結
する(S83)。専用VCが無い場合は、IP処理部で今ま
でデフォルトVCにて転送していたパケットを専用VCにて
転送するようにする(S84)。
【0113】このFlow ID に関して、自ノードが受信し
たパケットを転送するのではなく、自ノードが送信ノー
ドである場合は(S85Yes )、ここで終了する。それ
以外の場合は、一定時間待ち(S86)、上流側に下流
側と同じFlow IDを持つ専用VCが設定されず、上流側の
専用VCと下流側の専用VCが直結しなかったら(S87N
o)、IPスケジューラでの資源予約(S62)を行って
いたかを調べ(S88)、行っていればそのままとし、
行っていなければ、上流側(ルータ1)に、S63にて
送信したRESVメッセージを取り消すための、RESV Tear
メッセージを送信し、下流側(ルータ3 )に、資源予約
に失敗したことを示すRESV Errメッセージを送信する。
なお、S88で改めてIPスケジューラの資源予約ができ
るかを調べ直しても構わない。
【0114】また、一定時間内に、上流側に下流側と同
じFlow ID を持つ専用VCが設定され、上流側の専用VCと
下流側の専用VCが直結されれば(S87Yes )、IPスケ
ジューラでの資源予約(S62)を行っていたかを調べ
(S90)、行っていなければそのままとし、行ってい
れば、この資源予約は専用VCの直結により不要となって
いるから、取り消す(S91)。
【0115】なお、上記の説明では、先にIPスケジュー
ラの資源予約を行ってから、専用VCが直結できたらこ
れを取り消すこととしたが、専用VCの直結ができる可
能性が高い場合には、IPスケジューラの資源予約は行わ
ずに下流側に専用VCを設定し、上流側に専用VCができる
のを待ってできたら直結し、直結ができないことを確認
した時点(S87No)でIPスケジューラの資源予約を試
み、資源予約できればそのままとし、できなければ上流
にRESV Tear を、下流にRESV Errを返すこととしても構
わない。
【0116】以上により、ルータ2 の資源予約が終了す
る。なお、上記リダイレクトメッセージを、ルータ3か
らルータ2へ適当なタイミングで定期的に送出すること
により、対応する専用VCを保持する。この保持のための
メッセージは、RESVメッセージによって代用しても構わ
ない。リダイレクトメッセージ(代用する場合はRESVメ
ッセージ)が送信されてこなくなったルータへの専用VC
は解放する。
【0117】(具体例1−2)本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをインバンドで流す場合について説明する。具
体例1−1で説明した手順では、ATM シグナリングを行
った後、VCID提案、VCID ACK、専用VC通知と3つのメッ
セージを送信していたが、専用VC通知メッセージを新た
に作ったATM コネクション(専用VC)に流すことで、VC
ID提案メッセージとVCID ACKを省略することが可能であ
る。
【0118】具体的なシーケンス図を図24で示し、下
流側のノードのフローチャートを図20、21、25
に、上流側のノードのフローチャートを図26に示す。
具体例1−1から変更した点を説明すると、図24で
は、VCID提案メッセージとVCID ACKメッセージが無くな
ったことと、専用VC通知メッセージを新たに作ったATM
コネクション(専用VC)で転送することが異なる。ま
た、本例での専用VC通知メッセージには、Flow ID とVC
IDの他に、具体例1−1ではVCID提案メッセージに含ま
せていたターゲットIPアドレスを含ませる。
【0119】メッセージが2つ不要となったことに伴っ
て、上流側のノードは、VCID ACKメッセージを受信した
ときの動作(図19)が無くなり、新たに作ったATM コ
ネクションに、VCID提案ではなく、上述した専用VC通知
を送信することになる(図25のS105)。
【0120】下流側のノードは、VCID ACK提案を受信し
たときの動作(図22)が無くなり、専用VC通知メッセ
ージを受信したときは、図26に示すように、このメッ
セージに含まれるターゲットIPアドレスが自分のアドレ
スであるか否かチェック(S111)した後、図23と
同様の動作を行う。
【0121】(具体例2)本例では、ATM コネクション
がVP(Virtual Path)のコネクションであり、ユニキャス
トを想定した場合について説明する。図27のようにル
ータ1,2,3(R1,R2,R3)が存在している場合に、ルータ2
での資源予約の方法を述べる。初期状態として、ルータ
1 からルータ2 へ、ルータ2からルータ3 へのデフォル
トVCが設定されている状況を考える。以下では、メッセ
ージ交換の様子を示す図(図27)と下流側のルータ内
部の動作図(図23)と上流側のルータ内部の動作(図
20、21、28)を用い、具体例1から変更した点を
説明する。
【0122】図17では、予約(RESV)メッセージを受
信すると、ATM シグナリング、VCID提案、VCID ACKを行
っていたが、VPの場合は、予めATM コネクションがあ
り、VCIDとしてVPI/VCI を利用することが出来るので、
これらのメッセージが図27では無い。
【0123】この3つのメッセージ転送が無いために、
上流側ノードでは、図18のS65のVCID提案メッセー
ジ送信の代わりに、図28のS125の専用VC通知メッ
セージを送信する。また、図19のVCID ACK受信に対す
る動作が無い。下流側ノードでは、図22のVCID提案受
信した場合の動作が無い。
【0124】(具体例3)本例では、ATM コネクション
がSVC であり、マルチキャストを想定した場合について
説明する。
【0125】(具体例3−1)本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをアウトバンドで流す場合について説明する。
初期状態として、図29のように、ルータ2 からルータ
3 とルータ4へ、マルチキャスト用のデフォルトVC(p-
mpとなり得る( ここでは既になっている)VC )が設定さ
れ、ルータ2からルータ3へのp-mpとなり得る(ここで
はまだなっていない)専用VCが設定され、ルータ1とル
ータ2間に(p-p の)デフォルトVCが設定されている状
況を考える。ルータ2 からルータ3 への専用VCは、マル
チキャストグループG の専用VCとする。
【0126】ここで、ルータ1から2への専用VCや、ル
ータ2から3への専用VCは、具体例1−1で説明した手
順により設定されたものである。但し、具体例1−1で
説明したRESV、VCID ACK、専用VC通知、リダイレクトの
各メッセージは、p-p のデフォルトVCを用いて送信され
る。
【0127】以下では、メッセージ交換の様子を示す図
(図29)と、下流側のルータ(図29ではR4)内部の
動作図(図22、図23)と、上流側のルータ(図29
ではR2)内部の動作図(図18、19、20、21)を
用いて、ルータ2がマルチキャストグループG のパケッ
トのための資源予約を行う手順を述べる。
【0128】はじめに、図29のようにルータ4からデ
フォルトVCで、RSVPの予約(RESV)メッセージがルータ
2に到着したとする。なお、これはマルチキャスト用の
デフォルトVCを用いて上流から下流へ転送されたRSVPの
Pathメッセージに応答してルータ4が送信したものであ
る。
【0129】RESVメッセージには、どのパケットに対し
て予約すべきか示すためのFlow IDと予約したいQOS が
書かれている。RESVメッセージを受信したルータ2は、
図18のフローチャートに従い、IPスケジューラで資源
予約出来るかチェックする(S 61)。資源予約出来る
場合は、資源予約した後(S 62)、予約(RESV)メッ
セージを上流に送信する(S 63)。資源予約出来なか
った場合は、資源予約をせずに、予約メッセージを上流
に送信する(S 63)。
【0130】次にATM シグナリングでATM コネクション
を下流ノードに設定した後(S64)、VCID提案メッセ
ージを設定したATM コネクションで送信する(S 6
5)。このVCID提案メッセージには、ターゲットIPアド
レスと VCID が書かれている。ここで、ターゲットIPア
ドレスは、ルータ4 のアドレスが入っている。
【0131】VCID提案メッセージは、ルータ3とルータ
4が受信する。これを受信したノードは、図22のフロ
ーチャートに従い、ターゲットIPアドレスが自分のアド
レスかチェックする。VCID提案メッセージのターゲット
IPアドレスは、ルータ4 になっており、ルータ3 では、
自分のIPアドレスと異なる(S 71No)ので、何もせず
に終了する。ルータ4では、自分のIPアドレスを同じな
ので(S 71yes)、VCID ACKを上流に送信する(S 7
2)。
【0132】VCID交換が終了し、専用VCが使用可能であ
ることを下流側のノード(ルータ4)に知らせるため
に、ルータ2からルータ4へ専用VC通知メッセージを送
信する(図19のS 66)。このメッセージは、p-p の
デフォルトVCにて、送信する。このメッセージには、Fl
ow ID とVCIDが含まれる。
【0133】この専用VC通知メッセージを受信したノー
ド(ルータ4)は、そのVCIDで特定される専用VCは、そ
のFlow ID で特定されるフロー専用に使えることが分か
る。図23に従い、下流側のFlow ID 用の専用VCがある
ことをチェックして、専用VCが無いことが分かるので
(S73なし)、上流側の専用VCで受信したパケット
をIP処理部に渡すように設定する(S74)。なお、専
用VCがある場合は、直結する。
【0134】なお、ルータ4には、ADD PARTY によって
専用VCに自分へのリーフが追加された時点から、パケッ
トが送信されてくるが、専用VC通知メッセージを受信す
るまでは、このパケットの扱いが分からないため無視
し、専用VC通知を受けて必要な設定がされるまでは、マ
ルチキャスト用デフォルトVCにて送信されてくるパケッ
トをIP処理部に渡して転送を行っている。
【0135】こうして専用VCが使用可能になると、上流
側にリダイレクトメッセージを送出する(S76)。リ
ダイレクトメッセージは、Flow ID とVCIDを含み、p-p
のデフォルトVCにより送信される。
【0136】上流側のノード(ルータ2)は、リダイレ
クトメッセージを受信すると、そのFlow ID は今まで専
用VCで送出していたので(S81No)、何もしない。な
お、マルチキャストの場合の上流側のノードの動作のう
ち、図20のS84は、今までマルチキャスト用デフォ
ルトVCに流していたそのFlow ID に関わるパケットを専
用VCに流すようにしたとき、マルチキャストデフォルト
VCにも同じパケットを流し続けるようにする。これは、
マルチキャストの場合は受信者毎に異なるQOS を要求す
る可能性があり、専用VCを設定せずマルチキャスト用デ
フォルトVCにてパケットを受け取っているノードが存在
するかもしれないことに対処するためである。
【0137】S 84を終了したあとの処理は、具体例1
ー1と同様である。以上により、ルータ2のルータ4に
関する資源予約が終了する。なお、上記リダイレクトメ
ッセージを、ルータ4からルータ2へ適当なタイミング
で定期的に送出することにより、対応する専用VCのリー
フを保持する。この保持のためのメッセージは、RESVメ
ッセージによって代用しても構わない。リダイレクトメ
ッセージ(代用する場合はRESVメッセージ)が送信され
てこなくなったルータへのリーフは削除する。
【0138】(具体例3−2)本例では、あるフローに
属するパケットをどの専用VCで送信するかを通知するメ
ッセージをインバンドで流す場合について説明する。初
期状態として、図30のように、ルータ2 からルータ3
とルータ4へ、マルチキャスト用のデフォルトVC(p-mp
となり得る( ここでは既になっている)VC )が設定さ
れ、ルータ2からルータ3へのp-mpとなり得る(ここで
はまだなっていない)専用VCが設定され、ルータ1とル
ータ2間に(p-p の)デフォルトVCが設定されている状
況を考える。ルータ2 からルータ3 への専用VCは、マル
チキャストグループG の専用VCとする。
【0139】具体例3−1で説明した手順では、ATM シ
グナリングを行った後、VCID提案、VCID ACK、専用VC通
知と3つのメッセージを送信していたが、専用VC通知メ
ッセージを新たに作ったATM コネクション(専用VC)に
流すことで、VCID提案メッセージとVCID ACKを省略する
ことが可能である。
【0140】具体的なシーケンス図を図30で示し、下
流側のノード(図30ではR4)のフローチャートを図2
0、21、25に、上流側のノード( 図30ではR2) の
フローチャートを図26に示す。
【0141】具体例3ー1から変更した点を説明する
と、VCID提案メッセージを送出する代わりに、専用VC通
知メッセージを新たに作ったATM コネクション(専用V
C)で転送することが異なる。また、本例での専用VC通
知メッセージには、Flow ID とVCIDの他に、具体例1−
1ではVCID提案メッセージに含ませていたターゲットIP
アドレスを含ませる。
【0142】メッセージが2つ不要となったことに伴っ
て、上流側のノードは、VCID ACKメッセージを受信した
ときの動作(図19)が無くなり、新たに作ったATM コ
ネクションに、VCID提案ではなく、上述した専用VC通知
を送信することになる(図25のS105)。
【0143】下流側のノードは、VCID ACK提案を受信し
たときの動作(図22)が無くなり、専用VC通知メッセ
ージを受信したときは、図26に示すように、このメッ
セージに含まれるターゲットIPアドレスが自分のアドレ
スであるか否かチェック(S111)した後、図23と
同様の動作を行う。
【0144】以上の説明では、RSVPをきっかけとしてCS
R の技術を生かした資源予約を行う方法を述べたが、上
述したようにRSVPのRESVメッセージをトリガとして専用
VCを設定するのではなく、データパケットをトリガとし
て専用VCを設定することも、同様にして実現できる。
【0145】上述したRSVPをきっかけとする場合と異な
る点は、以下の2つである。一つは、RSVP有りの場合
は、RESVメッセージを受信するとATM シグナリングを行
い下流に専用VCを設定したが、RSVPが無い場合は、デー
タパケットが来たときに、これを行う点である。その
後、設定した専用VCをデータパケット転送のために使用
可能とする(直結するかもしくはIP処理をして転送する
ようにする)動作を行うことは同様である。もう一つの
違いは、RESVメッセージ、RESV Tear を上流に送信しな
いことである。
【0146】具体的には、例えば図2のルータ2が、デ
フォルトVCもしくは専用VCにてデータパケットを受信す
ると、そのデータパケットをデフォルトVCにて次段のノ
ード(ルータ3)に転送した後、パケットに関係あるFl
ow ID を持つ次段のノードへの専用VCを設定するよう、
ATM シグナリングを行う。そして、上記データパケット
に書かれた送信元アドレス/ポートと宛先アドレス/ポ
ートの組(宛先アドレス/ポートだけでもよい)等をFl
ow ID とし、このFlow ID を書き込んだ専用VC通知メッ
セージを下流に送出する。
【0147】そして、ルータ2 は、ルータ3 がこの専用
VCを使用可能になったことをリダイレクトメッセージに
より知ると、そのパケットに関係あるFlow ID を持つ上
流側の(ルータ1 からの)専用VCがあるならば、直結
し、なければ、ルータ1からデフォルトVCで転送されて
きたパケットをルータ3への専用VCで転送するようにす
る。
【0148】また、例えば図14のルータ2が、IPマル
チキャスト用のプロトコル(例えばIGMP(Internet Grou
p Management Protocol))により、ルータ4 がマルチキ
ャストグループG に参加したことを認識すると、それに
関係するFlow ID (この場合のアドレスはマルチキャス
トアドレス)を持つ専用VCを下流側に設定するよう、AD
D PARTY を行う。そして、ルータ2からルータ3への専
用VCにルータ4へのリーフが追加される。なお、ルータ
2 は、ルータ3、4からそれぞれのp-p デフォルトVCに
てリダイレクトメッセージが定期的に送信されてくる間
は、p-mp専用VCのそれぞれに対応するリーフを維持する
(リダイレクトメッセージが送信されてこなくなったル
ータへのリーフは削除する)。
【0149】なお、このようにデータパケットをきっか
けとする場合、データパケットに含まれる情報に基づい
て、上記手順を起動するデータパケット(が属するフロ
ー)を選択するようにしても良い。
【0150】
【発明の効果】以上詳述したように、本発明の第一乃至
第四の発明によれば、ネットワークレイヤのスケジュー
リングのみによっては、資源予約のためのメッセージに
示される要求サービス品質を満たすことができない場合
にも、ネットワークレイヤより下位のレイヤでの仮想コ
ネクションのスイッチング機能の利用により要求された
資源の予約を可能とし、かつ、自ノードで資源予約が行
えたか否かを正しく他のノードに伝えることができる。
【0151】また、本発明の第五の発明によれば、ルー
タがネットワークレイヤより下位のレイヤでの仮想コネ
クションのスイッチング機能を利用しつつマルチキャス
ト通信を行う際に、この通信のためのコネクション及び
ルータ内の設定を効率よく行うことができる。
【0152】また、本発明の第六の発明によれば、ルー
タ間にスイッチの存在するシステムでマルチキャスト通
信を行う際に、この通信のためのコネクションを両端の
ルータで一意に識別し、必要なコネクション及びルータ
内の設定を効率よく行うことができる。
【図面の簡単な説明】
【図1】 CSR の動作を説明するための図。
【図2】 ユニキャストの場合のネットワークトポロジ
ーの例を示す図。
【図3】 実施形態1の具体例1−1のメッセージ交換
の様子を示す図。
【図4】 実施形態1の下流側のノードの動作例を示す
図。
【図5】 実施形態1の下流側のノードの動作例を示す
図。
【図6】 実施形態1の上流側のノードの動作例を示す
図。
【図7】 実施形態1の具体例1−2のメッセージ交換
の様子を示す図。
【図8】 実施形態1の下流側のノードの別の動作例を
示す図。
【図9】 実施形態1の上流側のノードの別の動作例を
示す図。
【図10】 実施形態1の具体例2のメッセージ交換の
様子を示す図。
【図11】 実施形態1の下流側のノードの更に別の動
作例を示す図。
【図12】 実施形態1の下流側のノードの更に別の動
作例を示す図。
【図13】 実施形態1の上流側のノードの更に別の動
作例を示す図。
【図14】 マルチキャストの場合のネットワークトポ
ロジーの例を示す図。
【図15】 実施形態1の具体例3−1のメッセージ交
換の様子を示す図。
【図16】 実施形態1の具体例3−2のメッセージ交
換の様子を示す図。
【図17】 実施形態2の具体例1−1のメッセージ交
換の様子を示す図。
【図18】 実施形態2の上流側のノードの動作例を示
す図。
【図19】 実施形態2の上流側のノードの動作例を示
す図。
【図20】 実施形態2の上流側のノードの動作例を示
す図。
【図21】 実施形態2の上流側のノードの動作例を示
す図。
【図22】 実施形態2の下流側のノードの動作例を示
す図。
【図23】 実施形態2の下流側のノードの動作例を示
す図。
【図24】 実施形態2の具体例1−2のメッセージ交
換の様子を示す図。
【図25】 実施形態2の上流側のノードの別の動作例
を示す図。
【図26】 実施形態2の下流側のノードの別の動作例
を示す図。
【図27】 実施形態2の具体例2のメッセージ交換の
様子を示す図。
【図28】 実施形態2の上流側のノードの更に別の動
作例を示す図。
【図29】 実施形態2の具体例3−1のメッセージ交
換の様子を示す図。
【図30】 実施形態2の具体例3−2のメッセージ交
換の様子を示す図。
───────────────────────────────────────────────────── フロントページの続き (58)調査した分野(Int.Cl.7,DB名) H04L 12/00 - 12/66

Claims (9)

    (57)【特許請求の範囲】
  1. 【請求項1】仮想コネクション型ネットワークとの物理
    インタフェースを有し、少なくとも2つの論理ネットワ
    ークを接続するルータ装置において、 一方の前記論理ネットワークからの受信に使用される仮
    想的転送路と他方の前記論理ネットワークへの送信に使
    用される仮想的転送路との対応関係を記憶する記憶手段
    と、 この記憶された対応関係に従って、パケットの転送を行
    う転送手段と、 資源予約のためのメッセージを受信者側の論理ネットワ
    ークから受信する受信手段と、 この受信した資源予約のためのメッセージに基づき、前
    記受信者側の論理ネットワークへの前記転送手段を介す
    ることが可能なパケット送信用の仮想的転送路の存在、
    及び、送信者側の論理ネットワークからの前記転送手段
    を介することが可能なパケット受信用の仮想的転送路の
    存在の有無に応じて、資源予約のためのメッセージを前
    記送信者側の論理ネットワークへ送信する送信手段とを
    具備したことを特徴とするルータ装置。
  2. 【請求項2】前記送信手段は、送信用の前記仮想的転送
    路の設定要求に対する応答を受信した場合に、前記受信
    手段により受信したメッセージに基づく資源予約のため
    のメッセージを、前記両仮想的転送路の存在の有無によ
    らず送信者側の論理ネットワークへ送信する手段をさら
    に備えるものである請求項1に記載のルータ装置。
  3. 【請求項3】前記受信手段により受信したメッセージに
    応じて、送信者側の論理ネットワークからの前記転送手
    段を介することが可能なパケット受信用の仮想的転送路
    を設定するよう前記送信者側の論理ネットワークへ要求
    する要求手段を更に具備する請求項1又は2に記載のル
    ータ装置。
  4. 【請求項4】仮想コネクション型ネットワークとの物理
    インタフェースを有し、少なくとも2つの論理ネットワ
    ークを接続するルータ装置において、 一方の前記論理ネットワークからの受信に使用される仮
    想的転送路と他方の前記論理ネットワークへの送信に使
    用される仮想的転送路との対応関係を記憶する記憶手段
    と、 この記憶された対応関係に従って、パケットの転送を行
    う転送手段と、 資源予約のためのメッセージを受信者側の論理ネットワ
    ークから受信する受信手段と、 この受信した資源予約のためのメッセージに基づき、資
    源予約のためのメッセージを送信者側の論理ネットワー
    クへ送信する送信手段と、 前記受信者側の論理ネットワークへの前記転送手段を介
    することが可能なパケット送信用の仮想的転送路の存
    在、及び、前記送信者側の論理ネットワークからの前記
    転送手段を介することが可能なパケット受信用の仮想的
    転送路の存在の有無に応じて、前記送信手段により送信
    した資源予約のためのメッセージの取り消しを通知する
    通知手段とを具備したことを特徴とするルータ装置。
  5. 【請求項5】前記通知手段は、前記転送手段による転送
    を行わないと前記受信手段により受信したメッセージに
    示される要求サービス品質を満たすことができないと判
    断した場合に、前記両仮想的転送路の存在の有無に応じ
    た通知を行うものである請求項4に記載のルータ装置。
  6. 【請求項6】前記受信手段により受信したメッセージに
    応じて、前記受信者側の論理ネットワークへの前記転送
    手段を介することが可能なパケット送信用の仮想的転送
    路を設定する設定手段を更に具備する請求項4又は5に
    記載のルータ装置。
  7. 【請求項7】前記転送手段による転送を行わないと前記
    受信手段により受信したメッセージに示される要求サー
    ビス品質を満たすことができないと判断し、かつ、前記
    両仮想的転送路の少なくとも一方の不存在を確認した場
    合に、資源予約に失敗した旨のメッセージを前記受信者
    側の論理ネットワークへ送信する手段を更に具備する請
    求項5乃至6に記載のルータ装置。
  8. 【請求項8】第1のノードから送信されるパケットを、
    前記第1のノードとは異なる論理ネットワークに属する
    第2のノードへ転送するパケット転送方法において、 資源予約のためのメッセージを前記第2のノードから受
    信し、 前記第1のノードから前記第2のノードへネットワーク
    レイヤレベルの転送処理の一部又は全部を行わずにパケ
    ット転送を行うことを可能とするように設定された、前
    記第1のノードからのパケットを受信可能な仮想的転送
    路と、前記第2のノードへのパケットを送信可能な仮想
    的転送路とが設定可能な場合に、これら仮想的転送路の
    対応関係を記憶すると共に、前記両仮想的転送路の有無
    に応じて資源予約のためのメッセージを前記第1のノー
    ドへ送信し、 パケットを受信した場合に、この受信に用いられた仮想
    的転送路についての前記対応関係が記憶されているなら
    ば、この対応関係に従って前記パケットを転送すること
    を特徴とするパケット転送方法。
  9. 【請求項9】第1のノードから送信されるパケットを、
    前記第1のノードとは異なる論理ネットワークに属する
    第2のノードへ転送するパケット転送方法において、 資源予約のためのメッセージを前記第2のノードから受
    信し、 この受信を受けて、資源予約のためのメッセージを前記
    第1のノードへ送信し、 前記第1のノードから前記第2のノードへネットワーク
    レイヤレベルの転送処理の一部又は全部を行わずにパケ
    ット転送を行うことを可能とするように設定された、前
    記第1のノードからのパケットを受信可能な仮想的転送
    路と、前記第2のノードへのパケットを送信可能な仮想
    的転送路との少なくとも一方が存在しない場合に、送信
    した前記資源予約のためのメッセージの取り消しを前記
    第1のノードに通知し、 前記両仮想的転送路が存在する場合に、これら仮想的転
    送路の対応関係を記憶し、 パケットを受信した場合に、この受信に用いられた仮想
    的転送路についての前記対応関係が記憶されているなら
    ば、この対応関係に従って前記パケットを転送すること
    を特徴とするパケット転送方法。
JP08024096A 1996-04-02 1996-04-02 ルータ装置及びパケット転送方法 Expired - Fee Related JP3529541B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP08024096A JP3529541B2 (ja) 1996-04-02 1996-04-02 ルータ装置及びパケット転送方法
US08/825,935 US6515999B1 (en) 1996-04-02 1997-04-01 Router apparatus and method of using a virtual connection to transfer a packet

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP08024096A JP3529541B2 (ja) 1996-04-02 1996-04-02 ルータ装置及びパケット転送方法

Related Child Applications (2)

Application Number Title Priority Date Filing Date
JP2003347064A Division JP2004015838A (ja) 2003-10-06 2003-10-06 仮想的転送路形成方法
JP2003432224A Division JP2004140869A (ja) 2003-12-26 2003-12-26 ルータ装置及びパケット転送方法

Publications (2)

Publication Number Publication Date
JPH09270816A JPH09270816A (ja) 1997-10-14
JP3529541B2 true JP3529541B2 (ja) 2004-05-24

Family

ID=13712812

Family Applications (1)

Application Number Title Priority Date Filing Date
JP08024096A Expired - Fee Related JP3529541B2 (ja) 1996-04-02 1996-04-02 ルータ装置及びパケット転送方法

Country Status (2)

Country Link
US (1) US6515999B1 (ja)
JP (1) JP3529541B2 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6046999A (en) * 1996-09-03 2000-04-04 Hitachi, Ltd. Router apparatus using ATM switch
US6335927B1 (en) * 1996-11-18 2002-01-01 Mci Communications Corporation System and method for providing requested quality of service in a hybrid network
US6304912B1 (en) * 1997-07-24 2001-10-16 Fujitsu Limited Process and apparatus for speeding-up layer-2 and layer-3 routing, and for determining layer-2 reachability, through a plurality of subnetworks
JP3699837B2 (ja) * 1998-10-30 2005-09-28 株式会社東芝 ルータ装置及びラベルスイッチパス制御方法
US6370621B1 (en) * 1998-12-21 2002-04-09 Advanced Micro Devices, Inc. Memory cancel response optionally cancelling memory controller's providing of data in response to a read operation
US6931645B2 (en) * 2000-12-15 2005-08-16 Microsoft Corporation Methods and systems for canceling requests for the transmission of data
US7664119B2 (en) * 2001-03-30 2010-02-16 Intel Corporation Method and apparatus to perform network routing
US20070171825A1 (en) * 2006-01-20 2007-07-26 Anagran, Inc. System, method, and computer program product for IP flow routing
US8547843B2 (en) * 2006-01-20 2013-10-01 Saisei Networks Pte Ltd System, method, and computer program product for controlling output port utilization
US7848257B1 (en) * 2008-10-08 2010-12-07 Sprint Spectrum L.P. Synchronizing reservation status between an access terminal and an access node

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5282270A (en) * 1990-06-06 1994-01-25 Apple Computer, Inc. Network device location using multicast
JP2646948B2 (ja) * 1992-12-25 1997-08-27 日本電気株式会社 パケット網におけるシグナリング方式
JP2570963B2 (ja) * 1993-05-31 1997-01-16 日本電気株式会社 パケット網における中継経路情報を用いたシグナリング方式
US5461611A (en) * 1994-06-07 1995-10-24 International Business Machines Corporation Quality of service management for source routing multimedia packet networks
JP2871469B2 (ja) * 1994-07-19 1999-03-17 日本電気株式会社 Atm網構成管理方法
US5541927A (en) * 1994-08-24 1996-07-30 At&T Corp. Method of multicasting
JP3224963B2 (ja) * 1994-08-31 2001-11-05 株式会社東芝 ネットワーク接続装置及びパケット転送方法
JP3150864B2 (ja) * 1995-02-27 2001-03-26 三菱電機株式会社 Atm通信ネットワークシステム及びatm通信装置
JP3515263B2 (ja) 1995-05-18 2004-04-05 株式会社東芝 ルータ装置、データ通信ネットワークシステム、ノード装置、データ転送方法及びネットワーク接続方法
US5732078A (en) * 1996-01-16 1998-03-24 Bell Communications Research, Inc. On-demand guaranteed bandwidth service for internet access points using supplemental user-allocatable bandwidth network
US5892924A (en) * 1996-01-31 1999-04-06 Ipsilon Networks, Inc. Method and apparatus for dynamically shifting between routing and switching packets in a transmission network
US6021263A (en) * 1996-02-16 2000-02-01 Lucent Technologies, Inc. Management of ATM virtual circuits with resources reservation protocol

Also Published As

Publication number Publication date
US6515999B1 (en) 2003-02-04
JPH09270816A (ja) 1997-10-14

Similar Documents

Publication Publication Date Title
JP3701476B2 (ja) データ通信方法
JP3480801B2 (ja) パケット転送方法及びノード装置
US6144661A (en) Network node apparatus and virtual connection control method for providing various service attributes in multicast communication
JP3332733B2 (ja) ノード装置及びパケット転送方法
US5953312A (en) Method and apparatus for determining alternate routes in a network using a connection-oriented protocol
JP3688408B2 (ja) パケット転送制御方法及びノード装置
US5805072A (en) VC connection method
JPH10190701A (ja) 高速atmセル伝送を使用したインターネットプロトコルスイッチング方法及びそのためのネットワーク
JP2004140539A (ja) 情報ルーティング方式および情報中継装置
JP2003333083A (ja) データパケットネットワークのサブネットワーク内におけるセルシーケンスとしてのデータパケット転送方法
JP3529541B2 (ja) ルータ装置及びパケット転送方法
JP2000341294A (ja) パケット中継装置
EP1418716A1 (en) Communication control system, communication control method, routing controller and router suitably used for the same
JP4268977B2 (ja) パケットスイッチングネットワークに用いるパケットスイッチ装置
JP3878483B2 (ja) 通信ノードにおける呼処理方法
JPH10341236A (ja) パケットスイッチングネットワーク及びパケットスイッチ装置
US7512130B2 (en) Optical communication network system
JP3120770B2 (ja) コネクション経路変更装置とその変更方法及びノードとコネクション経路変更システム
JP2004015838A (ja) 仮想的転送路形成方法
JP3482634B2 (ja) Ip網での通信資源予約方法
JP2004140869A (ja) ルータ装置及びパケット転送方法
JP3132842B2 (ja) ラベル交換網におけるコネクションレス型通信方式とコネクション型通信方式との多重方式
JP3848954B2 (ja) パケットスイッチングネットワーク及びパケットスイッチ装置
KR100265075B1 (ko) 논리적 백본 링크 구성 방법
JP3696166B2 (ja) ノード装置及びパケット転送方法

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20031226

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20040115

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: 20040217

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20040225

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080305

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090305

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100305

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees