JP2004194202A - Link connectivity confirmation method and program, and Ethernet (registered trademark) device having link connectivity confirmation function - Google Patents
Link connectivity confirmation method and program, and Ethernet (registered trademark) device having link connectivity confirmation function Download PDFInfo
- Publication number
- JP2004194202A JP2004194202A JP2002362480A JP2002362480A JP2004194202A JP 2004194202 A JP2004194202 A JP 2004194202A JP 2002362480 A JP2002362480 A JP 2002362480A JP 2002362480 A JP2002362480 A JP 2002362480A JP 2004194202 A JP2004194202 A JP 2004194202A
- Authority
- JP
- Japan
- Prior art keywords
- message
- ethernet
- link
- identification information
- registered
- 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.)
- Pending
Links
Images
Landscapes
- Small-Scale Networks (AREA)
Abstract
【課題】対向装置の台数やメッセージの送信間隔に関する制約の少ないリンク接続性確認を可能にする。
【解決手段】一方のイーサネット（登録商標）装置が、送信元識別情報を含む接続確認メッセージを定期的に送信する手順を含み、他方のイーサネット（登録商標）装置が、接続確認メッセージを受信して送信元識別情報を抽出する手順と、抽出した送信元識別情報をメッセージの到達時刻情報と共にアドレステーブルへ登録する手順と、アドレステーブルに既登録の送信元識別情報を含むメッセージを受信すると、当該リンクに関して既登録の到達時刻情報を更新する手順と、到達時刻情報に基づいてメッセージの受信状況をリンクごとに判別し、メッセージ受信が所定時間以上途切れたリンクの登録を前記アドレステーブルから抹消する手順とを含む。
【選択図】 図４An object of the present invention is to confirm link connectivity with less restrictions on the number of opposing devices and message transmission intervals.
An Ethernet (registered trademark) device includes a procedure for periodically transmitting a connection confirmation message including transmission source identification information, and the other Ethernet (registered trademark) device receives the connection confirmation message. The procedure for extracting the sender identification information, the procedure for registering the extracted sender identification information together with the arrival time information of the message in the address table, and the step of receiving the message including the sender identification information already registered in the address table, A procedure of updating the registered arrival time information with respect to the message, determining a message reception status for each link based on the arrival time information, and deleting the registration of the link in which the message reception is interrupted for a predetermined time or more from the address table. including.
[Selection diagram] Fig. 4
Description
【０００１】
【発明の属する技術分野】
本発明は、イーサネット（登録商標）ネットワークにおいて、対向するイーサネット（登録商標）装置間でリンクの接続性を確認するリンク接続性確認方法およびプログラムならびにリンク接続性確認機能を備えたイーサネット（登録商標）装置に係り、特に、複数のリンクに関して同時に接続を確認できるリンク接続性確認方法およびプログラムならびにリンク接続性確認機能を備えたイーサネット（登録商標）装置に関する。
【０００２】
【従来の技術】
IEEE Std 802.3, 2000 Edition (第43章 Link Aggregation)では、イーサネット（登録商標）装置間で低速なリンクを自動的に集約して一つに見せる（トランキング）ために必要なプロトコルとしてLACP(Link Aggregation Control Protocol)が定義されており、このプロトコルにはリンクの接続性確認機能が含まれる。
【０００３】
図５は、従来のLACPにおけるリンクの接続性確認手順を示したブロック図であり、装置A、BはIEEE 802.3で規定するイーサネット（登録商標）インタフェースを持つイーサネット（登録商標）装置である。イーサネット（登録商標）装置Aの1つのイーサネット（登録商標）インタフェースと装置Bの1つのイーサネット（登録商標）インタフェースとが接続され、ここではインタフェースの物理アドレス(MACアドレス)をそれぞれMa、Mbとする。
【０００４】
LACPでは、LACPメッセージの送信者をアクター、受信者をパートナーと呼び、アクターは定期的にLACPメッセージを送出する。図５では、イーサネット（登録商標）装置Aをアクター、イーサネット（登録商標）装置Bをパートナーとしているが、実際にはイーサネット（登録商標）装置BからもLACPメッセージは送出されており、どちらの装置もアクターであり、かつパートナーである。
【０００５】
LACPメッセージの宛先アドレスとしては、リンク制限付きマルチキャストアドレスが利用され、特定のインタフェースのMACアドレスが指定されるわけではない。この場合、送信元インタフェースと直接接続されたインタフェース(図５の例ではイーサネット（登録商標）装置BのアドレスMb)がLACPメッセージを受信することになる。
【０００６】
LACPメッセージには、アクター情報とパートナー情報とが含まれ、LACPメッセージを受信したパートナーは、メッセージ内のアクター情報からメッセージ送信者を判別し、また同一のアクターから一定期間LACPメッセージを受信しなかった場合に、該当するアクターとの接続が切断されたと判断する。
【０００７】
アクターにおけるLACPメッセージの送信間隔としては、ショートタイムアウトおよびロングタイムアウトの2種類が規定されており、時間はそれぞれ1秒、30秒である。ショートタイムアウトおよびロングタイムアウトのいずれを利用するかはパートナーが選択する。また、パートナーにおけるLACPメッセージの受信タイムアウト値は、メッセージ送信間隔の3倍と規定されているので、ショートタイムアウト利用時には3秒、ロングタイムアウト利用時には90秒となる。
【０００８】
【発明が解決しようとする課題】
従来のLACPには以下のような技術課題があり、リンク接続性確認の機能に関して不十分な点があった。
【０００９】
第１に、LACPはリンク集約化のために利用するプロトコルであるために、リンク集約化が必要ない場合の利用が考慮されていない。
【００１０】
第２に、メッセージ送信間隔およびメッセージ受信タイムアウト値の設定が、ショートタイムアウト、ロングタイムアウトの2種類に限定されており、柔軟性に欠ける。
【００１１】
第３に、メッセージ送信間隔の最小値が1秒であるために、より高速処理が必要な場合に対応できない。
【００１２】
第４に、アクターとパートナーとの関係が1対1に限られ、1対Nすなわちパートナーが複数存在する場合が考慮されていない。
【００１３】
本発明の目的は、上記した従来技術の課題を解決し、対向装置の台数やメッセージの送信間隔等に関する制約の少ないリンク接続性確認を可能にしたイーサネット（登録商標）装置用のリンク接続性確認方法およびプログラムならびにリンク接続性確認機能を備えたイーサネット（登録商標）装置を提供することにある。
【００１４】
【課題を解決するための手段】
上記した目的を達成するために、本発明は、相互に対向するイーサネット（登録商標）装置間でリンクの接続性を確認するリンク接続性確認方法において、一方のイーサネット（登録商標）装置および他方のイーサネット（登録商標）装置が、それぞれ以下のような手順を実行することを特徴とする。
(1)一方のイーサネット（登録商標）装置が、自身に固有の送信元識別情報を含む接続確認メッセージを定期的に送信する手順を実行すること。
(2)他方のイーサネット（登録商標）装置が、前記一方のイーサネット（登録商標）装置から送信された接続確認メッセージを受信する手順と、前記メッセージに含まれる送信元識別情報を抽出する手順と、前記抽出した送信元識別情報を、前記メッセージの到達時刻情報と共にアドレステーブルへ登録する手順と、前記アドレステーブルに既登録の送信元識別情報を含むメッセージを受信すると、当該リンクに関して既登録の到達時刻情報を更新する手順と、前記到達時刻情報に基づいて、前記メッセージの受信状況をリンクごとに判別する手順と、メッセージ受信が所定時間以上途切れたリンクの登録を前記アドレステーブルから抹消する手順とを実行し、アドレステーブルでの送信元識別情報の登録の有無に基づいて、前記一方のイーサネット（登録商標）装置との接続性を確認すること。
【００１５】
上記した特徴によれば、対向するイーサネット（登録商標）装置から接続確認メッセージを受信すると、このメッセージに登録されている、前記イーサネット（登録商標）装置に固有の識別情報が当該メッセージの到着時刻情報と共にアドレステーブルにエントリとして登録される一方、その後、メッセージの受信が所定時間以上途切れると、当該メッセージに関するエントリがアドレステーブルから抹消される。したがって、アドレステーブルを参照するだけで、対向する複数のイーサネット（登録商標）装置との接続性を確認できるようになる。
【００１６】
【発明の実施の形態】
以下、図面を参照して本発明の好ましい実施の形態について詳細に説明する。図１は、本発明を適用したイーサネット（登録商標）装置によるリンク接続性確認機能を示したブロック図である。
【００１７】
イーサネット（登録商標）装置A、Bは、IEEE 802.3で規定するイーサネット（登録商標）インタフェースを備え、以下に詳述するBNDP(Bridge Neighbor Discovery Protocol)をサポートして、同じくBNDPをサポートする他のイーサネット（登録商標）装置との間でインタフェース情報の交換および接続性の確認を行う。各イーサネット（登録商標）装置A、Bは、後に詳述するアドレステーブル１ａ，１ｂおよび任意に設定可能な各種のタイマ２ａ〜４ａ，２ｂ〜４ｂを具備している。
【００１８】
イーサネット（登録商標）装置Aの１つのイーサネット（登録商標）インタフェースとイーサネット（登録商標）装置Bの１つのイーサネット（登録商標）インタフェースとが接続され、ここでは、各インタフェースの物理アドレス(MACアドレス)をそれぞれMa、Mbとする。
【００１９】
BNDPでは、BNDPメッセージの送信者をアクター、受信者をパートナーと呼び、アクターは、自身のデバイス識別子と、接続に使用しているポート識別子とを含むBNDPメッセージを定期的に送出する。BNDPメッセージの送信元アドレスおよび宛先アドレスは、それぞれアクターのMACアドレスおよびリンク制限付きマルチキャストアドレスである。
【００２０】
本実施形態では、宛先アドレスとしてリンク制限付きマルチキャストアドレスを使用することにより、接続先の物理アドレスを事前に確認しなくてもメッセージの送出が可能になるのみならず、BNDPを解釈しないブリッジにおいては透過的にメッセージを通過させることが可能になる。
【００２１】
図２は、前記アドレステーブル１ａ，１ｂの一例を示した図であり、パートナーとして機能するイーサネット（登録商標）装置は、アクターから受信したBNDPメッセージに含まれる送信元識別情報としてのデバイス識別子IDdおよびポート識別子IDpを抽出し、これをエントリとして前記アドレステーブルに登録すると共に、各エントリに固有の経過時間タイマTageをスタートさせる。
【００２２】
次いで、前記BNDPについて詳細について説明する。本実施形態ではBNDPが以下の4つの状態を取り得る。
【００２３】
(1)disabled状態：
イーサネット（登録商標）インタフェースが利用不可である状態。
(2)blocking状態：
イーサネット（登録商標）インタフェースが利用可能となった状態。ただし、BNDPメッセージの受信のみが行われ、フレーム送信およびBNDPメッセージ以外のフレーム受信は行われない。
(3)listening状態：
イーサネット（登録商標）インタフェースにおいて、BNDPメッセージの送受信のみが行われる状態。BNDPメッセージは一定間隔(hellotime)で送信される。一般フレームの送受信は行われない。
(4)forwarding状態：
イーサネット（登録商標）インタフェースにおいて、BNDPメッセージの送受信および一般フレームの送受信が行われる状態。BNDPメッセージは、前記hellotimeタイマ２ａ，２ｂに登録された一定間隔(hellotime)周期で送信される。
【００２４】
図３は、上記した各状態の遷移図であり、disable状態でイーサネット（登録商標）インタフェースが利用可能になるとblocking状態へ移行する［▲１▼］。blocking状態では、BNDPメッセージを受信するか、あるいは blocking状態となってから前記maxageタイマ３ａ，３ｂに登録された一定時間(maxage)が経過するとlistening状態へ移行する［▲２▼］。 listening状態では、前記forward delayタイマ４ａ，４ｂに登録された一定時間(forward delay)の経過後にforwarding状態へ移行する［▲３▼］。ここでforward delay≧maxageとする。blocking、listening、forwarding状態では「リンク接続性確認処理」が実行される。
【００２５】
図４は、前記「リンク接続性確認処理」の動作を示したフローチャートであり、ステップＳ１では、BNDPメッセージの受信の有無が判断され、BNDPメッセージの受信が検知されると、ステップＳ２において、当該メッセージに登録されている送信元のデバイス識別子IDdおよびポート識別子IDpが抽出される。ステップＳ３では、前記抽出したデバイス識別子IDdとポート識別子IDpとの組み合わせが、前記アドレステーブルに既登録であるか否かが判定される。
【００２６】
未登録であればステップＳ４へ進み、前記デバイス識別子IDdとポート識別子IDpとの組み合わせがアドレステーブルに記憶され、その経過時間タイマTageがスタートする。前記デバイス識別子IDdとポート識別子IDpとの組み合わせがアドレステーブルに既登録であればステップＳ５へ進み、対応するエントリのタイマTageがリセット（０→Tage）される。すなわち、タイマTageが更新される。
【００２７】
前記ステップＳ１において、BNDPメッセージの受信が検知されていなければステップＳ６へ進み、前記アドレステーブルに登録されている各エントリのタイマTageが参照される。ここで、タイマTageが所定の基準時間Tref（＝maxage）を超えるエントリが有ればステップＳ７へ進み、当該エントリがアドレステーブルから抹消される。この結果、アドレステーブルには、BNDPメッセージが最後に受信されてからの経過時間が基準時間Trefよりも短いエントリのみが残るので、アドレステーブルに既登録のエントリであればリンク接続が保持されていることになる。
【００２８】
図３へ戻り、上記したようにlisteningまたはforwarding状態において、アドレステーブルの中身が空(すべての接続先デバイスがmaxage超過)になるとblocking状態へ移行する[▲４▼]。ここでmaxage＞hellotimeとする。
【００２９】
blocking、listeningまたはforwarding状態において、対応するイーサネット（登録商標）インタフェースが利用不可となるとdesabled状態へ移行する[▲５▼]。前記各種タイマー(hellotime、maxage、forward delay)はミリ秒オーダーで任意に設定が可能である。
【００３０】
このように、本実施形態ではイーサネット（登録商標）装置にアドレステーブルを設け、BNDPメッセージを新規に受信すると、このメッセージに登録されている送信元識別情報を抽出して到着時刻と共にアドレステーブルに登録する一方、アドレステーブルに既登録のメッセージを受信すると、そのエントリの到着時刻を更新するので、アドレステーブルを参照するだけで、複数のリンクに関して個々の接続確認が可能になる。
【００３１】
さらに、本実施形態によれば、BNDPメッセージの送信間隔(hellotime）、リンク接続性確認の判断基準（maxage）等のパラメータを任意に設定できるので、用途に合わせたリンク接続性確認が可能になる。
【００３２】
【本発明の効果】
本発明によれば、以下のような効果が達成される。
(1)イーサネット（登録商標）装置にアドレステーブルを設け、BNDPメッセージを新規に受信すると、このメッセージに登録されている送信元識別情報を抽出して到着時刻と共にアドレステーブルに登録する一方、アドレステーブルに既登録のメッセージを受信すると、そのエントリの到着時刻を更新するので、アドレステーブルを参照するだけで、複数のリンクに関して個々の接続確認が可能になる。
(2)BNDPメッセージの送信間隔やリンク接続性確認の判断基準等のパラメータをを任意に設定できるので、用途に合わせたリンク接続性確認が可能になる。
【図面の簡単な説明】
【図１】本発明の一実施形態であるイーサネット（登録商標）装置によるリンク接続性確認機能を示したブロック図である。
【図２】アドレステーブルの一例を示した図である。
【図３】イーサネット（登録商標）装置がサポートするBNDPの状態遷移図である。
【図４】BNDPにおけるリンク接続確認手順のフローチャートである。
【図５】従来のLACPにおけるリンクの接続性確認手順を示したブロック図である。
【符号の説明】１ａ，１ｂ…アドレステーブル、２ａ，２ｂ…hellotimeタイマ、３ａ，３ｂ…maxage、タイマ４ａ，４ｂ…forward delay[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a link connectivity confirmation method and program for confirming link connectivity between opposing Ethernet (registered trademark) devices in an Ethernet (registered trademark) network, and an Ethernet (registered trademark) provided with a link connectivity confirmation function. The present invention relates to a device, and more particularly to a link connectivity confirmation method and a program capable of confirming connections for a plurality of links simultaneously, and an Ethernet (registered trademark) device having a link connectivity confirmation function.
[0002]
[Prior art]
In IEEE Std 802.3, 2000 Edition (Chapter 43, Link Aggregation), LACP (Link Aggregation) is a protocol required to automatically aggregate low-speed links between Ethernet (registered trademark) devices and show them together (trunking). Aggregation Control Protocol) is defined, and this protocol includes a link connectivity check function.
[0003]
FIG. 5 is a block diagram showing a procedure for confirming link connectivity in a conventional LACP. Devices A and B are Ethernet (registered trademark) devices having an Ethernet (registered trademark) interface defined by IEEE 802.3. One Ethernet (registered trademark) interface of the Ethernet (registered trademark) device A and one Ethernet (registered trademark) interface of the device B are connected, and the physical addresses (MAC addresses) of the interfaces are Ma and Mb, respectively. .
[0004]
In LACP, the sender of an LACP message is called an actor and the recipient is called a partner, and the actor sends out the LACP message periodically. In FIG. 5, the Ethernet (registered trademark) device A is an actor, and the Ethernet (registered trademark) device B is a partner. However, the LACP message is actually transmitted from the Ethernet (registered trademark) device B. Are actors and partners.
[0005]
As the destination address of the LACP message, a multicast address with link restriction is used, and the MAC address of a specific interface is not specified. In this case, the interface (the address Mb of the Ethernet (registered trademark) device B in the example of FIG. 5) directly connected to the transmission source interface receives the LACP message.
[0006]
The LACP message contains actor information and partner information, and the partner who received the LACP message determined the message sender from the actor information in the message, and did not receive the LACP message from the same actor for a certain period of time In this case, it is determined that the connection with the corresponding actor has been disconnected.
[0007]
As the transmission interval of the LACP message in the actor, two types of short timeout and long timeout are defined, and the times are 1 second and 30 seconds, respectively. The partner selects whether to use the short timeout or the long timeout. Further, since the reception timeout value of the LACP message at the partner is specified to be three times the message transmission interval, it is 3 seconds when using the short timeout and 90 seconds when using the long timeout.
[0008]
[Problems to be solved by the invention]
The conventional LACP has the following technical problems, and there is an insufficient point regarding the function of link connectivity confirmation.
[0009]
First, since LACP is a protocol used for link aggregation, its use when link aggregation is not required is not considered.
[0010]
Second, the setting of the message transmission interval and the message reception timeout value is limited to two types, short timeout and long timeout, and lacks flexibility.
[0011]
Third, since the minimum value of the message transmission interval is 1 second, it cannot cope with a case where higher speed processing is required.
[0012]
Fourth, the relationship between actors and partners is limited to one-to-one, and one-to-N, that is, the case where there are multiple partners is not considered.
[0013]
SUMMARY OF THE INVENTION It is an object of the present invention to solve the above-mentioned problems of the prior art and to confirm link connectivity for an Ethernet (registered trademark) device, which enables confirmation of link connectivity with less restrictions on the number of opposing devices, message transmission intervals and the like. An object of the present invention is to provide an Ethernet (registered trademark) device having a method and a program and a link connectivity confirmation function.
[0014]
[Means for Solving the Problems]
In order to achieve the above object, the present invention provides a link connectivity confirmation method for confirming the connectivity of a link between mutually opposed Ethernet (registered trademark) devices. Each of the Ethernet (registered trademark) devices executes the following procedure.
(1) One Ethernet (registered trademark) device executes a procedure for periodically transmitting a connection confirmation message including transmission source identification information unique to itself.
(2) a procedure in which the other Ethernet (registered trademark) apparatus receives the connection confirmation message transmitted from the one Ethernet (registered trademark) apparatus, a procedure in which transmission source identification information included in the message is extracted, Registering the extracted transmission source identification information in the address table together with the arrival time information of the message, and receiving a message including the transmission source identification information registered in the address table; A step of updating information, a step of determining the reception status of the message for each link based on the arrival time information, and a step of deleting from the address table the registration of a link in which message reception has been interrupted for a predetermined time or more. And executes the one Ethernet based on whether or not the sender identification information is registered in the address table. Tsu door (registered trademark) to check the connectivity with the device.
[0015]
According to the above feature, when a connection confirmation message is received from the opposite Ethernet (registered trademark) device, the identification information unique to the Ethernet (registered trademark) registered in this message is the arrival time information of the message. When the reception of the message is interrupted for a predetermined time or more after that, the entry relating to the message is deleted from the address table. Therefore, it is possible to confirm the connectivity with a plurality of opposing Ethernet (registered trademark) devices only by referring to the address table.
[0016]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 is a block diagram showing a link connectivity confirmation function by an Ethernet (registered trademark) device to which the present invention is applied.
[0017]
The Ethernet (registered trademark) devices A and B have an Ethernet (registered trademark) interface defined by IEEE 802.3, and support the Bridge Neighbor Discovery Protocol (BNDP) described in detail below, and other Ethernets that also support BNDP. Exchanges interface information with a (registered trademark) device and checks connectivity. Each of the Ethernet (registered trademark) devices A and B is provided with address tables 1a and 1b, which will be described in detail later, and various timers 2a to 4a and 2b to 4b that can be arbitrarily set.
[0018]
One Ethernet (registered trademark) interface of the Ethernet (registered trademark) device A is connected to one Ethernet (registered trademark) interface of the Ethernet (registered trademark) device B. Here, a physical address (MAC address) of each interface is connected. Are Ma and Mb, respectively.
[0019]
In BNDP, the sender of a BNDP message is called an actor and the recipient is called a partner, and the actor periodically sends out a BNDP message including its own device identifier and the port identifier used for connection. The source address and destination address of the BNDP message are the actor's MAC address and the link-restricted multicast address, respectively.
[0020]
In the present embodiment, by using a link-limited multicast address as the destination address, not only can the message be transmitted without confirming the physical address of the connection destination in advance, but also in a bridge that does not interpret BNDP, This allows messages to pass through transparently.
[0021]
FIG. 2 is a diagram showing an example of the address tables 1a and 1b. An Ethernet (registered trademark) device functioning as a partner includes a device identifier IDd as transmission source identification information included in a BNDP message received from an actor. The port identifier IDp is extracted and registered as an entry in the address table, and an elapsed time timer Tage unique to each entry is started.
[0022]
Next, the BNDP will be described in detail. In this embodiment, the BNDP can take the following four states.
[0023]
(1) disabled state:
A state where the Ethernet interface is unavailable.
(2) blocking state:
The state in which the Ethernet (registered trademark) interface is available. However, only reception of the BNDP message is performed, and frame transmission and frame reception other than the BNDP message are not performed.
(3) listening state:
A state in which only transmission and reception of BNDP messages are performed in the Ethernet (registered trademark) interface. The BNDP message is transmitted at regular intervals (hellotime). No transmission / reception of general frames is performed.
(4) Forwarding status:
A state in which transmission and reception of BNDP messages and transmission and reception of general frames are performed in the Ethernet (registered trademark) interface. The BNDP message is transmitted at regular intervals (hellotime) cycles registered in the hellotime timers 2a and 2b.
[0024]
FIG. 3 is a transition diagram of each state described above. When the Ethernet (registered trademark) interface becomes available in the disable state, the state shifts to the blocking state [1]. In the blocking state, the state shifts to the listening state when a certain time (maxage) registered in the
[0025]
FIG. 4 is a flowchart showing the operation of the "link connectivity confirmation process". In step S1, it is determined whether or not a BNDP message has been received. When the reception of a BNDP message is detected, the process proceeds to step S2. The device identifier IDd and the port identifier IDp of the transmission source registered in the message are extracted. In step S3, it is determined whether or not the combination of the extracted device identifier IDd and port identifier IDp is already registered in the address table.
[0026]
If not registered, the process proceeds to step S4, where the combination of the device identifier IDd and the port identifier IDp is stored in the address table, and the elapsed time timer Tage starts. If the combination of the device identifier IDd and the port identifier IDp has already been registered in the address table, the process proceeds to step S5, and the timer Tage of the corresponding entry is reset (0 → Tage). That is, the timer Tage is updated.
[0027]
In step S1, if the reception of the BNDP message is not detected, the process proceeds to step S6, and the timer Tage of each entry registered in the address table is referred to. Here, if there is an entry whose timer Tage exceeds a predetermined reference time Tref (= maxage), the process proceeds to step S7, and the entry is deleted from the address table. As a result, only entries whose elapsed time since the last reception of the BNDP message is shorter than the reference time Tref remain in the address table. Therefore, if the entry is already registered in the address table, the link connection is held. Will be.
[0028]
Returning to FIG. 3, when the contents of the address table become empty (all connected devices exceed maxage) in the listening or forwarding state as described above, the state shifts to the blocking state [4]. Here, it is assumed that maxage> hellotime.
[0029]
In the blocking, listening, or forwarding state, when the corresponding Ethernet (registered trademark) interface becomes unavailable, the state shifts to the disabled state [5]. The various timers (hellotime, maxage, forward delay) can be arbitrarily set on the order of milliseconds.
[0030]
As described above, in the present embodiment, the address table is provided in the Ethernet (registered trademark) device, and when a BNDP message is newly received, the sender identification information registered in this message is extracted and registered in the address table together with the arrival time. On the other hand, when a message already registered in the address table is received, the arrival time of the entry is updated, so that it is possible to confirm individual connections for a plurality of links only by referring to the address table.
[0031]
Furthermore, according to the present embodiment, parameters such as the transmission interval (hellotime) of the BNDP message and the criterion (maxage) for determining the link connectivity can be arbitrarily set, so that the link connectivity can be confirmed according to the application. .
[0032]
[Effects of the present invention]
According to the present invention, the following effects are achieved.
(1) An address table is provided in the Ethernet (registered trademark) device, and when a BNDP message is newly received, the sender identification information registered in this message is extracted and registered in the address table together with the arrival time, while the address table is When an already registered message is received, the arrival time of the entry is updated, so that individual connections can be confirmed for a plurality of links only by referring to the address table.
(2) Since parameters such as the transmission interval of the BNDP message and the criterion for determining the link connectivity can be arbitrarily set, the link connectivity can be confirmed according to the intended use.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a link connectivity confirmation function of an Ethernet (registered trademark) device according to an embodiment of the present invention.
FIG. 2 is a diagram showing an example of an address table.
FIG. 3 is a state transition diagram of BNDP supported by the Ethernet (registered trademark) device.
FIG. 4 is a flowchart of a link connection confirmation procedure in BNDP.
FIG. 5 is a block diagram showing a procedure for confirming link connectivity in a conventional LACP.
[Description of Signs] 1a, 1b: address table, 2a, 2b: hellotime timer, 3a, 3b: maxage,
Claims (9)
一方のイーサネット（登録商標）装置が、
自身に固有の送信元識別情報を含む接続確認メッセージを定期的に送信する手順を含み、
他方のイーサネット（登録商標）装置が、
前記一方のイーサネット（登録商標）装置から送信された接続確認メッセージを受信する手順と、
前記メッセージに含まれる送信元識別情報を抽出する手順と、
前記送信元識別情報がアドレステーブルに未登録であれば、これを前記メッセージの到達時刻情報と共にアドレステーブルへ登録する手順と、
前記送信元識別情報がアドレステーブルに既登録であれば、当該リンクに関して既登録の到達時刻情報を更新する手順と、
前記到達時刻情報に基づいて、前記メッセージの受信状況をリンクごとに判別する手順と、
メッセージ受信が所定時間以上途切れたリンクの登録を前記アドレステーブルから抹消する手順とを含み、
前記アドレステーブルでの送信元識別情報の登録の有無に基づいて、前記一方のイーサネット（登録商標）装置との接続性を確認することを特徴とするリンク接続性確認方法。In a link connectivity confirmation method for confirming link connectivity between opposed Ethernet (registered trademark) devices,
One Ethernet device is
Includes a procedure to periodically send a connection confirmation message that contains its own unique sender identification information,
The other Ethernet device is
Receiving a connection confirmation message transmitted from the one Ethernet (registered trademark) device;
Extracting source identification information included in the message,
If the transmission source identification information is not registered in the address table, registering it in the address table together with the arrival time information of the message;
If the transmission source identification information is already registered in the address table, updating the registered arrival time information for the link;
Based on the arrival time information, determining the reception status of the message for each link,
Deleting from the address table the registration of the link where the message reception is interrupted for a predetermined time or more,
A link connectivity confirmation method comprising: confirming connectivity with the one Ethernet (registered trademark) device based on whether or not transmission source identification information is registered in the address table.
接続確認メッセージの送信手順および受信手順を含み、
前記送信手順は、
自身に固有の送信元識別情報を含む接続確認メッセージを定期的に送信する手順を含み、
前記受信手順は、
他のイーサネット（登録商標）装置から送信された接続確認メッセージを受信する手順と、
前記メッセージに含まれる送信元識別情報を抽出する手順と、
前記送信元識別情報がアドレステーブルに未登録であれば、これを前記メッセージの到達時刻情報と共にアドレステーブルへ登録する手順と、
前記送信元識別情報がアドレステーブルに既登録であれば、当該リンクに関して既登録の到達時刻情報を更新する手順と、
前記到達時刻情報に基づいて、前記メッセージの受信状況をリンクごとに判別する手順と、
メッセージ受信が所定時間以上途切れたリンクの登録を前記アドレステーブルから抹消する手順とを含み、
前記アドレステーブルでの送信元識別情報の登録の有無に基づいて、対向装置との接続性を確認することを特徴とするリンク接続性確認プログラム。A link connectivity check program mounted on the Ethernet (registered trademark) device and configured to check link connectivity between at least one opposed Ethernet (registered trademark) device,
Including the procedure for sending and receiving the connection confirmation message,
The transmission procedure includes:
Includes a procedure to periodically send a connection confirmation message that contains its own unique sender identification information,
The receiving procedure includes:
Receiving a connection confirmation message transmitted from another Ethernet (registered trademark) device,
Extracting source identification information included in the message,
If the transmission source identification information is not registered in the address table, registering it in the address table together with the arrival time information of the message;
If the transmission source identification information is already registered in the address table, updating the registered arrival time information for the link;
Based on the arrival time information, determining the reception status of the message for each link,
Deleting from the address table the registration of the link where the message reception is interrupted for a predetermined time or more,
A link connectivity confirmation program for confirming connectivity with a partner device based on whether or not transmission source identification information is registered in the address table.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002362480A JP2004194202A (en) | 2002-12-13 | 2002-12-13 | Link connectivity confirmation method and program, and Ethernet (registered trademark) device having link connectivity confirmation function |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002362480A JP2004194202A (en) | 2002-12-13 | 2002-12-13 | Link connectivity confirmation method and program, and Ethernet (registered trademark) device having link connectivity confirmation function |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004194202A true JP2004194202A (en) | 2004-07-08 |
Family
ID=32760916
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002362480A Pending JP2004194202A (en) | 2002-12-13 | 2002-12-13 | Link connectivity confirmation method and program, and Ethernet (registered trademark) device having link connectivity confirmation function |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004194202A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011512059A (en) * | 2008-01-14 | 2011-04-14 | アルカテル−ルーセント | Method and system for connectivity check of Ethernet multicast |
| CN102687466A (en) * | 2010-01-04 | 2012-09-19 | 阿尔卡特朗讯 | Neighbor discovery for Ethernet private line on user network interfaces |
-
2002
- 2002-12-13 JP JP2002362480A patent/JP2004194202A/en active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011512059A (en) * | 2008-01-14 | 2011-04-14 | アルカテル−ルーセント | Method and system for connectivity check of Ethernet multicast |
| CN102687466A (en) * | 2010-01-04 | 2012-09-19 | 阿尔卡特朗讯 | Neighbor discovery for Ethernet private line on user network interfaces |
| JP2013516822A (en) * | 2010-01-04 | 2013-05-13 | アルカテル−ルーセント | Neighbor discovery for Ethernet private lines on user network interfaces |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6202114B1 (en) | Spanning tree with fast link-failure convergence | |
| JP4897884B2 (en) | ZIGBEE / IP gateway | |
| CN105144645B (en) | Spanning tree in fabric switch | |
| CN102415054B (en) | Node device and communication method | |
| JP2003218901A (en) | Frame relay system, frame relay device, relay device, and network | |
| US6061728A (en) | Arrangement for controlling network proxy device traffic on a transparently-bridged local area network using a master proxy device | |
| US7733810B2 (en) | System and method for communicating on a virtual ring in an internet protocol network | |
| US8811190B2 (en) | Maximum transmission unit (MTU) size discovery mechanism and method for data-link layers | |
| CN106790104A (en) | IP communications and the communication means of FC AE 1553 between multi-protocols emerging system, node | |
| CN105103502B (en) | For the method for the node device of configuration mesh communication network, computer program, information-storing device and system | |
| JPH0821924B2 (en) | Data communication network | |
| CN112671642A (en) | Message forwarding method and device | |
| JP2006340361A (en) | How to determine the home network connection topology | |
| JPH088975A (en) | Local area network interconnected system and device | |
| CN108989218B (en) | Data forwarding device and method based on network convergence architecture | |
| US5694543A (en) | Polling substitution system for performing polling communications within a computer network | |
| CN101019380B (en) | Systems and methods for accelerated learning in ring networks | |
| CN100593927C (en) | Cluster systems, cluster members, and programs | |
| CN104184667B (en) | Flux of multicast moving method and device in a kind of SPB network of M in M-modes | |
| CN102710500A (en) | Method for processing conflict of identifiers of device groups in network, and route bridge | |
| WO2019196853A1 (en) | Tcp acceleration method and apparatus | |
| JP2004194202A (en) | Link connectivity confirmation method and program, and Ethernet (registered trademark) device having link connectivity confirmation function | |
| CN117061414A (en) | Maintaining a link set associated with a link aggregation group to support client edge devices | |
| CN113452543B (en) | Detection of multi-host misconfiguration | |
| CN106034078B (en) | A method and system for reducing DR variation of PIM protocol |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040922 |
|
| A977 | Report on retrieval |
Effective date: 20061016 Free format text: JAPANESE INTERMEDIATE CODE: A971007 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061018 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061215 |
|
| A02 | Decision of refusal |
Effective date: 20070322 Free format text: JAPANESE INTERMEDIATE CODE: A02 |