JP5036041B2 - Rstp処理方式 - Google Patents

Rstp処理方式 Download PDF

Info

Publication number
JP5036041B2
JP5036041B2 JP2007115389A JP2007115389A JP5036041B2 JP 5036041 B2 JP5036041 B2 JP 5036041B2 JP 2007115389 A JP2007115389 A JP 2007115389A JP 2007115389 A JP2007115389 A JP 2007115389A JP 5036041 B2 JP5036041 B2 JP 5036041B2
Authority
JP
Japan
Prior art keywords
bpdu
unit
data
transmission
mac
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.)
Active
Application number
JP2007115389A
Other languages
English (en)
Other versions
JP2008271480A (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.)
Azbil Corp
Original Assignee
Azbil 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 Azbil Corp filed Critical Azbil Corp
Priority to JP2007115389A priority Critical patent/JP5036041B2/ja
Priority to PCT/JP2008/057766 priority patent/WO2008133250A1/ja
Priority to CN2008800129180A priority patent/CN101663863B/zh
Priority to US12/596,312 priority patent/US8213339B2/en
Priority to KR20097019570A priority patent/KR101025529B1/ko
Publication of JP2008271480A publication Critical patent/JP2008271480A/ja
Application granted granted Critical
Publication of JP5036041B2 publication Critical patent/JP5036041B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42Loop networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462LAN interconnection over a bridge based backbone
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/48Routing tree calculation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)

Description

本発明は、IEEE802.3に準拠した複数のノードが所定の伝送線路によって接続されてリング型のトポロジを構成したネットワークにおけるRSTP処理方式に係り、特にネットワークに生じた障害から極めて高速に復旧するに最適なRSTP処理方式に関する。
従来、IEEE802.3に準拠したイーサネット(登録商標:以下、同じ)等のLAN(ローカル・エリア・ネットワーク)におけるパケットのスイッチングを行うスイッチング・ハブが広く用いられている。この種のスイッチング・ハブは、IEEE802.1D/wによって規定されたスパニングツリープロトコルに基づいたBPDU(Bridge Protocol Data Unit)の送受信を行い、ループの発生を防止する機能を備える。
しかしながら、スイッチング・ハブによるスイッチングが継続したまま、このスイッチング・ハブを制御するCPU(中央処理装置)の処理が停止すると、スパニングツリープロトコルが正しく機能せず、ネットワークにループが形成されてしまうことがある。このような不具合を防止するため、パケットスイッチ装置およびスパニングツリートポロジの安定化方法が知られている(例えば、特許文献1参照)。
この装置および方法は、ハードウエアでパケットのスイッチを行う装置にスパニングツリープロトコルを実装する場合、パケットスイッチを行う回路にBPDUの送信を監視する回路を組み込み、スパニングツリープロトコルで規定された時間内にBPDUの送信が行われない場合には、パケットスイッチを停止することによってネットワークトポロジにループが発生することを抑制し、ネットワークを安定化させている。
ところでIEEE802.3に準拠したネットワークは、オフィスや家庭にも幅広く適用され、さらには、工業システムやビルシステムへの適用も試みられている。そしてオフィスに適用されるネットワークは、その利便性から配線方式としてスター型のトポロジが採用されている。一方、工業システムやビルシステムにおけるネットワークの形態は、一般に伝送線路の配線長が長くなることが否めず、そのため複数の制御機器(以下、ノードと称することがある)間に亘る、渡り配線方式を適用することが好ましい。具体的には、図17に示すように複数のノードN1,N2,・・・,Nnにそれぞれスイッチング・ハブS1,S2,・・・,Snを装備し、これらスイッチング・ハブS1,S2,・・・,Snが備えるポートのうちの2ポートをそれぞれ異なるノードに伝送線路1を介して接続し、リング型トポロジを構成する。そして、複数のスイッチング・ハブS1,S2,・・・,Snには、IEEE802.1wのRSTP(Rapid Spanning Tree Protocol)を搭載しておく。
本来、RSTPは、ネットワーク内においてパケットが無限に循環することを防止するものである。図17に示したようにRSTPの機能を利用することで、リング状にネットワークを構成したとしても、ネットワークの一箇所が論理的に切断(ブロッキング)された状態を維持するので、パケットがネットワーク内を無限にループすることがない。
このように構成されたネットワークにおいて、伝送線路1の断線やノードの電源ダウン等のネットワークに生じる障害を検出するには、所定の時間毎に予め定めたパケット、具体的にはBPDUをネットワークに送出し、その健全性を確かめるヘルシ・チェックを実施する。そして一定時間以内にBPDUを受信できない場合、各ノードは、障害が発生したことを認識する。するとスイッチング・ハブS1,S2,・・・,Snは、ネットワークのブロッキングを解除し、新しい通信ルートを形成する。このようにすることで、ネットワークに生じた障害が回避され正常な通信機能を維持することができる(リカバリ)。
より詳しくはスイッチング・ハブS1,S2,・・・,Snは、図18に示すように、2つのポート2A,2Bに伝送線路1がそれぞれ接続され、OSI参照モデルの物理層に係る処理をそれぞれ実行する2つのPHY部3A,3Bと、これらPHY部にそれぞれ接続されて、前記OSI参照モデルのデータリンク層の下位副層に係る処理をそれぞれ実行する2つのMAC部4A,4Bと、これらMAC部4A,4BとCPU5との間で相互にデータを授受すると共に、2つのMAC部4A,4B間でデータを受け渡すバッファ/転送回路部6を備えて構成される。
CPU5は、スイッチング・ハブS1,S2,・・・,Snが処理するデータリンク層より上位層(アプリケーション層およびネットワーク層)の処理を実行する。このCPU5は、前述したRSTP処理をソフトウエアで実行するRSTPアルゴリズム7を備える。またPHY部3A,3Bには、検出したネットワークの障害をバッファ/転送回路部6に伝えるLinkライン8A,8Bがそれぞれ設けられている。
このように構成されたネットワークでは、BPDUを所定の時間(一般には、2秒毎)に送出し、ネットワークにおける健全性の確認(ヘルシ・チェック)が行われている。この場合、RSTPアルゴリズムは、ソフトウエアによる処理であり、それ故、障害発生からリカバリ完了まで数秒程度の時間(リカバリ時間)がかかる。
ところで工業システムやビルシステムのようなリアルタイム伝送処置が要求されるネットワークの伝送周期は、極めて短く例えば10ms程度が望ましい。したがって、この伝送周期の範囲内でリカバリを完了することが要求されている。
特開2005−109846号公報
しかしながら、上述した構成をとるネットワークは、リカバリ時間に数秒程度を要するため、工業システムやビルシステムのようなリアルタイム伝送処理が要求されるネットワークには適用できないという問題がある。
ちなみにリカバリ時間を短縮するために、Linkライン8A,8Bを介して、物理層レベルにおける障害を検出することも可能であり、その場合は、リカバリ時間を50msにまで短縮することが可能ではあるものの、伝送周期が短い上述した工業システムやビルシステムには、適用できないという問題がある。
本発明は、このような従来の事情を考慮してなされたものであり、その目的とするところは、IEEE802.3に準拠した複数のノードが所定の伝送線路によって接続されてリング型のトポロジを構成したネットワークにおけるRSTP処理を極めて短い時間で処理し、リアルタイム伝送処理の要求を満たすリカバリ時間を実現するRTSP処理方式を提供することにある。
上述した目的を達成するため、本発明のRSTP処理方式は、IEEE802.3に準拠した複数のノードが所定の伝送線路によって接続されてリング型のトポロジを構成したネットワーク・システムにおけるRSTP処理方式であって、特に、
前記ノードは、前記伝送線路にそれぞれ接続されて、OSI参照モデルの物理層に係る処理をそれぞれ実行する2つのPHY部と、これらPHY部にそれぞれ接続されて、前記OSI参照モデルのデータリンク層の下位副層に係る処理をそれぞれ実行する2つのMAC部と、これらMAC部に接続されて、ラピッド・スパニング・ツリー・プロトコルを処理するRSTP処理部と、前記各MAC部にそれぞれ設けられて、前記ラピッド・スパニング・ツリー・プロトコルにおけるBPDUデータの送受をそれぞれ行うBPDU送受信バッファと、これらBPDU送受信バッファと前記RSTP処理部との間で前記BPDUデータを相互に受け渡す2つのBPDUデータバスとを具備し、
前記RSTP処理部は、一方の前記PHY部が前記ネットワークから受信し、このPHY部に接続された一方の前記MAC部における前記BPDU送受信バッファに蓄積されたBPDUデータを、このMAC部と接続された前記BPDUデータバスを介して受け取り、この受け取ったBPDUデータを解読して、所定の処理を実行した後、他方の前記MAC部と接続された前記BPDUデータバスを介して所定のBPDUデータを他方の前記BPDU送受信バッファに転送し、この他方のMAC部に接続された他方の前記PHY部から前記ネットワークに該BPDUデータを送出することを特徴としている。
すなわち、一方のMAC部のBPDU送受信バッファに蓄積されたBPDUデータをBPDUデータバスを介して受け取り、このBPDUデータを解読し、所定の処理を実行した後、他方のMAC部に接続されたBPDUデータバスを介して他方のMAC部およびPHY部からBPDUデータを送出する一連の処理をソフトウエアによることなくRSTP処理部のハードウエアによって実行する。
好ましくは前記PHY部は、前記RSTP処理部に前記物理層レベルの障害を通知するリンク信号ラインを有し、前記RSTP処理部は、一方の前記PHY部の前記リンク信号ラインから前記物理層レベルの障害が通知されたとき、他方のPHY部に接続された他方の前記MAC部が有する前記BPDU送受信バッファから前記ネットワークに前記他方のPHY部を介して通報BPDUデータを送出することが望ましい。
より好ましくは前記RSTP処理部は、2つの前記MAC部のBPDU送受信バッファをそれぞれ制御する2つのポート制御モジュールと、前記ネットワークにおける自ノードの優先順位を判定する優先順位制御モジュールとを備え、2つの前記MAC部のBPDU送受信動作は、並列処理で動作することが望ましい。
また前記各MAC部は、OSI参照モデルの上位層のプロトコルを司るCPUと互いに送受信データを受け渡す上位層データバスと、この上位層データバスとBPDU送受信バッファとのいずれか一方を前記PHY部に対する接続に切り換えるスイッチ部と、前記RSTP処理部からの制御を受けて前記スイッチ部における接続先を切り換えるBPDU送受信処理モジュール部とをそれぞれ具備し、
前記ポート制御モジュールは、前記PHY部から前記MAC部に与えられる受信データまたは前記MAC部から前記PHY部へ与える送信データが前記BPDUデータであるとき、前記BPDU送受信処理モジュール部に前記スイッチ部を前記BPDU送受信バッファ側に切り換える指令を与える一方、前記受信データまたは送信データが前記BPDUデータでないとき、前記スイッチ部を前記上位層データバス側に切り換える指令を与えることを特徴としている。
上述したRSTP処理方式によれば、RSTP処理をデータリンク層においてハードウエアで高速に処理し、10ms以下のRSTPリカバリ時間を実現する。
本発明の請求項1に記載のRSTP処理方式によれば、RSTPを処理するRSTP処理部をデータリンク層にハードウエアとして組み込み、このRSTP処理部とMAC部のBPDU送受信バッファとをBPDUデータバスで接続し、RSTP処理をハードウエア上で実行しているので、ソフトウエアの処理を介在することなく極めて高速にBPDUの処理が可能となる。
またPHY部が検出した物理層レベルの障害をリンク信号によってRTSP処理部に通知する一方、このリンク信号によって障害の通知を受けたRSTP処理部は、他方のPHY部に接続された他方のMAC部のBPDU送受信バッファからネットワークにBPDUデータを送出しているので、極めて少ない伝送遅延時間でBPDUデータを転送することができる。
本発明の請求項2又は3に記載のRSTP処理方式によれば、RSTP処理部に自ノードの優先順位を判定する優先順位制御モジュールを備えているので、リカバリ時におけるノードの優先順位の切り換え(すなわち、RootとDesignatedの切り換え)を高速に行うことができ、さらに、2つのMAC部はハードウエアによりリング型ネットワーク上の隣り合う複数ノードへのBPDUデータの送信時間を並列処理できるので、短時間のうちに障害からのネットワークの復旧システムを実現することができる。
本発明の請求項4に記載のRSTP処理方式によれば、MAC部にスイッチ部を設け、CPUとBPDU送受信バッファへの経路を切り換るように構成され、RSTP処理部は、PHY部からMAC部に与えられる受信データがBPDUデータであるとき、スイッチ部をBPDU送受信バッファ側に切り換える指令を与える一方、受信データがBPDUデータでないとき、BPDU送受信処理モジュール部にスイッチ部を上位層データバス側に切り換える指令を与えることと、また同様に他方、送信すべきデータがBPDUデータでない場合にはBPDU送受信モジュール部のスイッチ部を上位層データバス側に切り換える指令を与えることで、障害からのネットワークの復旧と上位層との通信を両方実行することができる等の実用上多大なる効果を奏する。
以下、本発明のRSTP処理方式について図面を参照しながら説明する。なお、図1〜図16は、本発明の一実施形態に係るRSTP処理方式を説明するための図であって、これらの図によって本発明が限定されるものではない。また、これらの図において図17,18と同一の符号を付した部分は同一物を表しているので、その説明を略述する。
さて、図1,2は、各ノードN1,N2,・・・,Nnにそれぞれ装備されたスイッチング・ハブS1,S2,・・・,Snのスイッチング・ハブの構成を示すものである。詳細は後述するがこの図に示したスイッチング・ハブS1,S2,・・・,Snが従来のスイッチング・ハブを示す図18と異なるところは、2つのMAC部4A,4Bにそれぞれにバッファ/転送回路部6とは別にラピッド・スパニング・ツリー・プロトコルにおけるBPDUデータの送受をそれぞれ行うBPDU送受信バッファ10A,10Bを新たに設け、さらにBPDU送受信バッファ10A,10Bまたはバッファ/転送回路部6とPHY部3A,3Bとの間でデータの接続を切り換えるスイッチ部11A,11B、このスイッチ部11A,11Bの切り換えを制御するBPDU送受信処理モジュール部12A,12B、RSTP処理をソフトウエアの介在なしに、ハードウエアで実行するRSTP処理部20、およびこのRSTP処理部20とBPDU送受信バッファ10A,10Bとの間でデータを相互に受け渡すBPUDデータバス13A,13Bをそれぞれ設けた点にある。
RSTP処理部20は、BPDUデータバス13A,13Bを介してBPDU送受信バッファ10A,10Bとデータを相互に送受するほか、BPDU送受信処理モジュール部12A,12Bに対する制御指令を行うポート制御モジュール21A,21Bを備えている。
これら2つのポート制御モジュール21A,21Bは、それぞれ接続されたMAC部4A,4Bに対して一方のポート制御モジュール21A,21Bから他方のポート制御モジュール21B,21Aに対して互いに送信要求(送信REQ)とその確認応答(送信ACK)を実行する。
またBPDUデータバス13A,13Bは、64バイトのBPDUデータを一度に(1クロックで)相互に受け渡しができるようBPDUデータのサイズに合わせた64バイトのデータ幅を有している。つまりポート制御モジュール21A,21BとBPDU送受信バッファ10A,10Bとの間のBPDUデータの受け渡し(リード/ライト)は、1クロックで完了する。
また2つのポート制御モジュール21A,21Bは、それぞれが制御するMAC部4A,4Bから伝えられる自ノードの優先順位を制御する優先順位制御モジュール22を備える。この優先順位制御モジュール22は、RSTPアルゴリズムにおける優先順位、すなわちRootとDesignatedを定めるものであって、ポート制御モジュール21A,21Bからの優先順位変更要求(変更REQ)を受け、その要求に対するID情報(RootID)を返す役割を担っている。
このように構成された本発明のRSTP処理方式におけるリカバリ時間短縮の効果について、より詳細に説明する。
この検討は、図3に示すように5つのノードN1〜N5のそれぞれにスイッチング・ハブS1〜S5を備え、各スイッチング・ハブS1〜S5の2つのノードを順に隣接するノードに伝送線路1を用いて接続してリング状のトポロジを形成する。ここではノード番号が小さい方が優先度が高いものとする。つまり、ノードN1の優先度が最も高くマスタ(Root)の役割を担い、他のノードN2〜N5は、ノードN1より優先度が低くスレーブ(Designated)の役割が与えられるものとする。また各スイッチング・ハブS1〜S5が有する2つのポートを、それぞれポートP1およびポートP2とする。ここでは図3に示した5つのスイッチング・ハブS1〜S5において向かって左側をポートP1、右側をポートP2とする。
するとマスタの役割を担うRootスイッチング・ハブ(以下、Rootと称することがある)は、優先度が最も高いノードN1に自動的に決められる。そしてネットワークが正常に動作しているとき、RootであるノードN1は、2つのポート(P1およびP2)から他のノードN5,N2にヘルシ・チェック用のBPDUを所定の時間毎(一般に2秒毎)に送信する。このBPDUを受け取ったノードN2およびノードN5は、それぞれ隣り合うノードに対して、受け取ったBPDUを転送する。つまりノードN2は、ポートP2からノードN3のポートP1に、ノードN5は、ポートP1からノードN4のポートP2にBPDUをそれぞれ転送する。
次いでノードN3は、同様にポートP2からノードN4のポートP1にBPDUを転送し、ノードN4は、ポートP1からノードN3のポートP2へBPDUを転送しようとする。このときノードN3およびノードN4は、それぞれノードN3のポートP2とノードN4のポートP1との間の通信を論理的にブロックする(ブロッキング)。このようにしてノード間の通信をブロッキングすることによってパケットがネットワーク内でループされることを防ぐ。
このようにブロッキングがなされているとき図4に示すようにノードN1とノードN2の伝送線路1にケーブル断障害が発生した場合(ST1)、ノードN2はポートP1のPHY部3Aのリンク信号によって障害を検知する(ST2)。するとノードN2は、新Root(New Root)として作動する(ST3:新Root生成)。ノードN2は、New Rootとして作動を開始した旨を、他のノード(Designated)に通報するために、ポートP2から「通報BPDU」(以下、「通報」と称する)を送信する(ST4)。このときノードN2のポート制御モジュール21A,21Bは、相互に送信REQおよび送信ACKをやり取りしてBPDUを確実に受け渡す。
この「通報」を受信したノードN3は、「通報」を受けたことノードN2に通知するためポートP1から「ACK BPDU」(以下、「ACK」と称する)を返信する(ST5)。ノードN3は、ポートP2から「通報」をノードN4に送信する(ST6)。以下、同様にノードN4,N5は、「通報」、「ACK」を相互に送信する(ST8〜ST10)。このときノードN4は、ノードN3からの「通報」を受信するとネットワークに障害が発生したと認識し、ブロッキングを解除する(ST7)。
そうしてノードN5のポートP2からノードN1のポートP1に「通報」が到着する(ST11)。するとノードN1は、優先度がノードN2より高いのでRootとしてその機能を継続する。次いでノードN1は、図5に示すようにRootで作動中であることをノードN2に通知する(ST12’)とともに、他の全ノードN5〜N2に「トポロジが変更された」ことを通知するため、「Re:通報BPDU」(以下「Re:通報」)を順次転送する(ST12)。この「Re:通報」を受け取った各ノードは、この応答として「ACK/Re:通報」を順次返信する(ST13〜ST20)。
このようにして、各ノードが順次「Re:通報」を受け取り、「ACK/Re:通報」を順次返信すると最後にノードN2に「Re:通報」が到着する。するとノードN2の優先順位制御モジュール22は、New Rootの作動をやめてDesignatedの動作に戻る(ST19)。このようにしてリカバリ動作は、完了し、新通信ルートが形成される。
なお、各ノードN1〜N5は、「通報」、「ACK」と「Re:通報」のどちらかを受信した場合、トポロジが変更されたと認識し、自ノードが保持する「ポートMACアドレス・テーブル」の内容を消去する。この「ポートMACアドレス・テーブル」とは、ポートの接続先のノードのMACアドレスの情報を保持しているものである。
ここで、図4,5の中のST1〜ST20までの動作時間の合計が、リカバリ時間となる。さらに、障害(図4ではノードN1とノードN2との間)が解消された場合には、同様な動作が実行され、再び正常動作時の状態(初期状態)に復帰する。
さて、このようなリカバリ動作を実行するネットワーク・システムにおいて本発明のリカバリに要する時間を算定する。このリカバリ動作におけるリカバリ時間は、次の各要素によって定まる。
(a)各ノードN1〜N5のRSTP処理時間とBPDUの伝搬時間
(b)障害発生箇所
(c)接続ノードの台数
(d)各ノードN1〜N5の通信状況
そこで、前述したRSTP動作原理を踏まえると、各ノードにおけるRSTP処理時間とBPDUの伝搬時間は、主に次の5つの要素に大別することができる。
(1)RT1:ノードが障害の発生を検出し、隣接するノードに対して「通報」の送信が完了するまでの時間(図4の場合は、ノードN2が該当する)
(2)RT2:「通報」を受信したノードが「ACK」を返信するとともに、他のポートから「通報」を送信し終えるまでの時間(図4の場合、ノードN3〜N5が該当する)
(3)RT3:「通報」を受信してから、両ポートに対し「Re:通報」を送信完了するまでの時間(図4および図5の場合、ノードN1が該当する)
(4)RT4:「Re:通報」を受信してから「ACK」を返信すると共に、他のポートから「Re:通報」を送信し終えるまでの時間(図5の場合、例、ノードN3、N4、N5が該当する)
(5)RT5:障害検出ノードが「Re:通報」を受信してから「ACK」の送信が完了するまでの時間(図5の場合、ノードN2が該当する)
そこでこれら5つの要素時間について本発明の計算モデルを作って計算する。
<計算モデル(1)RT1について>
まず伝搬時間RT1についてその所要時間を算出する。図6、図7に示すように障害が発生してからPHY部3A(または3B)がこの障害(Link障害)を検出するまでの時間をt1、PHY部3A(または3B)がLink障害を検出してからRSTP処理部20が処理を完了するまでの時間をt2、他方のMAC部4B(または4A)に「通報」データの送信処理に要する時間をt3、このMAC部4B(または4A)が「通報」データをMII(Media Independent Interface)に出力するまでの時間をt4、PHY部3B(または3A)が転送に要する時間(転送遅延時間)をt5、伝送線路(ケーブル)伝搬時間をt6とする。
なお、これらの時間を算出する条件として、「通報」データのフレーム長は72バイト、ネットワークはケーブル(伝送線路)にTIA/EIA−568−A−5に準拠したカテゴリ5のケーブル100mを用い、伝送速度100Mbpsで伝送するIEEE802.3で規定される100BASE−TXであるとし、PHY部3A,3BおよびMAC部4A,4Bの動作クロックはそれぞれ25MHzおよび50MHzであるとする。
すると、上述した各時間は、t1=20μs以下(実測値)、t2=0.14μs(7クロック)、t3=0.2μs(5クロック)、t4=5.76μs(フレーム長72バイト)、t5=70ns(7BT:Bit Time)、t6=538nsとなる。
したがって、伝搬時間RT1は、
RT1=t1+t2+t3+t4+t5+t6
=20+0.14+0.2+5.76+0.07+0.538=26.708μs
と求まる(内訳時間の詳細を図7に示す)。
<計算モデル(2)RT2について>
次に伝搬時間RT2についてその所要時間を算出する。図8、図9に示すようにPHY部3A(または3B)が転送に要する時間(転送遅延時間)をt7,t13,t17、MAC部4A(または4B)が「通報」を受信する時間(MIIからのデータ入力時間)をt8、MAC部4A(または4B)による「通報」データの受信処理時間をt9、RSTP処理部20におけるハードウエア処理時間をt10、MAC部4A(または4B)が「ACK」データを処理する時間をt11、MAC部4A(または4B)が「ACK」データをMIIに出力する時間をt12、伝送線路(ケーブル)伝搬時間をt14,t18、他方のMAC部4B(または4A)が「通報」データの送信を処理する時間をt15、このMAC部4B(または4A)が「通報」データをMIIに出力する時間をt16とする。
なお、伝搬時間RT2を算出するための条件は、前述した伝搬時間RT1を算出したときの条件と同一であり、また「ACK」のフレーム長は72バイトである。
すると、これらの時間は、t7=t13=t17=70ns(7BT)、t8=5.76μs、t9=0.28μs(7クロック)、t10=0.52μs(26クロック)、t11=0.2μs(5クロック)、t12=5.76μs、t14=t18=538ns、t15=0.2μs(5クロック)、t16=5.76μsとなる。
ちなみにMAC部4A(または4B)が「通報」を受信する時間(MIIからのデータ入力時間)t8は、伝搬時間RT1を算出した前述の計算式の時間t4と同じBPDUの送受信時間であり、伝搬時間RT2には含まない。当該t4およびt8にかかる「通報」データを送信および受信する処理は各ノードで同時に実行されるものだからである。また、上記時間の[t11+t12+t13+t14]と[t15+t16+t17+t18]は、2つのMAC部のハードウエア並列処理により同時に実行される。したがって、どちらか一方の時間を用いて伝搬時間RT2を算出すればよい。計算数値上はどちらも等価だが、ここでは、次のノードにおける処理時間の連結に着目し、後者を採用する。
よって伝搬時間RT2は、
RT2=t7+t9+t10+t15+t16+t17+t18
=0.07+0.28+0.52+0.2+5.76+0.07+0.538
=7.438μs
と求まる(内訳時間の詳細を図9に示す)。
<計算モデル(3)RT3について>
次に伝搬時間RT3についてその所要時間を算出する。図10、図11に示すようにPHY部3A(または3B)が転送に要する時間(転送遅延時間)をt19,t25,t29、MAC部4A(または4B)が「通報」をMIIから入力する時間をt20、MAC部4A(または4B)による「通報」データの受信処理時間をt21、RSTP処理部20におけるハードウエア処理時間をt22、MAC部4A(または4B)が「Re:通報」データを送信処理する時間をt23、MAC部4A(または4B)が「Re:通報」データをMIIに出力する時間をt24、伝送線路(ケーブル)伝搬時間をt26,t30、他方のMAC部4B(または4A)が「Re:通報」データの送信を処理する時間をt27、このMAC部4B(または4A)が「Re:通報」データをMIIに出力する時間をt28とする。
なお、伝搬時間RT3を算出するための条件は、前述した伝搬時間RT1,RT2を算出したときの条件と同一であり、また「Re:通報」のフレーム長は72バイトである。
ちなみに伝搬時間RT2の計算と同様にMAC部4A(または4B)が「通報」をMIIから入力する時間t20は、伝搬時間RT2の前述計算式中の時間t16と同時に発生するので伝搬時間RT3の計算に含まない。また、上記時間の[t23+t24+t25+t26]と[t27+t28+t29+t30]は、ハードウエア並列処理のため同時に実行される。したがって、どちらか一方の時間を用いて伝搬時間RT3を算出すれば足りる。ここでは、次のノードにおける処理時間の連結に着目し、前者を採用する。
よって、伝搬時間RT3は、
RT3=t19+t21+t22+t23+t24+t25+t26
=0.07+0.28+0.32+0.2+5.76+0.07+0.538
=7.238μs
と求まる(内訳時間の詳細を図11に示す)。
<計算モデル(4)RT4について>
次に伝搬時間RT4についてその所要時間を算出する。図12、図13に示すようにPHY部3A(または3B)が転送に要する時間(転送遅延時間)をt31,t37,t41、MAC部4A(または4B)が「Re:通報」をMIIから入力する時間をt32、MAC部4A(または4B)による「Re:通報」データの受信処理時間をt33、RSTP処理部20におけるハードウエア処理時間をt34、MAC部4A(または4B)が「ACK」データを送信処理する時間をt35、MAC部4A(または4B)が「ACK」データをMIIに出力する時間をt36、伝送線路(ケーブル)伝搬時間をt38,t42、他方のMAC部4B(または4A)が「Re:通報」データの送信を処理する時間をt39、このMAC部4B(または4A)が「Re:通報」データをMIIに出力する時間をt40とする。
なお、伝搬時間RT4を算出するための条件は、前述した伝搬時間RT1〜RT3を算出したときの条件と同一である。
ちなみに伝搬時間RT2,RT3の計算と同様にMAC部4A(または4B)が「Re:通報」をMIIから入力する時間をt32は、伝搬時間RT3の前述計算式中の時間t28と同時に発生するので伝搬時間RT4の計算には含まない。また、上記時間の[t35+t36+t37+t38]と[t39+t40+t41+t42]は、ハードウエア並列処理のため同時に実行される。したがって、どちらか一方の時間を用いて伝搬時間RT4を算出すれば足りる。ここでは、次のノードにおける処理時間の連結に着目するので、後者を採用する。
よって、伝搬時間RT4は、
RT4=t31+t33+t34+t39+t40+t41+t42
=0.07+0.28+0.4+0.2+5.76+0.07+0.538
=7.318μs
と求まる(内訳時間の詳細を図13に示す)。
<計算モデル(5)RT5について>
最後に、伝搬時間RT5についてその所要時間を算出する。図14、図15に示すようにPHY部3A(または3B)が転送に要する時間(転送遅延時間)をt43,t49、MAC部4A(または4B)が「Re:通報」をMIIから入力する時間をt44、MAC部4A(または4B)による「Re:通報」データの受信処理時間をt45、RSTP処理部20におけるハードウエア処理時間をt46、MAC部4A(または4B)が「ACK」データを送信処理する時間をt47、MAC部4A(または4B)が「ACK」データをMIIに出力する時間をt48、伝送線路(ケーブル)伝搬時間をt50とする。
なお、伝搬時間RT5を算出するための条件は、前述した伝搬時間RT1〜RT4を算出したときの条件と同一である。
ちなみに伝搬時間RT2〜RT4の計算と同様にMAC部4A(または4B)が「Re:通報」をMIIから入力する時間をt44は、伝搬時間RT4の前述計算式中の時間t40と同時に発生するので伝搬時間RT5の計算には含まない。
よって、伝搬時間RT5は、
RT5=t43+t45+t46+t47+t48+t49+t50
=0.07+0.28+0.52+0.2+5.76+0.07+0.538
=7.438μs
と求まる(内訳時間の詳細を図15に示す)。
<総合計算モデルについて>
これらの伝搬時間RT1〜5に基づき、図3に示した5つのノードN1〜N5で構成されたネットワークにおけるリカバリ時間RT(最大値)を求めると次式に示すようになる。
RT=RT1(ノードN2)+RT2(ノードN3)+RT2(ノードN4)
+RT2(ノードN5)+RT3(ノードN1)+RT4(ノードN5)
+RT4(ノードN4)+RT4(ノードN3)+RT5(ノードN2)
=RT1+3×RT2+RT3+3×RT4+RT5
=26.708+3×7.438+7.238+3×7.318+7.438
=85.652μs
ただし、この計算式で求められるリカバリ時間は、各ノードがRSTP処理に係るデータ以外を送信していない状態(ゼロ負荷と称する)のときである。
またこの計算式に基づいて、n台のノードでリング状のトポロジを構成した場合、リカバリ時間RT(最大値)を求める計算式を次式に示すように得ることができる。
RT=RT1+(n−2)×RT2+RT3+(n−2)×RT4+RT5
=26.71+(n−2)×7.438+7.238+(n−2)×7.318
+7.438
=26.628+(n−1)×14.756μs
よって100台のノードを用いて構成した場合のリカバリ時間RT(最大値)は、約1.487msとなる。
逆に工業システムやビルシステムのようなリアルタイム伝送処置が要求されるネットワークでリカバリ時間を10ms以内に抑えたい場合、上記式を変形してノードの最大数を求めればよく、そのノードは676台となる。
次にIEEE802.3が規定する各ノードがネットワークに一度に出力できるフレームの最大長である1526バイトのフレームを出力したと仮定したとき、同様に伝搬時間RT1〜RT5を求める(これを絶対最大負荷と称する)。100BASE−TXにおいて1526バイトのフレームを出力するのに必要な時間は、122.08μsであるから、この時間を上記RT1〜RT5のそれぞれに加えればよい。具体的には、上述したMIIに出力する時間t4,t16,t28,t40,t48にそれぞれ122.08μsを加えればよい。
このようにして各ノードが1526バイトのデータをそれぞれ任意に送出するものとして求めた伝搬時間RT1〜RT5は、それぞれ次のようになる。
RT1=148.788μs
RT2=129.518μs
RT3=129.318μs
RT4=129.398μs
RT5=129.518μs
よって、5つのノードが絶対最大負荷のときのリカバリ時間RT(最大値)は、上記式を用いれば、
RT=1184.372μs
と求まる。また、n台のノードがある場合のリカバリ時間RT(最大値)は、
RT=148.708+(n−1)×258.916μs
となる。したがってこの場合、リカバリ時間を10ms以内に抑えるには、ノードの台数を39台以下にすればよい。
次に工業システムやビルシステムのようなリアルタイム伝送処置が要求されるネットワークにおいて各ノードは、200バイト程度のデータを送受するのが一般的である(これを実際最大負荷と称する)。そこで各ノードが200バイトのデータをそれぞれ任意に送出するものとして伝搬時間RT1〜RT5を再計算する。100BASE−TXの場合、200バイトのデータを送信するのに要する時間は16μsであるから、上述したMIIに出力する時間t4,t16,t28,t40,t48に16μsを加えればよい。
このようにして求めた伝搬時間RT1〜RT5は、それぞれ次のようになる。
RT1=42.708μs
RT2=23.438μs
RT3=23.238μs
RT4=23.318μs
RT5=23.438μs
よって、5つのノードが実際最大負荷のときのリカバリ時間RT(最大値)は、上記式を用いれば、
RT=229.652μs
と求まる。また、n台のノードがある場合のリカバリ時間RT(最大値)は、
RT=42.628+(n−1)×46.756μs
となる。したがってこの場合、10msのリカバリ時間内を満たすノードの台数は、最大213台まで可能となる。
このようにして求められたノード台数とリカバリ時間の関係を図示すると図16のグラフが得られる。このグラフに示されるように本発明のRTSP処理方式は、リアルタイムシステムにも充分適用できることが確かめられた。
かくして本発明のRSTP処理方式は、RSTPを処理するRSTP処理部20をデータリンク層にハードウエアとして組み込み、このRSTP処理部20とMAC部4A,4BのBPDU送受信バッファ10A,10BとをBPDUデータバス13A,13Bで接続し、RSTP処理をハードウエア上で実行しているので、ソフトウエアの処理を介在することなく極めて高速にBPDUの処理ができる。
また本発明のRSTP処理方式は、PHY部3A,3Bが検出した物理層レベルの障害をリンク信号によってRTSP処理部20に通知する一方、このリンク信号によって障害の通知を受けたRSTP処理部20は、他方のPHY部3B,3Aに接続された他方のMAC部4B,4AのBPDU送受信バッファ10B,10AからネットワークにBPDUデータを送出するので、極めて少ない伝送遅延時間でBPDUデータを転送することができる。
さらに本発明のRSTP処理方式は、RSTP処理部20に自ノードの優先順位を判定する優先順位制御モジュール22を備えているので、リカバリ時におけるノードの優先順位の切り換え(すなわち、RootとDesignatedの切り換え)を高速に行うことができ、短時間のうちにネットワークの復旧ができる。
また本発明のRSTP処理方式は、MAC部4A,4Bにスイッチ部11A,11Bを設け、CPUとBPDU送受信バッファ10A,10Bへの経路を切り換るように構成され、RSTP処理部20が、PHY部3A,3BからMAC4A,4B部に与えられる受信データがBPDUデータであるとき、スイッチ部11A,11BをBPDU送受信バッファ10A,10Bに切り換える指令を与える一方、受信データがBPDUデータでないとき、BPDU送受信処理モジュール部12A,12Bにスイッチ部を上位層データバスに切り換える指令を与えているので、ノード間の上位層における通信を実行しつつ短時間のうちに障害からのネットワークの復旧と再構成を実行することができる等の実用上多大なる効果を奏する。
なお、本発明のRSTP処理方式は、上記した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加えてもかまわない。
本発明の一実施形態に係るノードおよびスイッチング・ハブの要部構成を示すブロック図。 図1のスイッチング・ハブの構成の詳細構成を示すブロック図。 複数のノードが伝送線路によってリング状のトポロジを構成するネットワークにおけるBPDUデータの流れを示す図。 図3に示すネットワークでケーブル断障害が発生したときの通報およびACKの転送手順を示した図。 図4の通報に対する返信およびそのACKの転送手順を示した図。 ノードが障害の発生を検出し、隣接するノードに対して通報の送信が完了するまでの時間を示した図。 図6に示した内訳時間の定義、時間および条件を示した図。 通報を受信したノードがACKを返信するとともに、他のポートから通報を送信し終えるまでの時間を示した図。 図8に示した内訳時間の定義、時間および条件を示した図。 通報を受信してから、両ポートに対しその返信を送信完了するまでの時間を示した図。 図10に示した内訳時間の定義、時間および条件を示した図。 通報に対する返信を受信してからACKを返信すると共に、他のポートから通報に対する応答を送信し終えるまでの時間を示した図。 図12に示した内訳時間の定義、時間および条件を示した図。 障害検出ノードが通報に対する返信を受信してからACKの送信が完了するまでの時間を示した図。 図14に示した内訳時間の定義、時間および条件を示した図。 ノードの台数とリカバリ時間との関係を示したグラフ。 複数のノードが伝送線路によってリング状のトポロジを構成したネットワークの概略構成を示すブロック図。 従来のノードおよびスイッチング・ハブの要部構成を示すブロック図。
符号の説明
1 伝送線路
2A,2B ポート
3B,3A PHY部
4B,4A MAC部
5 CPU
6 バッファ/転送回路部
8A,8B Linkライン
9 上位層データバス
10A,10B BPDU送受信バッファ
11A,11B スイッチ部
12A,12B BPDU送受信処理モジュール部
13A,13B データバス
20 RSTP処理部
21A,21B ポート制御モジュール
22 優先順位制御モジュール
N1,N2,・・・,Nn ノード
S1,S2,・・・,Sn スイッチング・ハブ

Claims (4)

  1. IEEE802.3に準拠した複数のノードが所定の伝送線路によって接続されてリング型のトポロジを構成したネットワーク・システムにおけるRSTP処理方式であって、
    前記ノードは、前記伝送線路にそれぞれ接続されて、OSI参照モデルの物理層に係る処理をそれぞれ実行する2つのPHY部と、
    これらPHY部にそれぞれ接続されて、前記OSI参照モデルのデータリンク層の下位副層に係る処理をそれぞれ実行する2つのMAC部と、
    これらMAC部に接続されて、ラピッド・スパニング・ツリー・プロトコルを処理するRSTP処理部と、
    前記各MAC部にそれぞれ設けられて、前記ラピッド・スパニング・ツリー・プロトコルにおけるBPDUデータの送受をそれぞれ行うBPDU送受信バッファと、
    これらBPDU送受信バッファと前記RSTP処理部との間で前記BPDUデータを相互に受け渡す2つのBPDUデータバスとを具備し、
    前記PHY部は、前記RSTP処理部に前記物理層レベルの障害を通知するリンク信号ラインを有し、
    前記RSTP処理部は、一方の前記PHY部が前記ネットワークから受信し、このPHY部に接続された一方の前記MAC部における前記BPDU送受信バッファに蓄積されたBPDUデータを、このMAC部と接続された前記BPDUデータバスを介して受け取り、この受け取ったBPDUデータを解読して、所定の処理を実行した後、他方の前記MAC部と接続された前記BPDUデータバスを介して所定のBPDUデータを他方の前記BPDU送受信バッファに転送し、この他方のMAC部に接続された他方の前記PHY部から前記ネットワークに該BPDUデータを送出し、さらに、一方の前記PHY部の前記リンク信号ラインから前記物理層レベルの障害が通知されたとき、他方のPHY部に接続された他方の前記MAC部が有する前記BPDU送受信バッファから前記ネットワークに前記他方のPHY部を介して通報BPDUデータを送出することを特徴とするRSTP処理方式。
  2. IEEE802.3に準拠した複数のノードが所定の伝送線路によって接続されてリング型のトポロジを構成したネットワーク・システムにおけるRSTP処理方式であって、
    前記ノードは、前記伝送線路にそれぞれ接続されて、OSI参照モデルの物理層に係る処理をそれぞれ実行する2つのPHY部と、
    これらPHY部にそれぞれ接続されて、前記OSI参照モデルのデータリンク層の下位副層に係る処理をそれぞれ実行する2つのMAC部と、
    これらMAC部に接続されて、ラピッド・スパニング・ツリー・プロトコルを処理するRSTP処理部と、
    前記各MAC部にそれぞれ設けられて、前記ラピッド・スパニング・ツリー・プロトコルにおけるBPDUデータの送受をそれぞれ行うBPDU送受信バッファと、
    これらBPDU送受信バッファと前記RSTP処理部との間で前記BPDUデータを相互に受け渡す2つのBPDUデータバスとを具備し、
    前記RSTP処理部は、一方の前記PHY部が前記ネットワークから受信し、このPHY部に接続された一方の前記MAC部における前記BPDU送受信バッファに蓄積されたBPDUデータを、このMAC部と接続された前記BPDUデータバスを介して受け取り、この受け取ったBPDUデータを解読して、所定の処理を実行した後、他方の前記MAC部と接続された前記BPDUデータバスを介して所定のBPDUデータを他方の前記BPDU送受信バッファに転送し、この他方のMAC部に接続された他方の前記PHY部から前記ネットワークに該BPDUデータを送出し、
    さらに、前記RSTP処理部は、2つの前記MAC部のBPDU送受信バッファをそれぞれ制御する2つのポート制御モジュールと、前記ネットワークにおける自ノードの優先順位を判定する優先順位制御モジュールとを備え、2つの前記MAC部のBPDU送受信動作は、並列処理で動作することを特徴とするRSTP処理方式。
  3. 前記RSTP処理部は、2つの前記MAC部のBPDU送受信バッファをそれぞれ制御する2つのポート制御モジュールと、前記ネットワークにおける自ノードの優先順位を判定する優先順位制御モジュールとを備え、2つの前記MAC部のBPDU送受信動作は、並列処理で動作することを特徴とする請求項1に記載のRSTP処理方式。
  4. 前記各MAC部は、OSI参照モデルの上位層のプロトコルを司るCPUと互いに送受信データを受け渡す上位層データバスと、
    この上位層データバスとBPDU送受信バッファとのいずれか一方を前記PHY部に対する接続に切り換えるスイッチ部と、
    前記RSTP処理部からの制御を受けて前記スイッチ部における接続先を切り換えるBPDU送受信処理モジュール部とをそれぞれ具備し、
    前記ポート制御モジュールは、前記PHY部から前記MAC部に与えられる受信データまたは前記MAC部から前記PHY部へ与える送信データが前記BPDUデータであるとき、前記BPDU送受信処理モジュール部に前記スイッチ部を前記BPDU送受信バッファ側に切り換える指令を与える一方、前記受信データまたは送信データが前記BPDUデータでないとき、前記スイッチ部を前記上位層データバス側に切り換える指令を与えることを特徴とする請求項2又は3に記載のRSTP処理方式。
JP2007115389A 2007-04-25 2007-04-25 Rstp処理方式 Active JP5036041B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2007115389A JP5036041B2 (ja) 2007-04-25 2007-04-25 Rstp処理方式
PCT/JP2008/057766 WO2008133250A1 (ja) 2007-04-25 2008-04-22 Rstp処理方式
CN2008800129180A CN101663863B (zh) 2007-04-25 2008-04-22 Rstp处理方式
US12/596,312 US8213339B2 (en) 2007-04-25 2008-04-22 RSTP processing system
KR20097019570A KR101025529B1 (ko) 2007-04-25 2008-04-22 Rstp 처리 방식

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007115389A JP5036041B2 (ja) 2007-04-25 2007-04-25 Rstp処理方式

Publications (2)

Publication Number Publication Date
JP2008271480A JP2008271480A (ja) 2008-11-06
JP5036041B2 true JP5036041B2 (ja) 2012-09-26

Family

ID=39925700

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007115389A Active JP5036041B2 (ja) 2007-04-25 2007-04-25 Rstp処理方式

Country Status (5)

Country Link
US (1) US8213339B2 (ja)
JP (1) JP5036041B2 (ja)
KR (1) KR101025529B1 (ja)
CN (1) CN101663863B (ja)
WO (1) WO2008133250A1 (ja)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8725905B2 (en) * 2006-01-11 2014-05-13 Dell Products L.P. Power over ethernet powered management and diagnoses of information handling systems
US8179787B2 (en) * 2009-01-27 2012-05-15 Smsc Holding S.A.R.L. Fault tolerant network utilizing bi-directional point-to-point communications links between nodes
JP5398436B2 (ja) * 2009-09-09 2014-01-29 三菱電機株式会社 ブリッジ、ネットワークシステムおよび経路切り替え方法
DE102010041427A1 (de) * 2010-09-27 2012-03-29 Robert Bosch Gmbh Verfahren zum Übertragen von Daten
US9201685B2 (en) 2011-01-28 2015-12-01 Oracle International Corporation Transactional cache versioning and storage in a distributed data grid
US9081839B2 (en) 2011-01-28 2015-07-14 Oracle International Corporation Push replication for use with a distributed data grid
US9164806B2 (en) 2011-01-28 2015-10-20 Oracle International Corporation Processing pattern framework for dispatching and executing tasks in a distributed computing grid
US9063852B2 (en) * 2011-01-28 2015-06-23 Oracle International Corporation System and method for use with a data grid cluster to support death detection
US9063787B2 (en) 2011-01-28 2015-06-23 Oracle International Corporation System and method for using cluster level quorum to prevent split brain scenario in a data grid cluster
US10706021B2 (en) 2012-01-17 2020-07-07 Oracle International Corporation System and method for supporting persistence partition discovery in a distributed data grid
US8923113B2 (en) * 2012-06-27 2014-12-30 Cisco Technology, Inc. Optimizations in multi-destination tree calculations for layer 2 link state protocols
US10664495B2 (en) 2014-09-25 2020-05-26 Oracle International Corporation System and method for supporting data grid snapshot and federation
US10585599B2 (en) 2015-07-01 2020-03-10 Oracle International Corporation System and method for distributed persistent store archival and retrieval in a distributed computing environment
US11163498B2 (en) 2015-07-01 2021-11-02 Oracle International Corporation System and method for rare copy-on-write in a distributed computing environment
US10860378B2 (en) 2015-07-01 2020-12-08 Oracle International Corporation System and method for association aware executor service in a distributed computing environment
US10798146B2 (en) 2015-07-01 2020-10-06 Oracle International Corporation System and method for universal timeout in a distributed computing environment
KR20170008913A (ko) 2015-07-14 2017-01-25 현대중공업 주식회사 디지털보호계전기용 iec 61850 통신 이중화 이더넷모듈
KR101822863B1 (ko) * 2016-09-09 2018-01-29 주식회사 쏠리드 셀룰라 통신 시스템
CN106789521B (zh) * 2016-12-29 2019-07-26 瑞斯康达科技发展股份有限公司 一种环网故障倒换方法及环节点
US11550820B2 (en) 2017-04-28 2023-01-10 Oracle International Corporation System and method for partition-scoped snapshot creation in a distributed data computing environment
US10769019B2 (en) 2017-07-19 2020-09-08 Oracle International Corporation System and method for data recovery in a distributed data computing environment implementing active persistence
US10721095B2 (en) 2017-09-26 2020-07-21 Oracle International Corporation Virtual interface system and method for multi-tenant cloud networking
US10862965B2 (en) 2017-10-01 2020-12-08 Oracle International Corporation System and method for topics implementation in a distributed data computing environment
US20190305983A1 (en) * 2018-03-29 2019-10-03 Hyundai Motor Company Method and apparatus for configuring backup path in vehicle network

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0879518B1 (en) * 1996-02-09 2010-04-28 Level One Communications, Inc Automatic speed switching repeater
JP4021841B2 (ja) * 2003-10-29 2007-12-12 富士通株式会社 スパニングツリープロトコルにおける制御パケット処理装置および方法
JP2004282409A (ja) * 2003-03-17 2004-10-07 Meidensha Corp 情報転送システムおよび情報転送システムの論理的トポロジ構築方法
JP3969375B2 (ja) 2003-09-30 2007-09-05 日本電気株式会社 パケットスイッチ装置及びスパニングツリートポロジの安定化方式
JP4397292B2 (ja) * 2004-07-09 2010-01-13 富士通株式会社 制御パケットループ防止方法及びそれを用いたブリッジ装置
JP2006174422A (ja) * 2004-11-19 2006-06-29 Yamatake Corp 通信装置および障害通知方法
WO2006065795A2 (en) * 2004-12-14 2006-06-22 Alcatel Lucent Ring rapid spanning tree protocol

Also Published As

Publication number Publication date
US8213339B2 (en) 2012-07-03
JP2008271480A (ja) 2008-11-06
CN101663863B (zh) 2012-05-30
US20100128732A1 (en) 2010-05-27
KR20090123892A (ko) 2009-12-02
KR101025529B1 (ko) 2011-04-04
CN101663863A (zh) 2010-03-03
WO2008133250A1 (ja) 2008-11-06

Similar Documents

Publication Publication Date Title
JP5036041B2 (ja) Rstp処理方式
US9231849B2 (en) Apparatus and method for controlling virtual switches
US8473656B2 (en) Method and system for selecting a communications bus system as a function of an operating mode
JP4074631B2 (ja) 伝送路システム、および同システムにおけるフレーム伝送装置、ならびに伝送路切り替え方法
JP4527447B2 (ja) ネットワーク中継装置及びその制御方法
JP5395450B2 (ja) リング型スイッチおよびリング型スイッチ制御方法
JP2005347943A (ja) ネットワーク中継装置及びその制御方法
US10090952B2 (en) Master/slave negotiation associated with a synchronous ethernet network
US6647446B1 (en) Method and system for using a new bus identifier resulting from a bus topology change
US9413642B2 (en) Failover procedure for networks
WO2020129219A1 (ja) ネットワーク装置、ネットワークシステム、ネットワーク方法、およびネットワークプログラム
JP5912923B2 (ja) リング/スター型イーサネットシステム、リング/スター型スイッチ、およびフレーム転送制御方法
JP2006109258A (ja) 通信方法及び通信装置
US20140347974A1 (en) Data transmission network and programmable network node
JP6554405B2 (ja) リングネットワークシステム、及び、ネットワークノード
US10735310B2 (en) Controller, method for adjusting flow rule, and network communication system
CN113346983A (zh) 具有镜像冗余的epa设备和epa***
JP5422585B2 (ja) リング状ネットワークシステム
JP4944986B2 (ja) 伝送路システムおよび伝送路構築方法
JP2011188414A (ja) リング型スイッチ、リング型イーサネットシステム、リング型スイッチ制御方法、およびリング型イーサネットシステム制御方法
US11757799B2 (en) Line monitor device and network switch
JP5113215B2 (ja) ネットワーク中継装置及びその制御方法
JP2017147713A (ja) ノード装置、および通信システム
JP6772739B2 (ja) 通信システム
JP6478244B2 (ja) 通信インターフェース装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100315

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120208

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120220

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

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120702

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

Free format text: PAYMENT UNTIL: 20150713

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5036041

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250