(57)【特許請求の範囲】
【請求項１】
少なくともエラー報告機能、経路記録機能、およびコネクションレス型ネットワークプロトコル（ＣＬＮＰ）エコー機能を含む開放型システム間相互接続（ＯＳＩ）スタックのＣＬＮＰ機能をサポートする要求システムが実行する、宛先システムをピングする方法であって、要求システムが、
ａ）エラー報告機能を使用可能にし、
ｂ）経路記録機能を使用可能にし、
ｃ）ＣＬＮＰエコー要求ＰＤＵ（プロトコル  データ  ユニット）を発行し、
ｄ）要求システムが応答を受取らない場合に「ＦＡＩＬ」を報告し、
ｅ）要求システムが正確な応答を宛先システムから受取った場合に「ＳＵＣＣＥＳＳ」を報告し、
ｆ）要求システムが正確な応答を宛先システムから受取らない場合に、経路記録機能およびエラー報告機能によって提供された情報を説明するＣＬＮＰエコー要求ＰＤＵの結果を分析する段階を含む方法。
【請求項２】
ＣＬＮＰエコー要求ＰＤＵの結果の分析において、要求システムが、応答が宛先システムからのものであることを経路記録機能によって確認した場合、また宛先システムがＣＬＮＰエコー機能をサポートしていないことをエラー報告機能によって確認した場合に、要求システムは「ＳＵＣＣＥＳＳ」を報告し、そうでない場合には「ＦＡＩＬ、ＩＮＴＥＲＭＥＤＩＡＴＥ  ＳＹＳＴＥＭ」を報告する、請求項１に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、任意のＯＳＩ（ＯＰＥＮ  ＳＹＳＴＥＭＳ  ＩＮＴＥＲＣＯＮＮＥＣＴ／開放型システム間相互接続）準拠通信管理システムを含む、ＯＳＩ準拠コンピュータシステムに関する。さらに詳細には、本発明は、ＯＳＩ準拠システムのネットワーク中のあるエレメントに問合せシステムから到達可能であるかどうかを確認する方法に関する。
【０００２】
【従来の技術】
全ての転送ネットワーク要素（ＮＥ）を包含する通信管理ネットワーク中にＯＳＩスタックを含むことは、ロバストな診断ツールのない、比較的新しいが複雑な技術である。ネットワークのトラブルシューティングに要する時間を節約することができる新しいツールが必要とされている。そのような一つのツールは、ピング要求、すなわちその時点でユーザの位置から宛先システムに到達可能であるかどうかを確認するためにユーザが要求システムを介して発行した要求の結果に関する誤解を招く報告をなくす方法である。
【０００３】
従来技術では、ユーザがＯＳＩの下にある宛先システムをピングすると、その宛先システムはＯＳＩエコー機能を使用してそのピングを返送する。要求システムがピングに応答したエコーを受取らない場合には、要求システムはユーザに対して障害を報告する。しかし、宛先システムに到達可能であってもピングを返送することができないこともある。ピングを返送するためには、宛先システムはＯＳＩエコー機能をサポートしなければならないからである。このように、従来技術による障害報告は誤解を招くことがある。
【０００４】
ＯＳＩは、いわゆるコネクションレス型ネットワークプロトコル（ＣＬＮＰ）を使用し、前記プロトコルは、ＩＳＯ８４７３に規定のＣＬＮＰエコー機能、経路記録機能、およびエラー報告機能の三つの基本構築ブロックを有する。現在の慣行では、エラー報告機能は使用可能となっておらず、その出力は、ピングするシステムがＯＳＩピングユーザ応答を定式化するときに他の機能と整合がとれていない。したがって、ピングされた宛先システムに到達可能ではあるが宛先システムがＣＬＮＰエコー機能をサポートしていないときには、ピング要求は宛先システムに到達するが廃棄されることになるので、ユーザは誤解を招く結果を受取ることになる。
【０００５】
【発明が解決しようとする課題】
単に宛先システムがＣＬＮＰエコー能力を有していないという理由だけで異常状態を報告しないように、宛先システムの状態を確認してその結果を分析するようにＯＳＩピング機能を実行する方法が必要とされている。
【０００６】
【課題を解決するための手段】
本発明によれば、エラー報告および経路記録を使用可能にした状態で、ＣＬＮＰエコー要求プロトコルデータユニット（ＰＤＵ）を発行して宛先システムをピングすることにより、宛先システムをピングした結果に関する誤解を招く報告はなくなる。次いで、ＯＳＩピング分析機能に、宛先システムがＣＬＮＰエコー能力を有するかどうかを確認するために、エラー報告ＰＤＵを使用してエコー応答を解釈させる。エラー報告および経路記録を使用可能にした後、またＣＬＮＰエコー要求ＰＤＵを発行することによって宛先システムをピングした後で、本発明による完全なＯＳＩピング分析は下記の疑似コードに従って進行する。
【０００７】
応答がなければ、結果はＦＡＩＬ（失敗）、
さらに、ＣＬＮＰエコー応答ＰＤＵを受取れば、結果は、ＳＵＣＣＥＳＳ（成功）、
さらに、「機能サポートされず」という理由と、ソースアドレスとして、ピング宛先アドレス」のあるエラー報告であれば、結果は、ＳＵＣＣＥＳＳ、
さらに、結果は、ＦＡＩＬ、ＩＮＴＥＲＭＥＤＩＡＴＥ  ＳＹＳＴＥＭ（中間システム）
エコー要求が発行されたときにエラー報告を使用可能にすることにより、宛先システムに、メッセージ「ＦＵＮＣＴＩＯＮ  ＮＯＴ  ＳＵＰＰＯＲＴＥＤ」を含むエラー報告で強制的に応答させる。このエラー応答をエコー要求と整合させることにより、ＯＳＩピング分析機能は、宛先システムはエコー機能をサポートしないが、宛先システムに到達可能であると確認することができる。
【０００８】
本発明の上記その他の目的、特徴、および利点は、添付の図面に関連して与えられた下記の詳細な説明を考慮すれば明らかになるであろう。
【０００９】
【発明の実施の形態】
次に図１を参照すると、ユーザ（図示せず）は、宛先システム１１にユーザインタフェース１２を有する要求システム１０から到達可能であるかどうかを確認する。これを行うために、ユーザインタフェースは、エラー報告機能１７と、経路記録機能１８と、およびＣＬＮＰ（ＣＯＮＮＥＣＴＩＯＮＬＥＳＳ  ＮＥＴＷＯＲＫ  ＰＲＯＴＯＣＯＬ／コネクションレス型ネットワーク  プロトコル）エコー機能１９とを含むＯＳＩ（ＯＰＥＮ  ＳＹＳＴＥＭＳ  ＩＮＴＥＲＣＯＮＮＥＣＴＩＯＮ／開放型システム間相互接続）スタックＣＬＮＰ機能１４を順番に使用するＯＳＩピング要求機能１５を、要求システム内で使用する。エラー報告機能および経路記録機能が使用可能になると、ＣＬＮＰエコー機能はＣＬＮＰエコー要求ＰＤＵ（ＰＲＯＴＯＣＯＬ  ＤＡＴＡ  ＵＮＩＴ／プロトコル  データユニット）を宛先システム１１に発行する。宛先システムの応答はＣＬＮＰエコー機能１９で受取られ、ここから経路記録機能およびエラー報告機能もその応答を知る。三つの全てのＯＳＩスタックＣＬＮＰ機能は宛先システムからの応答のそれらの解釈をＯＳＩピング分析機能１６に通信し、前記機能が各ＯＳＩスタックＣＬＮＰ機能からの情報を検査し、統合した報告をユーザインタフェース１２に提供する。ＯＳＩピング分析機能は、下記に説明するように、宛先システムに到達可能であるかどうか、また宛先システムがＣＬＮＰエコー機能をサポートするかどうかによって、「ＳＵＣＣＥＳＳ（成功）」、「ＦＡＩＬ（失敗），  ＩＮＴＥＲＭＥＤＩＡＴＥ  ＳＹＳＴＥＭ（中間システム）」、または「ＦＡＩＬ」のいずれかを報告することになる。
【００１０】
図２に、本発明の方法をフローチャートで示す。これはＯＳＩピング分析機能１６による異なる三つの可能な応答各々各々への筋道を図示するものである。ここで図１および図２をともに参照すると、段階２１で、要求システム１０は宛先システムに問い合わせるユーザ要求を受取る。そして、次の段階２２で要求システムはエラー報告を使用可能にし、段階２３で要求システムは経路報告を使用可能にする。次いで段階２４で、要求システム１０はＣＬＮＰエコー要求ＰＤＵを宛先システム１１に発行する。宛先システムが、到達可能であり、ＣＬＮＰエコー機能をサポートしている場合には、宛先システムは要求システム１０に正確な方法で応答する。
【００１１】
宛先システムが到達可能であるがＣＬＮＰエコー機能をサポートしていない場合には、要求システムはある応答を受け取るが、この応答によって、エラー報告機能１７はＣＬＮＰエコー機能がサポートされていないことを表明し、経路記録機能１８はこの不正確な応答のソースが宛先システムであることを表明する。それでも、この場合には宛先システムには到達可能である。
【００１２】
要求システムは、応答を受取ることもあるが宛先システムからではないこともある。この場合には、経路記録機能が、応答のソースが宛先システムではないことを示すことになる。この場合、宛先システムに到達可能でない。最後に、要求システムは応答を受取らないこともある。この場合、宛先システムには到達可能でない。
【００１３】
これらの三つのＯＳＩスタックＣＬＮＰ機能各々の出力を、ＯＳＩピング分析機能１６が利用することができ、前記分析機能はまず段階２５で、応答が受取られているかどうかを検査する。受取られていない場合には、ＯＳＩピング分析機能は「ＦＡＩＬ」を報告する。
【００１４】
次に段階２６で、ＯＳＩピング分析機能は、エコー応答ＰＤＵが受取られているかどうか、すなわち正確な応答が受取られているかどうかを確認する。受取られている場合には、ＯＳＩピング分析機能はユーザインタフェースを介して「ＳＵＣＣＥＳＳ」という報告で応答する。ＣＬＮＰエコー応答ＰＤＵが受取られていない場合には次に段階２７で、ＯＳＩピング分析機能は、エラー報告機能１７が「ＦＵＮＣＴＩＯＮ  ＮＯＴ  ＳＵＰＰＯＲＴＥＤ（機能サポートされず）」を与えたかどうか、またソースアドレスが宛先アドレスと同じであることを経路報告機能１８が示すかどうかを確認する。これら両方の照会に対する回答がＹＥＳである場合には、不正確な応答が受取られた場合でも宛先アドレスから受取られたものであり、したがって宛先システムに必ず到達可能であるので、ＯＳＩピング分析機能はやはり「ＳＵＣＣＥＳＳ」と報告する。
【００１５】
段階２７での質問のいずれかに対する回答がＮＯである場合には、段階２８に示すようにＯＳＩピング分析機能は「ＦＡＩＬ，  ＩＮＴＥＲＭＥＤＩＡＴＥ  ＳＹＳＴＥＭ」と報告することになる。
【００１６】
例えばＯＳＩピング分析機能が、受取ったＣＬＮＰ  ＰＤＵを検査して応答のソースが宛先システムのアドレスであるかどうかを知ることによって、「ＦＡＩＬ、ＩＮＴＥＲＭＥＤＩＡＴＥ  ＳＹＳＴＥＭ」の結果を決定することもできるので、本発明の方法は本明細書に与えた段階の順序に制限されない。したがって、ＯＳＩピング分析機能は、段階２６の前にＣＬＮＰ  ＰＤＵを検査して、受信した応答が中間システムからのものであるかどうかを確認することもできる。
【００１７】
したがって本発明の方法によれば、宛先システムがＣＬＮＰエコー機能をサポートするかどうかに関わらず、要求システムは宛先システムに到達可能でない場合にのみ「ＦＡＩＬ」（または「ＦＡＩＬ、ＩＮＴＥＲＭＥＤＩＡＴＥ  ＳＹＳＴＥＭ」）と報告することになる。
【００１８】
上述の装置は本発明の原理の適用分野の単なる例であることを理解されたい。当業者なら、趣旨を逸脱することなく多数の変更および代替構成を考案することができる。
【図面の簡単な説明】
【図１】本発明に従って協働するネットワークの構成要素を示すブロック図である。
【図２】本発明を例示するフローチャートである。
【符号の説明】
１０  要求システム
１１  宛先システム
１２  ユーザインタフェース
１４  ＯＳＩスタックＣＬＮＰ機能
１５  ＯＳＩピング要求機能
１６  ＯＳＩピング分析機能
１７  エラー報告機能
１８  経路記録機能
１９  ＣＬＮＰエコー機能
【図１】
0003556485.tif 000002
【図２】
0003556485.tif 000003