JP2000036819A - データ通信システムおよび通信方法 - Google Patents

データ通信システムおよび通信方法

Info

Publication number
JP2000036819A
JP2000036819A JP32208498A JP32208498A JP2000036819A JP 2000036819 A JP2000036819 A JP 2000036819A JP 32208498 A JP32208498 A JP 32208498A JP 32208498 A JP32208498 A JP 32208498A JP 2000036819 A JP2000036819 A JP 2000036819A
Authority
JP
Japan
Prior art keywords
data
node
communication
relay node
transmission
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.)
Granted
Application number
JP32208498A
Other languages
English (en)
Other versions
JP3352038B2 (ja
Inventor
Kiyoshi Oguri
清 小栗
Hiroshi Nakada
広 中田
Tsunemichi Shiozawa
恒道 塩澤
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.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone 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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP32208498A priority Critical patent/JP3352038B2/ja
Publication of JP2000036819A publication Critical patent/JP2000036819A/ja
Application granted granted Critical
Publication of JP3352038B2 publication Critical patent/JP3352038B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

(57)【要約】 【課題】本発明は、受信側で輻輳状態が生じていても、
データが非所望に廃棄されないようにすることを目的と
している。 【解決手段】自ノードに到着したデータパケットを再度
通信路に送り出して通信路をデータパケットを記憶する
バッファとして機能させ、いわば後刻に取り込むように
する。

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は、ATM通信のよう
に送信データが送信先の情報をもつパケットとして送信
される通信ネットワークを適用対象としたデータ通信シ
ステムおよび通信方法に関し、特に複数の中継ノードを
介する情報データをやり取りするコンピュータ間通信の
ような通信に対し、中継ノードや受信ノードで輻輳した
際に対応するようにしたデータ通信システムおよびその
通信方法に関する。
【0002】
【従来の技術】電気通信の標準化機関であるITU(国
際電気通信連合、International Telecommunications U
nion)で広帯域ISDN(Broadband ISDN:B-ISDN)用
の転送方式として非同期転送モード(ATM:Asynchro
nous Transfer Mode)技術が採用されている。このAT
M技術を用い、実時間情報転送を必要とするマルチメデ
ィアサービス(コンピュータ間のパケット通信も含む)
の実現やPBX,CATV,LANなど複数サービス種
別を統合するバックボーン網の構築が検討されている。
【0003】このATM方式に基づく情報転送では、全
ての情報がセルと呼ばれる、5バイトの送信情報と48
バイトのデータの合計53byte固定長の情報ブロックの
形で伝送媒体上を多重伝送される。
【0004】また、これまでの通常のネットワークは、
ハイアラーキカルな構造を持っている。例えば、世界標
準として統一されたSDH(Synchronous Digital Hier
archy)インターフェ−スでは、156bit/s ×N(N=
1,4,・・・)を基本としたハイアラーキとなってい
る。このハイアラーキの各インターフェ−スの上側を基
幹ノード、下側を支線ノードと識別している。
【0005】上記のATM通信網や通常のハイアラーキ
カルな構造のネットワークにおいて、通信データの送受
信をこれまでより効率化することが望まれている。 (従来例:基本)図13に従来例の基本構成を示す。送
信ノードから送信されたデータパケットは通信路を介し
受信ノードに送られる。この受信ノードの状態によって
は、送られたデータパケットが一旦バッファに保持され
たり、またバッファに保持しきれなくなって廃棄された
りする。
【0006】この受信ノードの状態というのは、例えば
データパケットをこの受信ノードから転送するようなと
きに、受信するデータが他のノードからも多量に来るこ
とにより受信側で処理できなくなる、つまり転送側が輻
輳状態である。その転送側の輻輳以外に受信ノード自体
の内部処理で、多量なデータが一時的に発生するような
ケースも考えられる。これはたとえば、(1)受信ノー
ドが一般的な端末だった場合、グラフィック処理などで
多量のメモリを使用しているケース、(2)受信ノード
がデータベースだった場合、データベース自体の容量が
一杯になっているケース、などがある。
【0007】このような受信ノードの状態でデータパケ
ットが廃棄されると、受信側が送信側へ(破線部)再送
要求などを行い、廃棄されたデータパケットを再送する
必要が生まれる。 (従来例1:通常の通信形態)図14に従来例の通信網
やその使われ方を示す。この図に示すように通信網には
複数の中継ノードが存在している。このような、通信網
を使って、大阪のあるユーザA(ユーザ端末Aから)
が、米国ロスのデータベースA(データサーバA)にア
クセスし、情報を得るという状況を考える。このとき、
情報は、対象データベースAから米国ロスの中継ノード
A、東京の中継ノード1、大阪の中継ノード2を順に経
由してユーザ端末Aまで送信されてゆく。この状態を図
14では図示右の米国から中央の日本へ向かう矢印で示
している。
【0008】ここで既に別の大阪のユーザB(ユーザ端
末B)が、英国ロンドンのデータベースB(データサー
バB)に同様にアクセスしていて、東京の中継ノード1
から大阪の中継ノード2に向けて経路が使われていると
する。この状態は図14の図示左の欧州から中央の日本
へ向かう矢印で示している。
【0009】当然、米国ロスからのデータが東京の中継
ノード1まで送られて、ユーザ端末A宛に大阪の中継ノ
ード2に向けての経路へ送信しようとしたときは、輻輳
が発生し、後着の米国ロスからのデータが東京の中継ノ
ード1で廃棄される。折角、ユーザ端末Aが各ノードを
経由し米国ロスのデータベースAにアクセスし、東京ま
で送信されたデータが無駄になってしまう。
【0010】さらに、ユーザ端末Aは着信が想定される
待機時間を越えタイムアウトになってはじめて、どこか
の中継ノード(中継ノードA,1,2のどこか)で、デ
ータが廃棄されたことを知る。そして再び米国ロスのデ
ータベースAに向けデータの再送要求をかけ、データを
再送させるのである。
【0011】このような中継ノードでのデータ廃棄によ
り生じる無駄な再送要求や再送を未然に防ぐためには各
中継ノード(今回のケースでは中継ノード1)にデータ
を一旦蓄積するバッファを設けることが考えられる。し
かし、一般にデータベースをアクセスすることで転送さ
れる情報量は非常に大きく予測することも難しいため、
中継ノードに設置しなければならないバッファ量は決し
て現実的なサイズでは済まなくなる。
【0012】なお、上記の“米国ロスからのデータが東
京の中継ノード1で廃棄される”とのデータ廃棄のやり
方や“ユーザ端末Aは・・・データベースAに・・・再
送要求をかけ、データを再送させる”の再送の仕方につ
いて、ここで少し触れる。
【0013】まず、東京の中継ノード1で廃棄は、例え
ば、一般的なATM通信網を利用したコンピュータ間通
信の場合であると、ATMセル単位での廃棄である。つ
まり、通信プロトコルでは低レイヤの処理で通信データ
が廃棄されている。
【0014】一方、ユーザ端末AがデータベースAにデ
ータを再送させる時の要求・再送に関しては、コンピュ
ータ間通信で用いられるパケット単位でデータを要求し
再送がなされる。従って、要求・再送は通信プロトコル
での高レイヤ処理である。
【0015】このように、データの廃棄とこの廃棄に伴
うデータの再送とは異なる通信プロトコル(低レイヤで
の廃棄処理と高レイヤでの再送処理)により行われる
が、高レイヤ処理での処理単位であるパケットは通常複
数のセルで構成される(通常パケットは4KB、セルは
3B)ため、再送処理は廃棄されたセル以外のデータの
再送も要求することになる。このような通信処理の下
で、輻輳を考慮したより効率的な通信を目指すには、デ
ータを極力廃棄しないような仕組みが必要である。 (従来例2:トークンリングの通信形態)情報処理学会
編“情報処理ハンドブック”オーム社、ISBN4-274-0750
2-8 、平成5年11月20日印刷、p792-802にローカル
エリアネットワーク(LAN)の1つの形態としてのト
ークンリングが示されている。
【0016】図15に従来例として示したトークンリン
グの場合を示す。送信端末より送信されたデータは、一
方向(この図15では時計方向)に順次伝送され、一巡
後送信元で消去される。媒体結合ユニットは、能動素子
(電源供給を必要とする)で構成され、数ビットの遅れ
でデータを再生中継をするだけでなく、ビットを書き換
えることも行う。1方向にデータが伝送され一巡するた
め、障害箇所の特定が容易である反面、1箇所の障害が
通信全体の中断につながるため、高い信頼性が要求され
る場合には、リングを2重化するなどの対策が必要であ
る。
【0017】図16を参照してトークンリングのアクセ
ス制御について説明する。
【0018】まず、トークンリングのアクセス制御はス
テーションが順次結ばれてリングを構成していることを
前提にしており、物理形状がリングである必要はなく、
論理リングを形成すれば適用できる。トークンアクセス
(token access)を使用したリング形状のLANをトー
クンリング(token ring)と称す。
【0019】次にトークンリングのアクセス制御の原理
について説明する。図16(a)(b)(c)に示すよ
うにトークン(token)という特定の信号を物理的あるい
は論理的なリングに巡回させ、伝送媒体へのアクセス権
を授受していく。送信要求が発生したステーションは、
巡回してきたトークンを捕獲し、リングへのアクセス権
を得て、データフレームを送出する。データフレーム送
信完了後にトークンを送出して、下流のステーションに
アクセス権を渡す。
【0020】トークンが消滅してしまうと、何れの端末
も送信できなくなってしまうので、トークンの消滅監視
と再生とを行う監視ステーションが必要である。監視ス
テーションは、トークンが一定時間以上巡回しなくなっ
たことを検出すると、伝送媒体上の残存フレームを消去
し、新たにトークンを発生する。信頼性を高めるため
に、監視ステーションの機能をいずれのステーションも
有しうるようにできるが、一時点を取ると監視ステーシ
ョンは一つでなければならない。
【0021】物理形状がリングで信号が一方向に順次伝
播されるトークンリングについて説明する。各ステーシ
ョンは、リピータ(repeater)と称す再生中継機能をも
つ。リピータは、上流から送られてきたビット列を、F
IFO(first in first out)レジスタに入れ、数ビッ
トの遅れで再生し、下流ステーションに送出すると同時
に、フレームに付けられたアドレスを認識し、自ステー
ション宛のフレームを複写して、メモリに取り込む。
【0022】リピータまたは、FIFOに入れられてい
る間に、ビットを書き換える機能を有する。この機能に
より、トークンをデータフレームの先頭を指すコ−ドに
変更し、続けてデータを送信する。送出したデータフレ
ームが一巡して戻ってくると、消去する。さらに宛先ア
ドレスで示されるステーションが、アドレスを認識し、
フレームを複写したかを示すフレームの終わりに付けら
れたビットを更新することもできる。この機能は、フレ
ームが一巡するというリングの特性を活用し、フロー制
御、隣接上流のステーションの認識、重複アドレスの検
出などに利用できる。
【0023】
【発明が解決しようとする課題】従来例(基本)では、
輻輳や多量のメモリ使用、データベース容量の超過とい
った受信ノードの状態により送られたデータパケットが
廃棄される。そして、廃棄されたデータパケットを再送
する必要がある。この再送のためには、送信側と受信側
とには再送要求・再送の手順(通信プロトコル)を実装
する必要がある。このプロトコルは、送信されたデータ
パケットの内で受信されていないデータパケットがどれ
であるかの特定など、比較的複雑な処理が必要となる。
このため、現在は、廃棄されたパケットを再送すること
に関して、中継ノードでは何も処理されない代わりに、
送信端末と受信端末とで、当該必要な手順が実装され
る。従って、送信端末と受信端末との間で再送要求・再
送が行われると処理に時間がかかるので、高速・効率的
なデータ転送が困難になる。
【0024】従来例1で説明した従来の通信方法では、
中継ノード1でのデータ廃棄により送信端末(データベ
ースA)と受信端末(ユーザ端末A)との間で無駄な再
送要求や再送が生じていた。
【0025】また、仮にそのようなデータ廃棄や再送を
未然に防ぐために、各中継ノード(従来例1では中継ノ
ード1)にデータを一旦蓄積する大きなバッファを設け
たとする。こうした場合も、データベース等をアクセス
し得る情報量が非常に大きく、中継ノード1に必要なバ
ッファのサイズは決して現実的なものでは済まなかっ
た。
【0026】また、従来例2で説明したトークンリング
を、仮に各中継ノード間(例えば図14に示す東京の中
継ノード1とロスの中継ノードA間や、東京の中継ノー
ド1と大阪の中継ノード2間)の通信に用いたとする。
こうしたとしても、トークンを確保しなければ伝送媒体
へのアクセス権は得られないので、複数の通信要求があ
る場合でも各要求は1つづつ通信が行われ、やはりリピ
ータ部分でフレームを保持するので、データベースアク
セスなどの大量の情報を保持することはできない。ま
た、このトークンリングはフレームがリングを一巡する
と消去することを原則としている。もし一巡以上に巡回
させるような通信をする場合にはトークンリングのアク
セス制御では対応できない。
【0027】
【課題を解決するための手段】第1の解決手段は、自ノ
ードに到着した通信路上のデータパケットを再度通信路
に送り出し、このことにより、通信路をデータパケット
を記憶するバッファとして機能させる。
【0028】第2の解決手段は、第1の解決手段で通信
路に再度送り出された自ノード宛のデータパケットを、
通信路から自ノードが取り出すようにする。
【0029】第3の解決手段は、第1の解決手段と第2
の解決手段とでノード間をリング状に構成した通信路に
データパケットを巡回させるようにする。
【0030】第4の解決手段は、第1の解決手段で、送
信ノードと受信ノードとが1対のみの通信路があり、受
信ノードの状態に応じて通信路を介して送信ノードに送
り返すようにする。
【0031】第5の解決手段は、第4の解決手段で、受
信側でデータパケットの一部取り込み、残る取り除かれ
なかったデータパケットを通信路を介して送信ノードに
送り返すようにする。
【0032】第6の解決手段は、第4の解決手段または
第5の解決手段で、送信側に送り返されたデータパケッ
トを受信側に再送信するようにする。
【0033】第7の解決手段は、第3の解決手段と第4
の解決手段とを組み合わせたもので、送受信ノードが2
つの通信路で繋がっていて、一方の通信路から送られた
データパケットを他方の通信路で送り返すようにして、
2つの通信路をリング状に使う双方向通信となっている
ようにする。
【0034】第8の解決手段は、第3の解決手段と第5
の解決手段とを組み合わせたもので、第7の解決手段と
は、一部データパケットを受信ノードは取り込み残るデ
ータパケットを送り返すようにした点が異なっている。
【0035】第9の解決手段は、輻輳が発生した中継ノ
ード1から送り側の中継ノードAへ一旦データを戻し、
その後、戻されたデータを輻輳が解消した中継ノード1
へ再度送り直すようにする。
【0036】第10の解決手段は、送り側とは別の中継
ノードCへ一旦データを転送させ、その後、転送された
データを輻輳が解消した中継ノード1へ送り返すように
する。
【0037】第11の解決手段は、送り側とは別の中継
ノードCへ一旦データを転送し、さらに前段の中継ノー
ドAへデータを戻し、そして、前段の中継ノードAから
再び輻輳が解消した中継ノード1へ送るようにする。
【0038】まず、前記の第1と第2との解決手段で
は、自ノードに到着した通信路上のデータパケットを再
度通信路に送り出し、そのデータパケットを、通信路か
ら自ノードが取り出すことによって、通信路をデータパ
ケットを記憶するバッファとして機能させる。
【0039】ここで、第3の解決手段に挙げたような2
つの通信路を使うと、送り出す通信路と送り返す通信路
とに機能を分担させることが可能となる。
【0040】また、第4〜第8の解決手段では、送信ノ
ードと受信ノードとが通信路を介して直接通信する場
合、通信路が1対であったり、2つの通信路をリング状
に使ったりした場合を示している。この時に、受信ノー
ドで全部のパケットデータを送り返したり、一部データ
パケットを送り返したりしたときに、送り返しに使う通
信路と送信ノードで再度送るときに使う通信路とを合わ
せてデータパケットを記憶するバッファとして機能させ
る。これらの解決手段では、送信ノードと受信ノードと
が一対一に通信路で接続された形態となっているが、送
信ノードと受信ノードとを中継ノードと考えれば、これ
らの形態はネットワークの中継部分で発生する問題を解
決する手段となっている。
【0041】さらに、前記の第9〜第11の解決手段で
は、いずれも輻輳が発生した中継ノードから一旦別の中
継ノード(A,C,CとA)にデータを送り、その後輻
輳が解消した中継ノード1へデータが送り戻される。こ
のデータが送り戻される間にはデータの伝送の遅延が生
じる。一般にマルチメディア通信では、画像等の大量の
データが一時的な輻輳を発生させ、この輻輳は時間をず
らすことによって解決されることが多いのでこの遅延の
間に輻輳が起きていた中継ノード1では、輻輳の原因の
データの送信が処理され、輻輳が解消された状態にな
る。そこで、(一旦別の中継ノードA,C,CとAに送
られた)送信データが、輻輳が解消された中継ノード1
に戻ってくることになる。
【0042】
【発明の実施の形態】〔実施例1〕(送信と受信1対の
みで折り返し) 請求項1と請求項2、そして請求項4に関連した実施例
を以下で説明する。
【0043】図1に本発明の請求項4に記載のデータ通
信システムを示す。図中の符号1は送信ノード、2は受
信ノード、3は通信路、4はデータパケットを表してい
る。
【0044】送信ノード1から送り出されたデータパケ
ット4は通信路3を介し、受信ノード2に到達する。受
信ノード2では輻輳などの受信ノードの状態により、デ
ータパケット4を受け付けられない状態にある。この場
合に到達したデータパケット4を通信路3に送り返す。
こうすることで、通信路3にデータパケット4を一旦保
持してもらうようにできる。この通信路3のデータパケ
ット4の保持できる容量は通信路の通信容量と通信路の
長さにより決まる。
【0045】今日、光ファイバのような通信路では数十
Gbit/s といった極めて大きな通信容量であり、その長
さも、大陸間横断の海底ケーブルでは数千〜1万km、日
本国内の陸上でも数百kmであり、通信路のデータパケッ
トの保持できる容量は100M〜1Gbit にも達する。
従ってノード内に巨大なバッファを持つことなく、通信
路をバッファとして機能させて、データパケットを廃棄
させない現実的な通信方式となる。 〔実施例2〕(受信側で一部取り込む) 図2に本発明の請求項5に記載のデータ通信システムを
示す。この通信方式は実施例1と異なるところは、受信
ノードに到着したデータパケットの一部を受信ノードで
受け付ける点である。輻輳などの受信ノードの状態は必
ずしもパケットデータの全てを送り返すまでではないこ
とがある。従って、データパケットが到着した時点で受
信ノードが受付処理できる分は取り込み、残る処理しき
れないデータパケットを送り返すようにしている。 〔実施例3〕(送信側での再送信) 図3に本発明の請求項6に記載のデータ通信システムを
示す。実施例1で送り返されたデータパケットは送信ノ
ードへ到達する。この時に送信ノードでは受信ノードで
送り返されたデータパケットを判定して、このデータパ
ケットを受信ノードへ再び送り返すのである。こうする
ことによって、最初に受信ノードにパケットデータが到
達した時点では、輻輳などの受信ノードの状態で受け付
けられなかったが、その輻輳などの状態が解消し、再び
送り返されたパケットデータが到達した時には、受信ノ
ードで受け付けられるようになる(なっていることを期
待している)。 〔実施例4〕(受信側で一部取り込みかつ送信側で再送
信) また図4に本発明の請求項6に記載のデータ通信システ
ムの別の実施例を示す。実施例2で送り返されたデータ
パケットは送信ノードへ到達する。この時に送信ノード
では受信ノードで送り返されたデータパケットを判定し
て、このデータパケットを受信ノードへ再び送り返す。
こうすることは実施例3と同じようではあるが、最初に
受信ノードにパケットデータが到達した時点で一部デー
タパケットが処理されているので、残るパケットデータ
が再び送り返され受信ノードに到達した時には、受信ノ
ードで受け付け処理するパケットデータは少なくて済
む。従って、実施例3に比べ、より効率的なデータ通信
システムである。 〔実施例5〕(請求項4で双方向通信) 請求項3と請求項7とに関連した実施例を以下で説明す
る。
【0046】図5に本発明の請求項7に記載のデータ通
信システムを示す。第1の送受信ノードと第2の送受信
ノードとの間には2つの通信路がある。このようなネッ
トワーク構造では、パケットデータを一方の通信路を使
って送り、他方の通信路を使って送り返すようにする。
このようにすると、パケットデータはリング状の通信路
を周回してきたようになる。
【0047】このように、他ノードへパケットデータを
送る時の通信路と受信したパケットデータを送り返すと
きの通信路とを別に設けることにより、送り返す際の通
信容量(通信帯域)が常に確保される。常に送り返す通
信容量を確保できることは、送り返しの通信容量確保と
いう新たな通信プロトコルを用意したり実行させなくて
もよくなり、本発明を安定的に実施することができるよ
うになる。 〔実施例6〕(請求項5で双方向通信) 図6に本発明の請求項8に記載のデータ通信システムを
示す。実施例5で示した同じネットワーク構造に対し
て、この実施例では一部のデータパケットを取り込み、
残るデータパケットを他の通信路を使い送り返すように
している。
【0048】この実施例6は、リング状の通信路にした
だけの実施例5に比べより効率的なデータ通信システム
であり、また、受信側で一部取り込みかつ送信側で再送
信する実施例4にくらべ安定的に実施することができる
データ通信システムである。 〔実施例7〕(送り側の中継ノードAへ一旦データを戻
す) 図7に本発明の請求項9に記載の実施例を示す。
【0049】ロンドンのデータベースB(データサーバ
B)から送られてくる情報データがロンドンの中継ノー
ドB、東京の中継ノード1、大阪の中継ノード2を経由
してユーザ端末Bに送信されている。この時に、ロスの
データベースA(データサーバA)からの情報データを
ロスの中継ノードA、東京の中継ノード1、大阪の中継
ノード2を経由してユーザ端末Aに送ろうとした場合を
想定する。
【0050】この場合、東京の中継ノード1では大阪の
中継ノード2に向けての回線が、ロンドンからユーザ端
末Bへの情報データにより使用されており、他の情報が
利用できない状況にある。この時、ロスからユーザ端末
Aへ情報データを送ろうとすれば、当然東京の中継ノー
ド1では大阪の中継ノード2へ向けての通信路は輻輳が
生じ、後から送られてくるロスからユーザ端末Aへ情報
データを廃棄したり、バッファに蓄積し待たせたりする
といった必要が生まれる。
【0051】そこで、請求項9に記載した本発明では、
米国ロスから送られてくるデータが東京の中継ノード1
で、一旦、ロスの中継ノードAに送り返される。そして
ロスの中継ノードAではそのデータを再び東京の中継ノ
ード1へ送るようにする。
【0052】こうすると、情報データは東京の中継ノー
ド1からロスの中継ノードA、そしてロスの中継ノード
Aから東京の中継ノード1と送られる間に伝送遅延がか
かることになる。この遅延の間にロンドンからユーザ端
末Bに送られる情報データが東京の中継ノード1から大
阪の中継ノード2に向け全て送り終わっていれば、輻輳
が解消される。つまりロスからの情報データは東京−ロ
ス間を往復させて伝送遅延を与え、東京−大阪間の輻輳
が解消されるの(ロンドン−ユーザ端末B間の通信の完
了)を待ち、その輻輳解消後に目的の宛先(ユーザ端末
A)へ送るのである。
【0053】このような、東京−ロス間の往復遅延は東
京の中継ノード1で極めて大きなバッファを持って、情
報データを蓄積し一旦待たせるのと同じ様な効果を生
む。
【0054】ここで東京−ロス間の往復遅延に相当する
バッファの大きさを考えてみる。東京−ロス間の往復距
離は1万5千kmである。また現在使われている海底光フ
ァイバの伝送容量は40Gbit/sec である。従って、東
京−ロス間で光ファイバの往復遅延に相当するような、
東京の中継ノード1が持つバッファのサイズは 40Gbit/s ×(1.5 万km/30万km/s)=2Gbit であることから、2Gbit に相当する。このような大き
なバッファを持つことは中継ノード1の装置を極めて大
きなものとするため実現性に乏しい。しかしながら本発
明のように通信経路の途中で情報データを往復させるこ
とで、輻輳を避け、しかも再送処理も行わなくて済むこ
とになる。 〔実施例8〕(送り側とは別の中継ノードCへ一旦デー
タを転送させる) 図8に本発明の請求項10に記載の実施例を示す。図8
において仮定した状況は実施例7の場合と同じである。
東京の中継ノード1で大阪の中継ノード2向けのロンド
ンからユーザ端末Bへと、ロスからユーザ端末Aへの情
報データとが東京−大阪の中継ノード1,2間で輻輳が
生じる。
【0055】そこで、請求項10に記載した本発明で
は、その輻輳のときに、米国ロスから送られてくるデー
タが東京の中継ノード1で、一旦、例えば豪州のシドニ
ーの中継ノードCに転送される。そして豪州のシドニー
の中継ノードCではそのデータを再び東京の中継ノード
1へ送るようにする。
【0056】このような、東京−シドニー間の往復遅延
は、実施例1での東京−ロス間の往復遅延と同様、東京
の中継ノードで極めて大きなバッファを持って、情報デ
ータを蓄積し一旦待たせるのと同じ様な効果を生む。
【0057】ここで東京−シドニー間の往復遅延に相当
するバッファの大きさを考えてみる。東京−シドニー間
の往復距離は1万kmである。従って、東京−シドニー間
で光ファイバの往復遅延に相当するような、東京の中継
ノード1が持つバッファのサイズは 40Gbit/s ×(1万km/30万km/s)=1.3 Gbit であることから、1.3 Gbit に相当する。
【0058】また、豪州シドニーの代わりに、例えば東
北の仙台に設置された中継ノードC′を用いる場合を考
えることもできる。現在使われている日本の基幹網の光
ファイバの伝送容量は40Mbit/sec である。従って、
東京−仙台間で光ファイバの往復遅延に相当するよう
な、東京の中継ノード1が持つバッファのサイズは 40Mbit/s ×(700 km/30万km/s)=93kbit であることから、93kbitに相当する。さらに、将来に
向けて1Tbit/s というような伝送量を持つ光ファイバ
の通信方式も検討されている。この通信方式が実現され
た場合に、本発明の東京−仙台間に対応するバッファの
サイズは2.3 Mbit に相当する。このような大きく高速
アクセス可能なバッファを持たせることは中継ノードの
装置を大きなものとするため実現性に乏しい。しかしな
がら本発明のように通信経路の途中で情報データを往復
させることで、輻輳を避け、しかも再送処理も行わなく
て済ませることができる。このように豪州シドニーや仙
台といった中継ノードの中から使用率の低い通信経路や
バッファサイズが小さい通信路を選択することで他通信
への影響を小さくし、往復により発生する遅延時間を小
さくすることも可能(この例では米国ロスや豪州シドニ
ーに比べ仙台の遅延時間は小さい)となる。 〔実施例9〕(送り側とは別の中継ノードCへ一旦デー
タを転送し、さらに中継ノードCから輻輳が起きている
中継ノード1の前段の中継ノードAへデータを戻す) 図9に本発明の請求項11に記載の実施例を示す。図9
において仮定した状況は上記実施例7や実施例8の場合
と同じである。ロンドンからのユーザ端末Bへとロスか
らのユーザ端末Aへとの情報データが、東京−大阪の中
継ノード1,2間で同じ経路となるので、東京の中継ノ
ード1で大阪の中継ノード2向けの輻輳が生じる。
【0059】そこで、先に実施例8で説明した請求項1
0に記載した発明では、図8に示したようにその輻輳の
ときに、米国ロスから送られてくるデータが東京の中継
ノード1で、一旦、豪州のシドニーの中継ノードCに転
送した。
【0060】ここで、請求項11に記載した本発明で
は、図9に示すように、さらに豪州のシドニーの中継ノ
ードCではそのデータを米国のロスの中継ノードAへ送
り返すようにする。そして米国のロスの中継ノードAか
ら再び東京の中継ノード1へ送るようにする。
【0061】このような、東京−シドニー(中継ノード
1,C)間、シドニー−ロス(中継ノードC,A)間と
ロス−東京(中継ノードA,1)間を周回する遅延は、
実施例7での東京−ロス(中継ノード1,A)間の片道
の遅延と、実施例8での東京−シドニー(中継ノード
1,C)間の片道の遅延に、さらにシドニー−ロス(中
継ノードC,A)間の片道の遅延を加算することにな
り、東京の中継ノード1でさらに大きなバッファを持っ
て、情報データを蓄積し一旦待たせるのと同じ様な効果
を生む。
【0062】ここで東京−シドニー−ロス−東京(中継
ノード1,C,A,1)間の周回遅延に相当するバッフ
ァの大きさを考えてみる。ロス−東京(中継ノードA,
1)間、東京−シドニー(中継ノード1,C)間の片道
遅延は実施例7,実施例8からそれぞれ7,500km ,5,00
0km であった。残るシドニー−ロス間の距離は7,500km
である。従って、シドニー−ロス(中継ノードC,A)
間で光ファイバの片道遅延に相当するような、中継ノー
ドが持つバッファのサイズは1Gbit に相当する。従っ
て、この周回させる方法で東京の中継ノードが持つバッ
ファのサイズは2.6 Gbit にも達する。
【0063】ここまで実施例7、実施例8と実施例9と
で、通信の送信側の中継ノードに一旦データを戻した
り、転送や周回させることで、仮装的に非常に大きなデ
ータのバッファを中継ノードが持つことを説明した。こ
の通信の送信側の中継ノードに一旦データを戻したり、
転送や周回させるために必要な送信路やその通信帯域を
どうするかに関して少し述べる。
【0064】例えば、中継ノード間でデータを戻した
り、転送や周回させるような事態に、帯域制限や運用・
予備系の利用、中継ノードの送信側容量の確保などを挙
げることができる。
【0065】第1の案として、中継ノード間で通常に運
用されている通信帯域を最大値からある割合以下に制限
することが考えられる。
【0066】特に最大帯域の50%以下という値で制限
するような形で中継ノード間の通信を運用している状況
を前提として考える。この前提に立てば、ある中継ノー
ドから接続している他のどの中継ノードに対しても、必
ず一旦データを戻したり、転送や周回させるために必要
な送信路やその通信帯域は空いていて、利用できること
になる。
【0067】また第2の案として、通信装置の送受信モ
ジュールの故障や伝送路の断線に備えて用意されている
運用・予備系と呼ぶ二重系を利用することも検討でき
る。本発明の適用対象に考えている中継ノード装置やそ
の中継ノードの伝送路には運用・予備系の設備が通常設
けられている。このような運用・予備系の設備は例え
ば、支障移転や無瞬断切り替えといった通信品質を保つ
ために従来からあるもので、決して特別なものではな
い。従って、送信側の中継ノードに一旦データを戻した
り、転送や周回させるために必要な送信路やその通信帯
域として予備系を当てることができる。
【0068】第3の案として、中継ノードの送信側にデ
ータを送出するための容量を確保しておくことでも良
い。先の各実施例で説明したような送信側の中継ノー
ドに一旦データを戻したり、転送や周回させること
のどれか1つでも選択できる条件を考えてみる。この選
択を1つでも可能とするために必要な送信路やその通信
帯域の条件は、ある中継ノードの送信側にデータを送出
できる。
【0069】幾つかのケースで考えてみると、ある中継
ノードでの送信側のデータ送出先が、通信されている送
信側の中継ノードであれば、データを一旦戻すことに
なる。また、通信されている送信側以外の他の中継ノー
ドであればデータの転送や周回させることになる。
さらに転送と周回の違いは送信側以外の他の中継ノード
での送信側の空きのある送出方向による。つまり、送信
側以外の他の中継ノードでの送信側の空きが元の中継ノ
ード側に送信できればデータの転送になる。逆に、そ
の中継ノードでの空きが元の中継ノード側でなく、また
別の中継ノード側に送信できれば、データはいずれ周
回することになる。
【0070】上述の実施例1ないし実施例9を説明し
て、通信路にパケットを折り返させることを記述した。
これらに関連して、(i)折り返しが行われた回数をチ
ェックしたり、(ii)折り返しに当たって、宛先のアド
レスを入れ替えたり、(iii)あるいは、宛先のアドレス
を入れ替えることなく、現に受信したパケットをどのよ
うに振り分けるべきかを容易に判断できるようにした
り、することが望まれる。以下の実施例10ないし実施
例12は、それらを実現する構成を示している。 〔実施例10〕図10(a)に本発明の請求項12に記
載のデータ通信方法の実施例における1個のパケットの
フレーム構造を示し、折り返し回数部a1−1、送信ア
ドレス部a1−2、受信アドレス部a1−3、情報部a
1−4をもっている。なお、a1−1ないしa1−3は
ヘッダ部を構成している。また図10(b)に本実施例
のシステム全体図を示す。図10(b)に示すように送
信ノードから送出されたパケットは折り返し回数部a1
−1のビットがすべて0となっている。本図では折り返
し回数部a1−1が2ビットの例を示している。一方通
信路を介してパケットを受け取る受信ノードで、何らか
の理由でパケットを受け取れない場合は、受信ノードの
内部で折り返し回数部a1−1に1を加算し、通信路を
経由し送信ノード側にパケットを送り返す。送信ノード
では、受信ノードから到着したパケットの折り返し回数
部a1−1を見て、その値が0でないことからこのパケ
ットが受信ノードで受け取られなかったパケットである
ことを判断し、折り返し回数部a1−1に更に1を加算
し、再び通信路を経由し受信ノード側にパケットを送り
返す。
【0071】このような処理を繰り返してゆくうちに、
受信ノードから折り返されるパケットの折り返し回数部
a1−1のビットは全て1になる。このようなパケット
を送信ノードが受信したら、このパケットについては受
信ノードが受け取れなかったものと判断し、そのパケッ
トは廃棄され、時間をおいて後に再送などの手段をとる
ことになる。以上示した送信ノードと受信ノード間での
パケットの動きと、折り返し回数部a1−1のビットの
変化とを図10(c)に示す。
【0072】なお図10に示す通信方法においては、図
11を参照して後述する方法の場合のように送信アドレ
ス部a1−2の内容と受信アドレス部a1−3の内容と
を入れ替えるようにしてもよく、また図12を参照して
後述する方法の場合のように入れ替えなくてもよい。図
10の場合には、要するに、折り返し回数を計算する方
法を提供しているものである。 〔実施例11〕図11に本発明の請求項13に記載のデ
ータ通信方法の実施例を示す。1つのパケットのフレー
ム構成は図10(a)に対応するものとなっている。本
実施例においては、通常の送信ノードから受信ノードへ
のパケットと、受信ノードから送信ノードへの折り返し
パケットとを区別するために、受信ノードにおいてパケ
ットの受信ができずに折り返す際に、送信アドレス部a
1−2に格納されたデータ(送信端末のアドレス)と、
受信アドレス部a1−3に格納されたデータ(受信端末
のアドレス)とを入れ替える。この入れ替えは受信ノー
ドに配置されたメモリ等により行うことができる。
【0073】このデータの入れ替えにより、パケットの
中継を行う通信網中の各装置においては、折り返しパケ
ットであるかどうかを認識する必要なしに、正しく送信
ノードに向けてパケットを送達することが可能となる。
折り返しパケットが送信ノードに到着したら、再び送信
アドレス部a1−2に格納されたデータと受信アドレス
部a1−3に格納されたデータを入れ替えて、受信ノー
ドに向けてパケットを送出する。本実施例においては、
通信網中の各装置(送信ノードと受信ノード間の中継装
置)で、通常のパケットと折り返しパケットとを区別す
る必要がなく、中継ノードの付加ハード量が少なくてす
むという利点がある。 〔実施例12〕図12(a)に本発明の請求項14に記
載のデータ通信方法の実施例のシステム全体図を示し、
また図12(b)に本実施例における中継ノードにおけ
る処理のフローチャートを示す。
【0074】本実施例においては、送信ノードおよび受
信ノードにおけるパケットの折り返しに際しては、折り
返し回数部a1−1のビットの加算以外にはパケットの
内容を変化させない。一方パケットの中継を行う通信網
中の各中継ノードにおいては、折り返し回数部a1−1
の最下位のビットを検出し(ステップS1)、その値が
0であれば、そのパケットは送信ノードから受信ノード
へのパケットであると判断し、受信アドレス部a1−3
に格納されたデータに従ってパケットの振り分け等の処
理を行う(ステップS2)。
【0075】一方折り返し回数部a1−1の最下位ビッ
トの値が1であれば、そのパケットは受信ノードから送
信ノードへの折り返しパケットであると判断し、この場
合は送信アドレス部a1−2に格納されてデータに従っ
てパケットの振り分けを行う(ステップS3)。
【0076】本実施例においては、データ折り返しの際
の送信ノードおよび受信ノードにおけるアドレスの入れ
換えが不要となるため端末側(すなわち送信ノードおよ
び受信ノード)における処理量が実施例11に比べて少
ない。このため端末側の負担を軽減できるという利点が
ある。
【0077】以上のように、全ての実施例において必要
となる中継ノード間の送信路やその通信帯域の取り方は
幾つか有り、その取り方とデータを戻したり、転送や周
回させたりする仕方との組み合わせを考慮することがで
きる。
【0078】
【発明の効果】以上説明した如く、本発明によれば、従
来のデータ通信システムで各ノードにバッファを持って
いたり、送られるパケットデータが多量であるときはバ
ッファに保持できず廃棄してしまい、送信元から廃棄デ
ータと同じパケットデータを再度送信させる必要が生じ
ていた点を解消できる。即ち、本発明では受け付けでき
ないデータパケットを送り返すなどをして通信路に戻
す。通信路は現在使われている光ファイバでも充分な通
信帯域を持ち、巨大なバッファで保持させたようにでき
る。送り返されたパケットデータは再び輻輳などが解消
した受信可能となったノードに再び送り返される。こう
すれば、パケットは廃棄されず、再送の必要がなくな
る。しかも、膨大な容量のバッファを新たに各ノードに
設ける必要もない。またこのような通信路にデータパケ
ットを送り返す際にも、送りと別の通信路を使い帯域確
保の不安性を解消したり、受け付けられる一部のパケッ
トデータは取り込み、残るパケットデータのみ送り返す
ことで効率性をより高めたりすることができる。
【図面の簡単な説明】
【図1】本発明の請求項4に記載のデータ通信システム
(送信と受信1対のみで折り返し)を示す。
【図2】本発明の請求項5に記載のデータ通信システム
(受信側で一部取り込む)を示す。
【図3】本発明の請求項6に記載のデータ通信システム
(送信側での再送信)を示す。
【図4】本発明の請求項6に記載のデータ通信システム
(受信側で一部取り込みかつ送信側で再送信)を示す。
【図5】本発明の請求項7に記載のデータ通信システム
(請求項4で双方向通信)を示す。
【図6】本発明の請求項8に記載のデータ通信システム
(請求項5で双方向通信)を示す。
【図7】本発明の請求項9に記載した実施例(一旦、前
段の中継ノードに戻す)を示す。
【図8】本発明の請求項10に記載した実施例(一旦、
他の中継ノードに転送する)を示す。
【図9】本発明の請求項11に記載した実施例(一旦、
他のノードに転送、前段ノードに戻す)を示す。
【図10】本発明の請求項12に記載した実施例を示
す。
【図11】本発明の請求項13に記載した実施例を示
す。
【図12】本発明の請求項14に記載した実施例を示
す。
【図13】従来例(基本)を示す。
【図14】通信方法の従来例を示す。
【図15】通信方法の従来例2におけるトークンリング
を示す。
【図16】従来例2におけるトークンリングのアクセス
制御を示す。
【符号の説明】
1:送信ノード 2:受信ノード 3:通信路 4:データパケット

Claims (14)

    【特許請求の範囲】
  1. 【請求項1】 複数のノードと、その各ノード間を接続
    する通信路とを持ち、前記ノード間を前記通信路を介し
    てデータパケットを送受信するデータ通信システムにお
    いて、 前記通信路上には、複数の前記データパケットが同時に
    存在可能であり、 前記各ノードには、自ノードに到着した前記通信路上の
    前記データパケットを再度前記通信路に送り出す手段を
    有し、 前記各ノードが、前記自ノードに到着した前記通信路上
    の前記データパケットを再度前記通信路に送り出すこと
    により、前記通信路を前記データパケットを記憶するバ
    ッファとして機能させることを特徴とするデータ通信シ
    ステム。
  2. 【請求項2】 複数のノードおよび各ノード間を接続す
    る通信路間でデータパケットを送受信するデータ通信方
    法において、 前記通信路上には、複数の前記データパケットが同時に
    存在し、 前記各ノードには、前記通信路上から前記データパケッ
    トを取り出し、 前記各ノードには当該データパケットを前記通信路へ再
    度送り出すようにし、 前記各ノードが、前記自ノードの状態に応じて、前記通
    信路上から前記自ノード宛に送り出されたデータパケッ
    トを取り出すことを特徴とするデータ通信方法。
  3. 【請求項3】 前記請求項1に記載されたデータ通信シ
    ステムであって、 前記各ノードが、前記自ノードに到着した前記通信路上
    の前記データパケットを再度前記通信路に送り出し、リ
    ング状に構成した前記通信路上を巡回させることによ
    り、前記通信路を前記データパケットを記憶するバッフ
    ァとして機能させることを特徴とするデータ通信システ
    ム。
  4. 【請求項4】 送信ノード、受信ノード、および送信ノ
    ードと受信ノードとの間で相互にデータの送受信を行う
    手段である通信路を有するデータ通信システムにおい
    て、 受信ノードは上記通信路を介して受信したデータを当該
    受信ノードの状態に応じて上記通信路を介して送信ノー
    ドに送り返すことを特徴とする請求項1に記載したデー
    タ通信システム。
  5. 【請求項5】 送信ノード、受信ノード、および送信ノ
    ードと受信ノード間で相互にデータの送受信を行う手段
    である通信路を有するデータ通信システムにおいて、 受信ノードは、その状態に応じて上記通信路を介して受
    信ノードに到着したデータを通信路から取り除き、 受信ノードに到着したデータのうち上記操作により通信
    路から取り除かれなかったデータを上記通信路を介して
    送信ノードに送り返すように構成されることを特徴とす
    る請求項1に記載したデータ通信システム。
  6. 【請求項6】 前記請求項4または請求項5のデータ通
    信システムにおいて、 前記受信ノードから前記通信路を介して前記送信ノード
    に送り返されたデータを、 送信ノードにおいて上記通信路を介してふたたび受信ノ
    ードに送り返すことを特徴とするデータ通信システム。
  7. 【請求項7】 第1の送受信ノード、第2の送受信ノー
    ド、および前記第1の送受信ノードと第2の送受信ノー
    ド間で相互にデータの送受信を行う手段である少なくと
    も2本の通信路を有するデータ通信システムにおいて、 第2の送受信ノードもしくは第1の送受信ノードは、上
    記複数の通信路のうちのそれぞれ一方を介して受信した
    データを、当該送受信ノードのそれぞれの状態に応じて
    上記複数の通信路のうちのそれぞれもう一方を介して他
    方の送受信ノードにそれぞれ送り返すことを特徴とする
    請求項3または請求項4に記載したデータ通信システ
    ム。
  8. 【請求項8】 第1の送受信ノード、第2の送受信ノー
    ド、および前記第1の送受信ノードと第2の送受信ノー
    ド間で相互にデータの送受信を行う手段である少なくと
    も2本の通信路を有するデータ通信システムにおいて、 第2の送受信ノードもしくは第1の送受信ノードは、そ
    の状態に応じて上記複数の通信路のうちのそれぞれ一方
    を介して第1の送受信ノードもしくは第2の送受信ノー
    ドから受信したデータをそれぞれ通信路から取り除き、 当該送受信ノードに到着したデータのうち上記操作によ
    りそれぞれの通信路から取り除かれなかったデータを、
    上記複数の通信路のうちのそれぞれもう一方を介しても
    う一方の送受信ノードにそれぞれ送り返すことを特徴と
    する請求項3または請求項5に記載したデータ通信シス
    テム。
  9. 【請求項9】 複数の中継ノードを介して情報データを
    送受信するデータベースおよびユーザ端末がそれぞれ複
    数あるデータ通信システムにおいて、 ある中継ノード1で、あるデータベースBとユーザ端末
    Bとの間の通信が行われていて、他のデータベースAと
    ユーザ端末Aとの間の通信も同じ中継ノード1を介して
    同じ中継ノード2へ向かう送信方向に送信する時に、 データベースBとユーザ端末Bとの間の通信により既に
    その中継ノード1の中継ノード2へ向かう同一送信方向
    は使われているために、データベースAとユーザ端末A
    間の通信が行われると輻輳となってしまう場合、 データベースAとユーザ端末Aとの間の通信で該当する
    中継ノード1の前に通信を中継した前段の中継ノードA
    に一旦情報データを戻すように送り、そして前段の中継
    ノードAから再び該当する中継ノード1に送り、その情
    報データが該当する中継ノード1に到着した時点で、デ
    ータベースBとユーザ端末B間の通信が終わっていれ
    ば、ユーザ端末A宛に次の中継ノード2へ向かい送信す
    るようにすることを特徴とする請求項1に記載したデー
    タ通信システム。
  10. 【請求項10】 複数の中継ノードを介して情報データ
    を送受信するデータベースおよびユーザ端末がそれぞれ
    複数あるデータ通信システムにおいて、 ある中継ノード1で、あるデータベースBとユーザ端末
    Bとの間の通信が行われていて、他のデータベースAと
    ユーザ端末Aとの間の通信も同じ中継ノード1を介して
    同じ中継ノード2へ向かう送信方向に送信する時に、 データベースBとユーザ端末Bとの間の通信により既に
    その中継ノード1の中継ノード2へ向かう同一送信方向
    は使われているために、データベースAとユーザ端末A
    間の通信が行われると輻輳となってしまう場合、 データベースBとユーザ端末Bとの間の通信やデータベ
    ースAとユーザ端末Aとの間の通信には用いられず、か
    つ輻輳となる該当する中継ノード1に繋がる他の中継ノ
    ードCに一旦情報データを転送して送り、そして転送さ
    れた中継ノードCから再び該当する中継ノード1に送
    り、その情報データが該当する中継ノード1に到着した
    時点で、データベースBとユーザ端末Bとの間の通信が
    終わっていれば、ユーザ端末A宛に次の中継ノード2へ
    向かい送信するようにすることを特徴とする請求項1に
    記載したデータ通信システム。
  11. 【請求項11】 複数の中継ノードを介して情報データ
    を送受信するデータベースおよびユーザ端末がそれぞれ
    複数あるデータ通信システムにおいて、 ある中継ノード1で、あるデータベースBとユーザ端末
    Bとの間の通信が行われていて、他のデータベースAと
    ユーザ端末Aとの間の通信も同じ中継ノード1を介して
    同じ中継ノード2へ向かう送信方向に送信する時に、 データベースBとユーザ端末Bとの間の通信により既に
    その中継ノード1の中継ノード2へ向かう同一送信方向
    は使われているために、データベースAとユーザ端末A
    間の通信が行われると輻輳となってしまう場合、 データベースBとユーザ端末Bとの間の通信やデータベ
    ースAとユーザ端末Aとの間の通信には用いられず、か
    つ輻輳となる該当する中継ノード1に繋がる他の中継ノ
    ードCに一旦情報データを転送して送り、 そして転送された中継ノードCから、通信やデータベー
    スAとユーザ端末Aとの間の通信の輻輳に該当する中継
    ノード1の前段の中継ノードAに送り返し、再び、前記
    前段の中継ノードAから該当する中継ノード1に再送信
    し、その情報データが該当する中継ノード1に到着した
    時点で、データベースBとユーザ端末B間の通信が終わ
    っていれば、ユーザ端末A宛に次の中継ノード2へ向か
    い送信するようにすることを特徴とする請求項1に記載
    したデータ通信システム。
  12. 【請求項12】 情報を固定ビット長あるいは可変ビッ
    ト長のパケットに加工して通信を行うデータ通信方法に
    おいて、 1個のパケットは、送信する情報からなる固定ビット長
    あるいは可変ビット長の情報部と、パケットの送受信に
    必要となるヘッダ部からなり、 前記ヘッダ部は複数の固定ビット長からなる折り返し回
    数部と、送信側のアドレスを格納する固定ビット長から
    なる送信アドレス部と、受信側のアドレスを格納する固
    定ビット長からなる受信アドレス部からなり、 前記折り返し回数部のビットは、最初に送信側から受信
    側に送信する際にはその内容を0とし、受信側で受信で
    きなかった場合に前記内容に1を加算し送信側に送り返
    し、送信側ではさらに1を加算し受信側に送り返し、上
    記の動作を受信側で受信できるまで、もしくは前記折り
    返し回数部の値が一定の値に達するまで繰り返し、 前記折り返し回数部の値が一定の値に達した場合には送
    信側において該パケットを廃棄することを特徴とするデ
    ータ通信方法。
  13. 【請求項13】 前記請求項12に記載のデータ通信方
    法において、受信側でパケットを受信できなかった場合
    に、前記パケットの受信アドレス部と送信アドレス部の
    値を入れ替えて送信側に折り返し、送信部においては受
    信側から受け取った前記パケットに対して受信アドレス
    部と送信アドレス部の値を入れ替えて受信側に折り返す
    ことを特徴とするデータ通信方法。
  14. 【請求項14】 前記請求項12に記載のデータ通信方
    法において、パケットの中継を行う中継ノードにおい
    て、折り返し回数部の値が奇数である場合、該パケット
    の受信アドレス部の値を送信アドレスとみなし、送信ア
    ドレス部の値を受信アドレスとみなすことにより中継処
    理を行うことを特徴とするデータ通信方法。
JP32208498A 1998-05-14 1998-11-12 データ通信システムおよび通信方法 Expired - Fee Related JP3352038B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP32208498A JP3352038B2 (ja) 1998-05-14 1998-11-12 データ通信システムおよび通信方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP13169698 1998-05-14
JP10-131696 1998-05-14
JP32208498A JP3352038B2 (ja) 1998-05-14 1998-11-12 データ通信システムおよび通信方法

Publications (2)

Publication Number Publication Date
JP2000036819A true JP2000036819A (ja) 2000-02-02
JP3352038B2 JP3352038B2 (ja) 2002-12-03

Family

ID=26466454

Family Applications (1)

Application Number Title Priority Date Filing Date
JP32208498A Expired - Fee Related JP3352038B2 (ja) 1998-05-14 1998-11-12 データ通信システムおよび通信方法

Country Status (1)

Country Link
JP (1) JP3352038B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006079169A (ja) * 2004-09-07 2006-03-23 Lac Co Ltd コンピュータシステム、データ転送装置、及びデータ転送方法
US8311043B2 (en) 2003-08-15 2012-11-13 Quintence Properties Kg, Llc Distribution of identifiers in serverless networks
CN114244773A (zh) * 2020-09-09 2022-03-25 英业达科技有限公司 封包处理系统及其封包处理方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8311043B2 (en) 2003-08-15 2012-11-13 Quintence Properties Kg, Llc Distribution of identifiers in serverless networks
JP2006079169A (ja) * 2004-09-07 2006-03-23 Lac Co Ltd コンピュータシステム、データ転送装置、及びデータ転送方法
JP4664026B2 (ja) * 2004-09-07 2011-04-06 株式会社ラック コンピュータシステム、データ転送装置、及びデータ転送方法
CN114244773A (zh) * 2020-09-09 2022-03-25 英业达科技有限公司 封包处理系统及其封包处理方法

Also Published As

Publication number Publication date
JP3352038B2 (ja) 2002-12-03

Similar Documents

Publication Publication Date Title
EP0146831B1 (en) Message stripping protocol for a ring communication network
EP0454364B1 (en) High speed transport protocol with two windows
JP4408496B2 (ja) 複数のサブネットワーク間でデータを伝送するためのブリッジ端末を有するローカルエリアネットワーク
US5459723A (en) Packet management device for fast-packet network
JPH07307737A (ja) Atm−uni・lan間通信方法及び通信装置
US20060256795A1 (en) System for triggering the control plane in an asynchronous connection-oriented transmission network
JPH0846644A (ja) パケット交換方式
US6256323B1 (en) Method and apparatus for efficiently transporting asynchronous characters over an ATM network
JPH07321842A (ja) パケット交換ネットワークを複数個のデータ端末にインタフェースする装置、フレームリレーパケットを交換するシステムに複数個のエンドポイントをインタフェースするモジュール、ならびにデータパケットを交換するシステムに端末をインタフェースする方法
CN100375461C (zh) 在网络中进行虚通路环保护倒换的方法
US5848058A (en) Frame relay switching node
JP3315926B2 (ja) Tcp通信高速化装置
CA2341939C (en) Label request packet transmission method, packet transfer network and method thereof, and packet transfer device
US6882626B1 (en) System and method for automated switching of data traffic in a packet network
JP3352038B2 (ja) データ通信システムおよび通信方法
Hekmat Communication networks
GB2171880A (en) Local area network
JPH04100343A (ja) Atmリンクシステム
CN111786718A (zh) 一种基于AoS插入业务的卫星光网络管理和控制平面信令传输方法
JP3474162B2 (ja) 地域通信ネットワーク
US20020141411A1 (en) Apparatus for line-concentrating and distributing PPP frame data
JP2850957B2 (ja) 音声パケットatm中継転送方式
JP3019855B2 (ja) Atm伝送装置
JP3132842B2 (ja) ラベル交換網におけるコネクションレス型通信方式とコネクション型通信方式との多重方式
US7197668B1 (en) Network wide debugging including node debugging information in the GAT IE of a PNNI Signaling Message

Legal Events

Date Code Title Description
FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080920

Year of fee payment: 6

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

Free format text: PAYMENT UNTIL: 20080920

Year of fee payment: 6

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

Free format text: PAYMENT UNTIL: 20090920

Year of fee payment: 7

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

Free format text: PAYMENT UNTIL: 20090920

Year of fee payment: 7

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

Free format text: PAYMENT UNTIL: 20100920

Year of fee payment: 8

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

Free format text: PAYMENT UNTIL: 20100920

Year of fee payment: 8

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

Free format text: PAYMENT UNTIL: 20110920

Year of fee payment: 9

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

Free format text: PAYMENT UNTIL: 20120920

Year of fee payment: 10

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

Free format text: PAYMENT UNTIL: 20130920

Year of fee payment: 11

LAPS Cancellation because of no payment of annual fees