JP5388211B2

JP5388211B2 - 通信装置

Info

Publication number: JP5388211B2
Application number: JP2010026309A
Authority: JP
Inventors: 昇吉兼; 逸郎森田
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2010-02-09
Filing date: 2010-02-09
Publication date: 2014-01-15
Anticipated expiration: 2030-02-09
Also published as: JP2011166408A

Description

本発明は、イーサネット（登録商標）ネットワークの運用技術に関するものである。より詳細には、スパニングツリープロトコル（Spanning Tree Protocol）とＥＥＥ（Energy Efficient Ethernet）が適用されたイーサネット（登録商標）ネットワークの運用技術に関するものである。

現在、レイヤ２ネットワークとして、イーサネット（登録商標）技術が普及している。イーサネット（登録商標）ネットワークにおいて、データが永遠に回り続けてしまうことを防ぐためのイーサネット（登録商標）スイッチ機能としてスパニングツリープロトコル（参考：非特許文献１、２）がある。スパニングツリープロトコル機能を用いることで、たとえイーサネット（登録商標）ネットワークが物理的にループ構成になっていても、イーサネット（登録商標）スイッチが適切なポートを自動的に閉塞し、論理的にはループのないネットワークを構成する。

また、現在、IEEE802.1azにおいて、イーサネット（登録商標）インタフェースの利用率に基づいてインタフェースの速度を最適化し、消費電力を削減する技術の規格化が推進されている。これは“Energy Efficient Ethernet (EEE)技術”と呼ばれている（参考：非特許文献３）。

IEEE802.1D, "Spanning Tree Protocol" "スパニング・ツリー完全理解"、[online]、［平成２２年２月１日検索］、インターネット＜ＵＲＬ：http://itpro.nikkeibp.co.jp/article/COLUMN/20060930/249477/＞ IEEE802.1az, "Energy Efficient Ethernet"（現在、規格化検討中の段階であるため、正式文書はリリースされていない。ドラフト版IEEE Draft P802.3az/D2.2（2010年1月現在））

スパニングツリープロトコル（以後、ＳＴＰとする）が動作しているネットワークに対して、Energy Efficient Ethernet（以後、ＥＥＥとする）技術が適用される場合に発生しうる課題について以下に述べる。

ＥＥＥ機能によりあるインタフェースが休止した場合、ＳＴＰを具備したレイヤ２スイッチはネットワークの構成に変更があったと認識して経路切り替え作業に移る場合がある。この場合、インタフェースやリンクに障害が発生したのではなくＥＥＥ機能によりインタフェースが休止しただけであるため、本来は経路を切り替える必要はない。しかしながら、ＳＴＰをサポートした装置が、ＥＥＥによりインタフェースが休止したのか否かを判別する手段を有していないため、上記のように経路切り替えを実行してしまう場合がある。

ＳＴＰによる経路切り替え後に、ＥＥＥ機能により休止していたインタフェースが復旧すると、再びネットワークのトポロジに変化が発生するためＳＴＰによる経路計算が行われ経路が切り替えられる。トラフィック量が変動することでＥＥＥ機能によるインタフェースの休止と復旧が繰り返されると、上記のようなＳＴＰによる経路切り替えが繰り返されることになる。ＳＴＰによる経路切り替え時には、切り替えの対象となるスイッチの通信が止まってしまう。そのため、ＥＥＥ機能によるインタフェースの休止と復旧に起因したＳＴＰの経路切り替えは、不要な通信断を発生させてしまうという課題がある。

したがって、本発明は、ＥＥＥ機能によりインタフェースが休止した場合に、ＳＴＰ機能による経路切り替えに起因する通信断を防ぐことが可能な通信装置を提供することを目的とする。

上記目的を実現するため本発明による通信装置は、ネットワーク内のループ構成を回避する回避機能および、インタフェースを休止および復旧させる休止機能を備えた通信装置において、前記回避機能のフレームのみを一定時間以上送受信しているインタフェースに対して、該フレーム断の検出機能をマスクする手段と、前記インタフェースを前記休止機能により休止させる手段と、前記回避機能のフレーム以外のパケットを前記インタフェースのバッファにて検出した場合に、前記休止機能により前記インタフェースを復旧させる手段と、前記休止機能により前記インタフェースを復旧させた場合に、前記フレーム断の検出機能のマスクを解除する手段とを備える。

また、前記フレーム断の検出機能のマスクを行った後、前記回避機能のフレームの送受信を停止させる手段と、前記フレーム断の検出機能のマスク解除を行った後、前記回避機能のフレームの送受信を開始させる手段とをさらに備えることも好ましい。

また、前記休止機能により休止されたインタフェースに対して、リンクの確立が成功するか否かで死活監視を実行する監視手段をさらに備えることも好ましい。

また、前記回避機能はＳＴＰ（Spanning Tree Protocol）機能であり、前記休止機能はＥＥＥ（Energy Efficient Ethernet）機能であり、前記回避機能のフレームは、Configuration BPDUであることも好ましい。

また、前記監視手段は、ＥＥＥ機能により休止されたインタフェースに対して、Configuration BPDUのHello Time設定時間間隔よりも長い周期で、ＥＥＥ機能を用いてリンクの確立が成功するか否かで死活監視を実行する手段であることも好ましい。

本発明により、ＳＴＰが動作しているイーサネット（登録商標）ネットワークに対して、ＥＥＥ技術が適用された場合に発生する不要な通信断を抑制することが可能になる。

本発明の通信装置の機能ブロック図を示す。本発明の通信装置の処理フローチャートを示す。ＳＴＰ機能のConfiguration BPDUの構造を示す。本発明の通信装置の実施例を示す。

図１は、本発明の通信装置の機能ブロック図を示す。通信装置は、インタフェース１、ＭＡＣ処理部２、スイッチ部３、メモリバッファ部４、スイッチ制御部５、およびＳＴＰ＆ＥＥＥ制御部６を備えている。

通信装置のインタフェース１から入力されたイーサネット（登録商標）フレームは、ＭＡＣ処理部２のＭＡＣテーブルに従い、自装置あてのフレームか、他インタフェースへ転送されるフレームかが判断される。他インタフェースに転送されるフレームは、スイッチ部３にてスイッチングされ適切なインタフェースに渡される。メモリバッファ部４では、スイッチング時のフレームを一時的に蓄える機能を有する。スイッチ制御部５は、スイッチング時の制御を行う。インタフェース１はＥＥＥをサポートしており、インタフェースのバッファのトラフィック量を監視し、バッファのトラフィック量に応じてインタフェースの速度調整、および休止・復旧を実行する。

インタフェース１は、イーサネット（登録商標）フレームを送受信するインタフェースである。また、各インタフェース１は、バッファを有する。本インタフェース１は、ＥＥＥをサポートする。すなわち、インタフェース１のバッファのトラフィック量を監視し、バッファ量に応じてインタフェース速度を調整、もしくは休止・復旧させる機能を有する（参考：非特許文献３）。

ＭＡＣ処理部（Media Access Control処理部）２は、インタフェース１から入力されたイーサネット（登録商標）フレームを、ＭＡＣテーブルに従って自装置あてのフレームか、他インタフェースへ転送されるフレームかを判断する。なお、ＭＡＣテーブルは、あるＭＡＣアドレスのホストは、どのインタフェースの先に存在するかをデータベース化したものである。

スイッチ部３は、ＭＡＣ処理部２から送られてきたイーサネット（登録商標）フレームを、適切なインタフェース１にスイッチングする機能を有する。

メモリバッファ部４は、スイッチング処理時に、フレームを一時的にストアする機能を有する。

スイッチ制御部５は、スイッチ部３を制御する機能を有する。

ＳＴＰ＆ＥＥＥ制御部６は、ＳＴＰ機能によりインタフェースの閉塞、および開放を制御する機能を有する。また、ＥＥＥ機能によりインタフェースの速度を調整、もしくは休止・復旧の制御機能を有する。また、ＳＴＰのConfiguration BPDU警報マスクの設定・解除を行う機能、およびＥＥＥ機能により休止されたインタフェースのリンク接続性を監視する機能を有する。

図２は、本発明の通信装置の処理フローチャートを示す。
ステップ１：動作を開始する。本装置は、レイヤ２スイッチとして動作している。

ステップ２：ＳＴＰ機能により、レイヤ２ネットワークにおいてツリーネットワークを構成する。ツリーネットワークの構成方法については、非特許文献１に従うこととする。ステップ３へ進む。

ステップ３：ＥＥＥ機能を開始する。これにより、トラフィック量に応じてインタフェースの速度変更、もしくは休止・復旧が実行可能な状態になる。ステップ４へ進む。

ステップ４：双方向のインタフェースのトラフィック量を監視する。このとき、ＳＴＰのConfiguration Bridge Protocol Data Unit（ＢＰＤＵ）のみが流れているインタフェースを確認する。なお、Configuration BPDUは、Configuration BPDUのHello Timeに記載されている時間間隔でパケットを授受することで、死活監視を行う機能である（参考：非特許文献１）。ここで、ＳＴＰのConfiguration BPDUの識別方法は次のように行う。インタフェースで受信したパケットをデコードし、ＳＴＰであるか否かを確認し、ＳＴＰである場合は、BPDU Message Typeを確認する。図３にＳＴＰのConfiguration BPDUの構造を示す。図３において、上から３番目のフィールド「BPDU Type」を確認し、BPDU Type=0の場合はConfiguration BPDUパケットであることの識別が可能である。Configuration BPDUのみが流れているインタフェースの場合、ステップ５へ進む。Configuration BPDUと他のトラフィックが混在しているインタフェースの場合、引き続きトラフィック量を監視する。ステップ４へ戻る。

ステップ５：Configuration BPDUが途絶状態となっても警報を送出させないために、ステップ４にて確認したインタフェースのConfiguration BPDU断に関する警報をマスクする。警報マスクを設定後、ステップ６へ進む。

ステップ６：ステップ４にて確認したインタフェースのConfiguration BPDUの授受を停止する。ステップ７へ進む。

ステップ７：ＥＥＥ機能を用いて、ステップ４にて確認したインタフェースを休止させる（インタフェース休止の手順は非特許文献３に従う）。インタフェース休止完了後、ステップ８へ進む。

ステップ８：ステップ４にて確認された休止インタフェースのリンク接続性を確認する。Configuration BPDUのHello Time設定時間よりも長い周期で、死活監視を実行する。監視パケットが受信できない場合は、リンク接続性に問題があるとする。接続性問題ＮＧの場合、ステップ９へ進む。接続性問題ＯＫの場合、ステップ１２へ進む。

ステップ９：ステップ８において、死活監視パケットが断状態となった場合、監視リンクに障害が発生したと見なす。ステップ１０へ進む。

ステップ１０：ステップ５にて設定したConfiguration BPDUの警報マスクを解除する。

ステップ１１：ＳＴＰ機能を用いて新たにツリーネットワークを構築する。ツリーネットワークの構成方法については、非特許文献１に従うこととする。なお、リンク障害箇所によっては、ツリー再構成後においても構成前のネットワークと変わらない場合がある。例えば、ツリーネットワークの先端部分のリンクが断状態になったとしても、ネットワーク構成は変更されない。ステップ４へ進む。

ステップ１２：インタフェースのトラフィック監視を行う。トラフィックがない場合、ステップ８へ戻る。トラフィックがある場合、ステップ１３へ進む。

ステップ１３：ＥＥＥ機能を用いてインタフェースを復旧させる。ステップ１４へ進む。

ステップ１４：Configuration BPDU機能を再開させ、Configuration BPDUの授受を行う。ステップ１５へ進む。

ステップ１５：ステップ５にて設定したConfiguration BPDU警報のマスクを解除する。マスク解除後、ステップ４へ戻る。

本発明の具体的な実施例を以下に説明する。本実施例では、図４のように、装置１〜３を用いてトライアングル型のネットワークを構築する。ここで、各装置は下記のように設定されているものとする。
装置１：ブリッジＩＤ＝１０
装置２：ブリッジＩＤ＝２０
装置３：ブリッジＩＤ＝３０
リンク１−２パスコスト＝１０
リンク１−３パスコスト＝２０
リンク２−３パスコスト＝３０

図４のネットワークは、図４（Ａ）に示すように物理的にはループとなっている。しかしながら、ＳＴＰ機能により、図４（Ｂ）に示すように装置３のリンク２−３側のインタフェースが閉塞され、論理的にはループがないネットワークが構成されている。

ＳＴＰ機能により論理的にはループがないネットワークが構成された後に、各装置インタフェースのＥＥＥ機能を開始する。

次に、各装置においてトラフィックの監視に移る。インタフェースのバッファに蓄積されたパケット量を監視することで、トラフィック量の増減を監視する。ここで、ＳＴＰのConfiguration BPDUのみが流れているインタフェースを確認する。Configuration BPDUのみが流れているインタフェースを検出した場合、そのインタフェースのConfiguration BPDUが途絶状態となっても警報を送出しないように、Configuration BPDU断に関する警報をマスクする。マスク設定後、Configuration BPDUの授受を停止し、次にインタフェースをＥＥＥ機能により休止させる。そのときの状態を図４（Ｃ）に示す。

インタフェースを休止後、そのインタフェースのリンク接続性を確認する。Configuration BPDUのHello Time設定時間よりも長い周期で、死活監視を実行する。休止させているインタフェースを定期的にＥＥＥ機能によりリンクがサポートする最低速度で復旧させ、リンクが確立することをもってリンクの接続性を確認する。リンクが確立しない場合は、リンクの接続性に問題が発生したとものと見なす。

リンクの接続性に問題がない場合は、インタフェースのトラフィックを監視する。トラフィックがない場合は、再度リンク接続性の確認を行う。トラフィックがある場合は、図４（Ｄ）のようにＥＥＥによりインタフェースを復旧させる。インタフェース復旧後、Configuration BPDU機能を再開させ、Configuration BPDUの授受を行う。次に、Configuration BPDU警報のマスクを解除することで、インタフェースの死活監視を行う。

一方、ＥＥＥ機能によりインタフェースが休止状態時に、図４（Ｅ）のように装置１と装置２間のリンクに切断といった障害が発生した場合を考える。この時、定期的にＥＥＥ機能を用いてリンクがサポートする最低速度でのリンク復旧を試行した際にリンクが確立しないため、リンク障害と判断できる。リンク障害と判断後、装置１と装置２は、設定していたConfiguration BPDUの警報マスクを解除し、ＳＴＰ機能を用いて閉塞していたポートを開放し、ネットワークを図４（Ｆ）のように構築する。

また、以上述べた実施形態は全て本発明を例示的に示すものであって限定的に示すものではなく、本発明は他の種々の変形態様および変更態様で実施することができる。従って本発明の範囲は特許請求の範囲およびその均等範囲によってのみ規定されるものである。

１インタフェース
２ＭＡＣ処理部
３スイッチ部
４メモリバッファ部
５スイッチ制御部
６ＳＴＰ＆ＥＥＥ制御部

Claims

ネットワーク内のループ構成を回避する回避機能および、インタフェースを休止および復旧させる休止機能を備えた通信装置において、
前記回避機能のフレームのみを一定時間以上送受信しているインタフェースに対して、該フレーム断の検出機能をマスクする手段と、
前記インタフェースを前記休止機能により休止させる手段と、
前記回避機能のフレーム以外のパケットを前記インタフェースのバッファにて検出した場合に、前記休止機能により前記インタフェースを復旧させる手段と、
前記休止機能により前記インタフェースを復旧させた場合に、前記フレーム断の検出機能のマスクを解除する手段と、
を備えることを特徴とする通信装置。
前記フレーム断の検出機能のマスクを行った後、前記回避機能のフレームの送受信を停止させる手段と、
前記フレーム断の検出機能のマスク解除を行った後、前記回避機能のフレームの送受信を開始させる手段と、
をさらに備えることを特徴とする請求項１に記載の通信装置。
前記休止機能により休止されたインタフェースに対して、リンクの確立が成功するか否かで死活監視を実行する監視手段をさらに備えることを特徴とする請求項１または２に記載の通信装置。
前記回避機能はＳＴＰ（Spanning Tree Protocol）機能であり、前記休止機能はＥＥＥ（Energy Efficient Ethernet）機能であり、前記回避機能のフレームは、Configuration BPDUであることを特徴とする請求項１から３のいずれか１項に記載の通信装置。
前記監視手段は、ＥＥＥ機能により休止されたインタフェースに対して、Configuration BPDUのHello Time設定時間間隔よりも長い周期で、ＥＥＥ機能を用いてリンクの確立が成功するか否かで死活監視を実行する手段であることを特徴とする請求項３に記載の通信装置。