JP2004207878A - 通信装置 - Google Patents
通信装置 Download PDFInfo
- Publication number
- JP2004207878A JP2004207878A JP2002372467A JP2002372467A JP2004207878A JP 2004207878 A JP2004207878 A JP 2004207878A JP 2002372467 A JP2002372467 A JP 2002372467A JP 2002372467 A JP2002372467 A JP 2002372467A JP 2004207878 A JP2004207878 A JP 2004207878A
- Authority
- JP
- Japan
- Prior art keywords
- link
- frame
- communication device
- data
- lcp
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0681—Configuration of triggering conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Environmental & Geological Engineering (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
【課題】データリンク層のリンク状態を迅速に判定可能な通信装置を提供する。
【解決手段】通信装置は、対向装置との間で確立したデータリンク層のリンクが正常な場合にこのリンクを通じて或る間隔内で順次到着するフラグを受信し、フラグの受信状態を監視して前記リンクが正常か異常かを判定する。前記判定により前記リンクが異常と判断された場合、このリンクを終了させる。
【選択図】図２
【解決手段】通信装置は、対向装置との間で確立したデータリンク層のリンクが正常な場合にこのリンクを通じて或る間隔内で順次到着するフラグを受信し、フラグの受信状態を監視して前記リンクが正常か異常かを判定する。前記判定により前記リンクが異常と判断された場合、このリンクを終了させる。
【選択図】図２
Description
【０００１】
【発明の属する技術分野】
本発明は、データ・リンク層のリンクを監視および制御する通信装置に関する。本発明は、例えば、ＩＰパケット又はイーサネット・フレームをＨＤＬＣ(High-level Data Link Control procedure:ハイレベル・データリンク制御手順)フレームに類似したフレーム(HDLC類似フレーム：以降、“HDLC-Likeフレーム”と呼ぶ)にカプセル化し、データ・リンク層のリンクを通じて転送する機能を有するSONET/SDH(Synchronous Optical NETwork/Synchronous Digital Hierarchy)通信装置に適用される。SONET/SDH通信装置は、中継回線インターフェースとしてSONET/SDHを利用する伝送装置、ルータ、スイッチ等の通信装置を含む。
【０００２】
【従来の技術】
インターネットや広域ＬＡＮサービス(ＭＡＮ: Metropolitan Area Network又はＷＡＮ: Wide Area Network)の普及に伴い、アクセス回線としてIEEE 802.3で規格化されたネットワーク(イーサネット（商標）)を実装(収容)し、イーサネットで構築されるローカル・ネットワーク間を相互接続する媒体としてSONET/SDH通信装置が多用されている。SONET/SDH通信装置は、中継回線インターフェースとしてSONET/SDHを利用する伝送装置、ルータ、スイッチ等の通信装置を含む。
【０００３】
ＩＰ(Internet Protocol)パケットをSONET/SDH通信装置間で転送する為のデータ・リンク層の規格としてＰＰＰ(Point to Point Protocol)が規定されている(RFC1661/1662/2615等)。ＰＰＰはポイント-トゥ-ポイント(Point-to-Point)のデータ伝送を保証し、かつユーザ認証等の付加機能を提供している。このため、ＰＰＰはSONET/SDH通信装置を介した広域サービスに適している。
【０００４】
また、イーサネット・フレームをSONET/SDHフレームのペイロード(SONET/SDH Payload)にマッピングする規格(例えば、ITU-T X.86、ITU-T G.7041 GFP)も標準化されつつある。
【０００５】
ところで、提供するサービスの品質を保証する為、SONET/SDH通信装置間におけるデータ・リンク層のリンク状態の監視を確実に行う必要がある。
【０００６】
企業等のエンド・ユーザは、通常、専用線やイーサネットを介してインターネットや遠方に位置するイントラネットにアクセスするために、通信事業者によって提供されるSONET/SDHネットワークを利用する。なぜなら、SONET/SDHネットワークによって提供されるサービスの品質が高いからである(例えば、障害時の伝送路切替えによる迅速な復旧等)。
【０００７】
通常、SONET/SDH通信装置間のデータ転送について、ＰＰＰがデータ・リンク層のプロトコルとして利用される(PPP over SONET/SDH:“ＰＯＳ”と呼ばれる)。図１０は、ＰＰＰを利用してSONET/SDH通信装置間でＬＡＮを相互接続する例を示す図である。
【０００８】
図１０において、各通信装置(通信装置１および２)は、アクセス回線にイーサネットを実装し、イーサネット信号をＰＰＰにカブセル化し、それをSONET/SDHのPayloadにマッピングすることでSONET/SDH信号として転送する装置である。
【０００９】
各通信装置は、100BASE-TXやGigabit Ethernet等のＭＡＣフレームを終端するＭＡＣ部、ＭＡＣフレームをＰＯＳフレームにマッピングするＰＰＰ部、ＰＯＳフレームをSONET/SDH PayloadにマッピングするＳＴＳ部より構成される。実際には、SONET/SDH Payloadをクロス・コネクトする部分やOC-48といった標準フォーマットに変換する部分も存在するがここでは省略する。
【００１０】
ＭＡＣ部で終端されたイーサネット信号は、ＰＰＰ部にてHDLC-Likeフレームにマッピング(Mapping)される。図１１は、ＰＯＳのフレーム構成を示す図である。図１１の最初の行(最上段)に記載されたフレームフォーマットは、HDLC-Likeフレームの構造を示す。
【００１１】
ＭＡＣ部で終端されたイーサネット信号(ユーザ・データ)は、HDLC-Likeフレームの“情報”フィールドに挿入される。情報フィールドの内容は、“プロトコル”フィールドに設定される値により識別される。例えば情報フィールドに挿入されるユーザ・データの上位層がＩＰならばプロトコルフィールドの値は“0x0021”に設定される。
【００１２】
ＰＰＰは、データ・リンク層のプロトコルである。このため、ＰＰＰ終端部(図１０に示した各通信装置１および２のＰＰＰ部)の間でリンク確立の手順を実行する必要がある。リンクが確立した後に、通信装置間でデータ(ユーザ・データ)の伝送が可能になる。ＰＰＰでは、ＬＣＰ(Link Control Protocol：リンク制御プロトコル)によるリンク確立手順が規定されている。図１１には、ＰＯＳでのＬＣＰフレームが定義されている。
【００１３】
ＬＣＰフレームは、ユーザ・データと同様に、図１１の最初の行(最上段)に示すHDLC-Likeフレーム構造を持つ。但し、ＬＣＰフレームは、図１１の２行目(上から２段目)に示すように、ユーザ・データに対するHDLC-Likeフレームと同様に、プロトコルフィールドと、情報フィールドと、パディング(Padding)フィールドとを持つ。情報フィールドには、ＬＣＰに係るデータが挿入され、プロトコルフィールドには、ＬＣＰを示す値(LCP=0xC021)がセットされる。パディングフィールドは、情報フィールドのデータ長を規定以上に保つ為の詰め物である。
【００１４】
図１１の３および４行目(上から３および４段目)には、ＬＣＰフレームの情報フィールド内の構成が定義されている。“Code”フィールドはＬＣＰリンク制御に関する各種要求・応答を識別するための値がセットされる。“Code”フィールドに続く“Identifier”,“Length”,“Data/Option”フィールドの値はＬＣＰリンク制御要求・応答の種類に依存する。なお、HDLC-Likeフレームのフォーマットは、下記の非特許文献１，非特許文献２で説明されている。
【００１５】
図１２は、図１０に示すような通信装置間で行われるＬＣＰリンク制御の手順を示すシーケンス図である。図１２に示すように、上位層からのリンク確立要求，または装置の電源オンもしくはリセット等の外部要因により、ＬＣＰリンクを確立する場合には、通信装置１および通信装置２のＰＰＰ部間で、“ＬＣＰリンク設定要求フレーム”と、ＬＣＰリンク設定要求フレームに対する“ＬＣＰリンク設定確認フレーム”とを送受信する手順が行われる。そして、双方におけるＬＣＰリンク設定確認フレームの受信を以ってリンクが確立する(ＬＣＰリンク・オープン状態)。
【００１６】
その後、ＬＣＰにてオプションとして提供される認証手順が必要に応じて起動される。その後、上位層からのリンク切断要求や外部要因によりリンクを切断する場合には、通信装置１および通信装置２のＰＰＰ部間で“ＬＣＰリンク終了要求フレーム”と“ＬＣＰリンク終了確認フレーム”との送受信という手順を踏む(ＬＣＰリンク・クローズ状態)。なお、上記したＬＣＰリンク・オープンシーケンスは非特許文献３に、ＬＣＰリンク・クローズシーケンスは非特許文献４に開示されている。
【００１７】
上記したようにＰＰＰは、装置(ＰＰＰ部)間でリンクを確立する。このため、通信装置間の信号断(光ファイバの切断)等によりリンクが切断される場合を考慮する必要がある。リンクが切断された後は、ユーザ・データの転送を保証できなくなるので、再びリンク確立(リンク再確立)の手順を踏む必要がある。
【００１８】
ＰＰＰでは、アナログ(電話)回線でモデム利用を想定した物理層(Carrier Detect信号を利用)でのリンク状態監視と共に、ＬＣＰメッセージによるリンク状態監視手順を規定している。前者の物理層監視はＰＯＳに適用することができない。後者では、図１２に示すように、ＬＣＰリンク・オープン状態において、リンク状態を調べたい側(検査側：例えば、図１０に示す通信装置１)が“LCP ECHO要求フレーム”を送信する。LCP ECHO要求フレームを受信する側(応答側：例えば、図１０に示す通信装置２)は、LCP ECHO要求フレームを受信すると“LCP ECHO応答フレーム”を返答する。検査側は一定時間(応答待ちタイマで定義される時間)が経過する前に“LCP ECHO応答フレーム”を応答側から受信した場合はリンク状態は正常と判定し、受信できなかった場合はリンク状態は異常と判定する。
【００１９】
ただし、リンク状態監視について、手順は規定されているが、その実装(機能を実装するか、機能を有効にするか、応答待ちタイマの値をどの位にするか、断検出時に保護を持たせるか、等)は任意である。通常はこのリンク監視機能を有効にしていないか、有効にしていても断判定に保護(一定時間待ってリトライを何回か行う)を持たせている。なお、上記した“LCP ECHO要求フレーム”および“LCP ECHO応答フレーム”は非特許文献５に開示されている。
【００２０】
また、本発明に関連する先行技術として、非特許文献６に記載されるようなＰＰＰにおけるネゴシエーション機能、IEEE 802.3x(フロー制御)で規定されるようなPause(ポーズ)フレームがある。
【００２１】
【非特許文献１】
Network Working Group、“Request For Comments: 1662, PPP in HDLC-Like Framing, 3.1 Frame Format”、[online]、1994年7月、Internet Engineering Task Force、[平成１４年１１月２８日検索]、インターネット＜ URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献２】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 2. PPP Encapsulation”、[online]、1994年7月、Internet E ngineering Task Force、[平成１４年１１月２８日検索]、インターネッ ト＜URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献３】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 3.4 Link Establishment Phase”、[online]、1994年7月、In ternet Engineering Task Force、[平成１４年１１月２８日検索]、イン ターネット＜URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献４】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 3.7 Link Termination Phase”[online]、1994年7月、Intern et Engineering Task Force、[平成１４年１１月２８日検索]、インター ネット＜URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献５】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 5.8 Echo-Request and Echo-Reply”、[online]、1994年7月、Internet Engineering Task Force、[平成１４年１１月２８日検索]、イ ンターネット＜URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献６】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 4. The Option Negotiation Automation”、[online]、1994年7月、Internet Engineering Task Force、[平成１４年１１月２８日検索 ]、インターネット＜URL:http://rfc-jp.nic.ad.jp/＞
【００２２】
【発明が解決しようとする課題】
上述したように、ＰＯＳでは物理層でのリンク監視方法、すなわちリンク切れおよびその復旧判定手順や条件が規定されていない。故にＬＣＰメッセージによるデータ・リンク層のリンク監視で物理層でのリンク監視を代用することが余儀なく行われている。ここで、ＬＣＰメッセージによるリンク監視は下記問題を有している。
【００２３】
(１) 負荷によりリンク状態を誤認する虞がある。ユーザ・データがバースト的に許された帯域を超過する状態が頻発した場合には、一方の通信装置(検査側)がLCP ECHO要求フレームを送信しても、他方の通信装置(被応答側)がユーザ・データの処理に追われてLCP ECHO応答フレームの返答に遅れると、応答待ちタイマがタイム・アウトする可能性がある。この場合、リンク状態は実際には正常で、負荷により一時的に応答側による応答が遅れただけである。しかしながら、検査側はリンクが切断されたと誤認してしまう。
【００２４】
(２) 問題(１)を防止する為に検査側での断判定に保護(一定時間待ってリトライを何回か実施し、リンク断を指定された回数連続で検出することで、リンク断と判断する)を適用すると、リンク断が実際に発生している場合において検査側が“リンクが切れている”と判定するまでの時間が長くなる。これによって、サービスに支障を来たす期間(リンク切れから復旧までの期間)が延伸する虞がある。
【００２５】
(３) ＬＣＰメッセージによるリンク監視機能が実装されていない、またはリンク監視機能が実装されていても有効に設定されていない場合には、リンク断の判定が実施されない。
【００２６】
(４) SONET/SDH通信装置特有の問題がある。SONET/SDH通信装置はクロス・コネクト機能を有する。クロス・コネクトに対する設定の変更はＰＰＰリンクに影響を与える可能性がある。よって、外線(この場合光信号)の状態をリンク状態の判定に適用するのに加え、クロス・コネクト状態もリンク状態の判定条件として定義する必要がある。外線及びクロス・コネクト状態の監視は、通常ハードウェアまたはファームウェアにより行われる。このような間接的な事象でリンク状態を推測する方法では、監視対象の事象が多い場合には、処理が煩雑になる。また、監視対象の事象が追加された場合はハードウェア又はファームウェアの変更を余儀なくされる。もし、間接的な事象ではなく、これら間接的事象を引き起こす共通の(直接的な)事象をもってリンク状態の判定が可能になれば、このような処理の煩雑さや将来における変更の必要はなくなる。
【００２７】
(５) ＰＰＰリンクが切れた状態では、アクセス回線(イーサネット)側から受信したイーサネット・フレームはSONET/SDH通信装置で廃棄される。このとき、そのイーサネット・フレームを送信した装置(例えば通常のLANスイッチや端末)にはイーサネット・フレームが廃棄されたことが通知されない。なぜなら、リンク状態を監視するＰＰＰ部とイーサネット・フレームを終端するＭＡＣ部は相互に独立しており、ＰＰＰ部からＭＡＣ部にリンク状態を通知する術がなく、更にリンク状態を通知してフロー制御(イーサネット側に対してフレーム送信の一時中断や送信再開を指示する)を実施するという規格が存在しないからである。上記したフレーム廃棄は、ＰＰＰリンク断状態が復旧しリンクが再確立された時点で解除される。ところが、リンク状態が正常になったこともＰＰＰ部からＭＡＣ部に通知されない。このため、イーサネット・フレームの送信側(LANスイッチや端末側)は、リンクが切れている期間に送信したユーザ・データに対する再送等による保護を何ら適用することができない。
【００２８】
(６) 一つのSONET/SDH通信装置に対して他の複数の装置がスター型で接続される運用形態(Server-Client(サーバ-クライアント)型のネットワーク構成)において、Server側装置から定期的にLCP ECHO要求フレームを送信しリンク状態を監視する場合がある。この場合には、接続されるClient側装置の数が多くなる程リンク監視に要する処理が増大し、ユーザ・データ自身を処理する能力を低下させる虞がある。この形態は、本店と各支店を接続しかつ各支店間での通信が不要な場合やセキュリティ上の理由で本店経由でインターネットや別の支店との接続を許容する場合に一般的に適用される。
【００２９】
本発明は、上述した問題に鑑みなされたものであり、迅速なリンク状態の判定を可能とする通信装置を提供することを目的とする。
【００３０】
また、本発明の他の目的は、リンク状態の判定の確実性が向上する通信装置を提供することである。
【００３１】
また、本発明の他の目的は、リンク状態に基づくフロー制御が可能な通信装置を提供することである。
【００３２】
【課題を解決するための手段】
本発明は、上述した目的を達成するために以下のような手段を採用する。すなわち、本発明は、対向装置との間で確立されるデータリンク層のリンクが正常な場合に、このリンクを通じて或る間隔内で順次到着するフラグを受信する受信手段と、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定する判定手段と、を含む通信装置である。
【００３３】
本発明によれば、或る間隔内で順次到着するフラグの受信状態を監視し、フラグが或る間隔内で受信できなくなればリンク切れと判定することができる。これによって、従来の手法(ＬＣＰリンク保守シーケンス)に比べて、リンク切れの判定を迅速に行うことができる。また、リンク切れの判定を確実に行うこともできる。
【００３４】
本発明は、前記判定手段によって前記リンクが切れていると判定された場合にリンク終了フェーズに移行して、このリンクを終了させるように構成するのが好ましい。
【００３５】
また、本発明は、前記判定手段の有効または無効を前記対向装置との間でネゴシエーションするネゴシエーション手段をさらに含むように構成するのが好ましい。
【００３６】
また、本発明は、対向装置との間で確立しているデータ・リンク層のリンクに、データの送信元から受信する送信対象のデータを送出する手段と、
前記リンクのリンク切れの検出に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるデータ送信制御手段とを含む通信装置である。
【００３７】
本発明によれば、リンク切れによってリンクが終了される場合に、データの送信元からのデータ送信を停止させることができる。これによって、通信装置が送信元から受信したデータを廃棄してしまうことを防止することができる。
【００３８】
また、本発明は、前記データ送信制御手段は、前記リンクを再確立した場合に、前記データの送信元にデータ送信を再開させるように構成するのが好ましい。
【００３９】
また、本発明は、対向装置との間で確立されるデータリンク層のリンクが正常な場合にこのリンクを通じて所定時間内で順次到着するフラグを受信するステップと、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定するステップと、を含む通信装置のデータリンク監視制御方法である。
【００４０】
また、本発明は、上記した判定手段を含み、通信装置に実装される、データリンク層のリンク監視装置として特定することも可能である。
【００４１】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。実施の形態における構成は例示であり、本発明は実施の形態の構成に限定されない。
【００４２】
〔本発明の概要〕
本発明の概要を説明する。図１(Ａ)は、PPP over SONET/SDH(ＰＯＳ)フレームの説明図であり、図１(Ｂ)は、フラグの説明図であり、図１(Ｃ)は、ＰＰＰのパケットがやりとりされている状態の説明図であり、図１(Ｄ)は、アイドル状態の説明図である。
【００４３】
図１(Ａ)に示すＰＯＳフレームは、データの送信側と受信側との間で確立したデータ・リンク層のリンク(例えばＰＰＰリンク)上を伝送される。ＰＯＳフレーム１０は、ＰＰＰフレームの一つであり、図１１に示したようなHDLC-Likeフレーム構造を持つ。
【００４４】
ＰＯＳフレーム１０を用いてユーザ・データが伝送される場合には、ユーザ・データはＰＯＳフレーム１０の“情報”フィールドに挿入される。但し、本発明は、情報フィールドの中身には依存しない。
【００４５】
ユーザ・データは、自装置又は対向装置にて送信要求があった場合にのみ送信される性質のものであり、回線(リンク)上を常に流れている訳ではない。ユーザ・データやその他の制御データが流れていない時(アイドル状態)では、図１(Ｂ)に示すようなフラグ２０(ＨＤＬＣのフラグと同様の“0x7E”または“01111110b”の値を持つ)を常に流すことがRFC1662等で規定されている。
【００４６】
即ち、送信側は対向装置(受信側)に送信すべきデータ(送信対象のデータ)が何もない場合にはフラグを常に送信する必要がある。従って、送信側と受信側との間で送信対象のデータがが送受信される場合には、リンク上の状態は、図１(Ｃ)の３０に示すＰＰＰのパケットがやりとりされている状態(フラグと、送信対象のデータを含むＰＰＰフレーム(ＰＯＳフレーム)とがシリアルに転送される状態)となり、送信側で送信対象のデータがない場合には、リンク上の状態は図１(Ｄ)の４０に示すアイドル状態(フラグのみがシリアルに転送される状態)となる。このように、確立されたリンクが正常である場合には、そのリンクを通じてフラグが所定の間隔内で受信側に順次到着する。
【００４７】
一方、受信側は、回線状態(リンク状態)が正常でリンクが確立されている状態では対向装置からユーザ・データや制御データを受信しない場合でもフラグを常に(所定の間隔内で)受信するはずである。そして、受信側は、回線状態に何らかの異常が発生した場合には、フラグを受信できなくなる。このため、受信側でフラグの受信状態を監視すれば、リンク状態の正常／異常を判定することができる。
【００４８】
図２は、本発明に係る通信装置の構成を示す図である。図２には、本発明に係る通信装置としてのSONET/SDH通信装置Ａに搭載されるＰＰＰ部４５の構成が示されている。ＰＰＰ部４５(設定手段，ネゴシエーション手段，リンク監視手段，リンク監視装置に相当)は、PPP over SONET/SDH(ＰＯＳ)制御部５０(受信手段，判定手段に相当)とリンク制御部６０(リンク制御手段，データ送信制御手段に相当)とを備えている。
【００４９】
ＰＯＳ制御部５０は、従来の機能(ＭＡＣ制御部６１(図１０に示すＭＡＣ部に相当)で終端されたＭＡＣフレームをＰＯＳフレームにマッピングする機能、およびＳＴＳ部(図１０参照)で終端されたＰＯＳフレームを受信してＭＡＣフレームにマッピングする機能)に加えて、ＰＯＳフレームのフラグ受信状態を監視する。すなわち、ＰＯＳ制御部５０は、リンクを通って或る間隔内で順次到着するフラグを受信するように構成されている。
【００５０】
リンク制御部６０は、上位層からの要求やその他外部要因という従来の事象に加えて、ＰＯＳ制御部５０から通知されるＰＯＳフレームのフラグ受信状態情報を監視し、それに基づいてリンク状態制御をＰＯＳ制御部５０に対して行う。
【００５１】
SONET/SDH通信装置１００のＰＰＰ部４５間でＰＰＰリンク確立手順が踏まれた後、ＰＰＰリンクが確立している状態(ＬＣＰリンク・オープン状態)で、ＰＯＳ制御部５０は、対向装置からのフラグ受信の有無を判定する。
【００５２】
即ち、ＰＯＳ制御部５０は、所定時間を計時するリンク断監視タイマ(監視タイマ)５１を有し、フラグを受信する毎に監視タイマ５１を起動する。監視タイマ５１の値(監視タイマ５１で計時する所定時間)は、通常状態でリンク断を検出しないことを保証する(ビット)時間とする。
【００５３】
ＰＯＳにおけるフレーム最大長は1,500バイト程度であり、フレームが最大長である場合には、フラグ(データの開始)から次のフラグ(データの終了または2つの連続したフレーム間に挿入される)までの期間は、1,531バイト = 1,531×8 = 12,248ビット時間(フラグ: 1バイト、アドレス: 1バイト、制御: 1バイト、プロトコル: 2バイト、ユーザ・データ: 最大1,522バイト、FCS: 4バイトの合計)となる。このため、最低でも上記期間が経過するまではリンク断と判定しない(タイマがタイムアウトにならない)ように所定時間が設定される。但し、監視タイマ５１の値(所定時間)があまり長く設定されると、実際にリンクが切れている場合の判定が遅くなる。このように、監視タイマ５１に設定される所定時間は、リンク正常時におけるフラグの到着間隔の最大値よりも長く設定することができる。
【００５４】
ＰＯＳ制御部５０は、所定期間フラグを受信しなかった場合には、監視タイマ５１をタイム・アウトさせ、監視タイマ５１のタイム・アウトをリンク制御部６０に通知する(図２の“リンク状態”と書かれた矢印を参照)。
【００５５】
図３は、ＰＯＳ制御部によるリンク断判定処理手順を示す図である。図３において、ＬＣＰリンク・オープン状態(ＬＣＰリンク確立状態)になった時(ステップＳ２００)、ステップＳ２０１にてフラグ監視機能が有効であるか、無効であるかが判断され、有効であれば(Ｓ２０１；ＹＥＳ)、ＰＯＳ制御部５０によるフラグ監視が行われ、無効であれば(Ｓ２０１；ＮＯ)、フラグ監視が行なわれない(ステップＳ２０２：監視停止(これについては後述する))。
【００５６】
フラグ監視が行なわれる(有効である)場合には、ＰＯＳ制御部５０は、ステップＳ２０３にてフラグの受信を待ち、フラグの受信を確認すると、ステップＳ２０４にて監視タイマ５１による計時を開始し、次のフラグの受信判定(ステップＳ２０５)と、監視タイマ５１のタイムアウト判定(ステップＳ２０６)とを含むループ処理を、次のフラグが受信されるか(Ｓ２０５；ＹＥＳ)、または監視タイマ５１がタイムアウトになる(Ｓ２０６；ＹＥＳ)まで、繰り返し実行する。
【００５７】
ＰＯＳ制御部５０は、ステップＳ２０６にて監視タイマ５１のタイムアウト(所定時間の計時)を検知すると(Ｓ２０６；ＹＥＳ)、リンク状態(リンク異常：リンク断判定)をリンク制御部６０に通知し、リンク制御部６０にＬＣＰリンクを終了させる(リンク終了フェーズに移行する：ステップＳ２０７)。
【００５８】
これに対し、ＰＯＳ制御部５０は、監視タイマ５１がタイムアウトする前に、ステップＳ２０５にて次のフラグを受信した場合には、リンクが正常であるものとして、監視タイマ５１を停止させ(ステップＳ２０８)、次のフラグの受信を監視するため、監視タイマ５１を再起動(リセット)する(ステップＳ２０４)。
【００５９】
リンク制御部６０はステート・マシンである。図４は、リンク制御部６０の状態遷移図である。図４には、ＰＰＰで規定されるリンク制御の状態遷移(“RFC1661(Point-to-Point Protocol) 3.2 Phase Diagram”参照)に、本発明に係るフラグ受信監視条件が加えられた状態遷移図が示されている。
【００６０】
図４は、リンク制御部６０にて管理される状態遷移を示す。図４において、１００はリンク停止フェーズであり、物理的あるいは電気的に動作していない状態を示す。物理的あるいは電気的に動作している状態になると、リンク確立フェーズ１０１に移行し、ここでリンクを確立するためにＬＣＰリンク設定要求・確認フレームをお互いに交換する。
【００６１】
ＬＣＰリンク設定要求・確認フレームの交換が正常に完了すると、ＬＣＰリンク・オープン状態１１０となる。この後、ネットワーク層プロトコルフェーズ１０３の前に、必要ならば認証プロトコル１０２が実行される。なお、この認証プロトコルは実施を省略することができる。
【００６２】
ネットワーク層プロトコルフェーズ１０３では、実装されるネットワーク層プロトコルに対応したＮＣＰ(Network Control Program：ネットワーク制御プログラム)がそれぞれ実行される。これによって、ＮＣＰリンク・オープン状態１１１となる。
【００６３】
その後、ＬＣＰリンクを終了する場合は、リンク終了フェーズ１０４に状態を遷移させて、ＬＣＰリンクを終了する。すると、状態がＬＣＰリンク・クローズ状態１１２となる。
【００６４】
リンク制御部６０は、ＬＣＰリンク・オープン状態１１０のときにＰＯＳ制御部５０から通知されるリンク状態情報に基づいてリンク監視を行ない、リンク状態情報からＬＣＰリンクが切れていること(ＬＣＰリンク断)を検出すると、状態をリンク終了フェーズ１０４に遷移させる。このように、ＬＣＰリンクが切れたこと(の検出)がＬＣＰリンクオーブン状態１１０からリンク終了フェーズ１０４への状態遷移のトリガとなっている。
【００６５】
リンク制御部６０がリンク終了フェーズ１０４に遷移すると、自装置と対向装置との間でＬＣＰリンク・クローズ・シーケンス(図１２)が実施され、ＬＣＰリンク・クローズ状態１１２に遷移する。
【００６６】
上記したリンク切れは、データ・リンクが確立される物理リンク(光ファイバ)の切断によって発生する。このような障害は、光ファイバの交換により復旧する。このような物理リンク(光ファイバ)の復旧は、物理層における信号の送受信により検出可能である。リンク制御部６０は、物理層で検出される物理リンクの復旧を検出した場合には、リンク確立フェーズ１０１に移行して、データ・リンク層のリンクを再確立する。
【００６７】
ところで、対向する通信装置の一方に本発明に係る構成(ＰＯＳ制御部５０によるフラグ監視機能)が適用され、他方がアイドル状態でフラグを送信しないこと(フラグ監視機能を持たない)が想定される。この場合には、一方の通信装置が受信側になると、常にリンク断を検出することになる。このようなケースを考慮し、本発明に係る通信装置は、上述したリンク断監視機能を有効にするか無効にするかを設定する機能(有効／無効設定機能)をさらに具備することができる。
【００６８】
図３には、有効／無効設定機能が付加されている場合の処理がステップＳ２０１および２０２として示されている。上述したように、監視機能が“有効”に設定されている場合には、ステップＳ２０１で“ＹＥＳ(有効)”と判定され、上述したフラグ監視機能が動作する(Ｓ２０３〜Ｓ２０７)。これに対し、フラグ監視機能が“無効”に設定されている場合には、ステップＳ２０１で“ＮＯ(無効)”と判定され、監視機能が動作せず(Ｓ２０２)、フラグを受信しない状態でもリンク断は検出されない。
【００６９】
但し、本発明に係る通信装置のＰＰＰ部４５は、LCP ECHO要求フレームによるリンク状態監視機能(図１２参照)を具備し、フラグ監視機能が“無効”である場合には、このリンク状態監視機能を動作させるように構成することが可能である。これによって、本発明に係るリンク状態監視機能を適用していない通信装置とのデータ・リンク層のリンク(ＰＰＰリンク)の相互接続を保証することができる。
【００７０】
さらに、上述した監視機能の有効・無効設定はユーザ・インターフェースを用いて実施することができる。この場合、対向する通信装置毎に設定を実施せねばならない。この場合、監視機能の有効・無効設定を通信装置毎に実施するのは手間がかかる。また、対向する通信装置の一方が有効に設定され、他方が無効に設定される等の通信装置間における矛盾が発生する可能性がある。
【００７１】
このため、ＬＣＰが提供するネゴシエーション機能を利用して、対向する通信装置の一方における設定を他方の通信装置に自動的に反映させる手法を採用することができる。
【００７２】
図５は、監視機能の有効／無効の設定をＬＣＰに定義する場合のフォーマット(監視機能の有効・無効設定が定義されたＬＣＰフレームのフォーマット)を示す図である。
【００７３】
図５において、プロトコル・フィールドの値は、“LCP(0xC021：既存)”であり、情報フィールドの“Code”の値は“Configure-Request(既存)”に設定される。さらに、Data/Optionフィールドに対し、新規に“Type=0x0A(0Ah):
リンク断監視機能”、“Data=0x0000(0000h:有効)/0x0001(0001h:無効)”というリンク断監視設定が定義される。このような監視設定の定義を含むData/Optionフィールドを通信設定オプション３０１と呼ぶ。
【００７４】
図４に示したＬＣＰリンク確立フェーズ１０１では、ＬＣＰリンク確立とＬＣＰ通信設定を行なうためにLink Configurationフレーム(Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject)を用いたネゴシエーションが通信装置間で実施される。Configure-Requestフレームは、ＬＣＰ通信設定要求を行なうものである(通信設定を装置間でネゴシエーションする)。このConfigure-RequestフレームのData/Optionフィールドに対し、図５に示した通信設定オプション301を定義する。
【００７５】
リンク断監視機能のデフォルトは無効に設定される。ＬＣＰリンク確立フェーズ１０１において、最初に、通信装置の一方は、ネゴシエーション側として、通信設定オプション３０１に“有効”を指定してネゴシエーションを行う。通信装置の他方が相手側として“有効”の指定を受諾した場合には、通信装置の一方は、ＬＣＰリンクが確立した後に“有効”の設定に基づいてリンク断監視動作を行う。これに対し、相手側が“有効”の指定を拒否した場合には、監視機能を“無効”に設定し、ＬＣＰリンクが確立してもリンク断監視動作は行なわない。
【００７６】
上記した構成(ネゴシエーション機能)により、ユーザがリンク断監視を有効にするか無効にするかを通信装置毎に設定する手間を省き、また対向装置間での設定矛盾を回避することが可能になる。なお、ネゴシエーション機能については、“RFC1661(Point-to-Point Protocol) 4. The Option Negotiation Automation”に規定されている。
【００７７】
図６は、ネゴシエーションにおいて監視機能の有効設定が受諾されるケースを示すシーケンス図であり、図７は、ネゴシエーションにおいて監視機能の有効設定が拒否されるケースを示すシーケンス図である。
【００７８】
図６において、対向する通信装置Ｘと通信装置Ｙ(それぞれフラグ監視機能および通信設定オプション３０１の認識機能を持つ)とがＰＰＰリンクを確立する場合には、ＬＣＰリンク・オープンシーケンス(リンク・オープンフェーズ)において、最初に、通信装置の一方(図６では通信装置Ｘ)は、相手方(通信装置Ｙ)に対し、“有効”が設定されたＬＣＰリンク設定要求フレーム(“有効”が設定された通信設定オプション３０１を含むConfigure-Requestフレーム)を送信する(ステップＳ６０１)。
【００７９】
このとき、相手側(通信装置Ｙ)が“有効”設定を受諾し、かつConfigure-Requestフレーム内のその他の通信設定オプションの全てを受諾する場合には、通信装置ＹはConfigure-Ack(通信設定肯定応答)フレームを送信する(ステップＳ６０２)。
【００８０】
また、通信装置Ｙは、通信装置Ｘに対し、“有効”が設定された通信設定オプション３０１を含むConfigure-Requestフレームを送信する(ステップＳ６０３)。これに対し、通信装置Ｘは、Configure-Requestフレーム内の“有効”設定を含む全ての通信設定オプションを受諾する場合には、Configure-Ackフレームを通信装置Ｙへ送信する(ステップＳ６０４)。
【００８１】
このようにして、通信装置ＸおよびＹは、相手側からのConfigure-Ackフレームを受信することでＬＣＰリンクを確立し、フラグ監視機能を有効に設定する。これによって、通信装置ＸおよびＹでフラグ監視動作がそれぞれ実施される。
【００８２】
図７において、対向する通信装置Ｘ(フラグ監視機能および通信設定オプション３０１の認識機能を持つ)と通信装置Ｙ(フラグ監視機能および通信設定オプション３０１の認識機能を持たない)とがＰＰＰリンクを確立する場合には、ＬＣＰリンク・オープンシーケンス(リンク・オープンフェーズ)において、通信装置の一方(図７では通信装置Ｘ)が、ステップＳ６０１と同様に、最初に、ステップＳ６０１と同様に、相手方(通信装置Ｙ)に対し、“有効”が設定されたＬＣＰリンク設定要求フレーム(“有効”が設定された通信設定オプション３０１を含むConfigure-Requestフレーム)を送信する(ステップＳ７０１)。
【００８３】
このとき、通信装置Ｙは、通信オプション３０１の“有効”設定を認識できないのでＬＣＰリンク設定要求を拒否する。通信装置Ｙは、ＬＣＰリンク設定要求を拒否する場合には、ＬＣＰリンク設定拒否フレーム(Configure-Reject(通信設定拒否)フレームを通信装置Ｘへ送信する(ステップＳ７０２)。
【００８４】
通信装置Ｘは、Configure-Rejectフレームを受信すると、監視機能設定を指定した通信設定オプション３０１を含まないConfigure-Requestフレームを通信装置Ｙへ送信する(通信オプション３０１なしでネゴシエーションをやり直す：ステップＳ７０３)。
【００８５】
一方、通信装置Ｙは、通信装置Ｘに対し、ネゴシエーション対象の通信設定オプションを含まないConfigure-Requestフレーム(通信設定オプション３０１を含まない)を通信装置Ｙへ送信する(ステップＳ７０４)。
【００８６】
通信装置Ｙは、Configure-Requestフレーム内の通信設定オプションを受諾する場合には、Configure-Ackフレームを通信装置Ｘへ送信する(ステップＳ７０５)。
【００８７】
通信装置Ｘも、通信装置ＹからのConfigure-Requestフレーム内の通信設定オプションを受諾する場合には、Configure-Ackフレームを通信装置Ｙへ送信する(ステップＳ７０６)。
【００８８】
このようにして、通信装置ＸおよびＹは、相手側からのConfigure-Ackフレームを受信することでＬＣＰリンクを確立する。このとき、通信装置Ｘは、フラグ監視機能を無効に設定する。したがって、通信装置Ｘは、フラグ監視動作を実施しない。一方、通信装置Ｙは、フラグ監視機能を持たないので、フラグ監視動作を行わない。
【００８９】
なお、図７において、通信装置Ｙがフラグ監視機能および通信オプション３０１の認識機能を持つ場合でも、所定の条件に従って“有効”設定に対するＬＣＰ設定拒否フレームを相手方に送信するように構成することができる。このとき、ＬＣＰ設定拒否フレームを受信した側は、通信オプション３０１を含まないＬＣＰ設定要求フレーム，または“無効”が設定された通信オプション３０１を含むＬＣＰ設定要求フレームを送信しなおすことができる。
【００９０】
ところで、本発明に係る通信装置Ａは、イーサネット(IEEE 802.3で規定されたネットワーク)を収容しており、イーサネットからのイーサネットフレームをＭＡＣ制御部６１で終端し、ＰＰＰ部でイーサネットフレームをＰＯＳフレームにカプセル化して確立済みのＰＰＰリンクへ送出する。
【００９１】
上述したＰＯＳ制御部５０およびリンク制御部６０の構成により、対向装置でＰＰＰリンクが切れていることが検出された場合には、対向装置におけるリンク制御部６０は、リンク終了フェーズ１０４(図４)に状態遷移し、対向装置間でＬＣＰリンク・クローズ・シーケンス(図１２)が実施され、各通信装置がＬＣＰリンク・クローズ状態となる。
【００９２】
ところが、イーサネットフレームの送信側の装置は、ＰＰＰリンクが切れたことを認識できないので、イーサネットフレームを送信し続ける。このような問題に鑑み、本発明に係る通信装置Ａは次の構成を持つ。
【００９３】
すなわち、通信装置Ａのリンク制御部６０は、図２に示すように、ＰＰＰ(ＬＣＰ)リンクの状態に基づいて、通信装置Ａに搭載されたＭＡＣ制御部６１に対するフロー制御を起動する。
【００９４】
すなわち、リンク制御部６０は、(１)リンク断状態(すなわちＬＣＰリンク・クローズ状態(図４の１１２参照))への遷移を契機として、ＭＡＣ制御部６１に対し、IEEE 802.3x(制御フロー)にて規定されるPauseフレーム(送信中断)をイーサネット側に送信させる制御と、(２)リンク復旧状態(ＬＣＰリンク・オープン状態(図４の１１０参照))への遷移を契機として、ＭＡＣ制御部６１に対し、Pauseフレーム(送信再開)をイーサネット側に送信させる制御を実施する。
【００９５】
IEEE 802.3xで規定されるフロー制御は、次の構成(機能)を持つ。全二重のイーサネット回線から受信するイーサネット・フレームを一旦バッファに蓄積し、そのバッファにフロー制御を起動するしきい値と解除するしきい値を定義する。フレーム量が起動しきい値を超えた場合には、イーサネット回線に対して送信中断を要求するPauseフレームというコマンドを送信する。一方、フレーム量が解除しきい値を下回った場合にはイーサネット回線に対して送信再開を示すPauseフレームを送信する。
【００９６】
フレーム量が起動しきい値を越えるような状況は、イーサネット回線から一時的に転送可能な帯域を超えるフレームを受信した場合に発生する。また、イーサネット回線の帯域に対してそれをマッピングするSONET/SDH信号の帯域が小さい(例えば1Gbpsのイーサネット回線をSTS-12c=622Mbpsにマッピングする)場合に発生する。
【００９７】
送信中断を示すPauseフレームを受信したイーサネット側の(対向)装置は、Pauseフレーム中の中断時間フィールドで指定されたビット時間が経過するまでの間イーサネット・フレームの送信を停止しなければならない。そして、送信再開を示すPauseフレーム(中断時間フィールドが“０”のPauseフレーム)を受信すると、イーサネット・フレームの送信を再開する。
【００９８】
図８は、Pauseフレームのフォーマットを示す図である。PauseフレームはＭＡＣフレーム構造を持つ。図８において、“宛先アドレス”には、Pauseフレーム用に予約されたマルチキャスト・アドレスがセットされる。“送信元アドレス”は、Pauseフレームの送信側のＭＡＣアドレスがセットされるが、特に指定しなくても良い。
【００９９】
“長さ/タイプ”フィールドおよび“操作コード”フィールドには、固定値(各々“0x8808”、“0x0001”)が指定される。“中断時間”フィールドには、指定された０〜65,535の(可変)値がセットされる。ここで指定された値×512ビット時間が経過するまでの間フレームの送信が停止(中断)される。
【０１００】
“512ビット時間”は、転送速度により異なる。例えば、イーサネットが100Mbpsイーサネットである場合には、約5usecであり、最大の中断時間は約330msecとなる。リンクが切れた状態が中断時間を超えて継続する場合、ＭＡＣ制御部６１は定期的に(間隔は転送速度に依存する)Pauseフレーム(送信中断)を送信し、リンクが切れた状態から復旧した時点で中断時間=0のPauseフレーム(送信再開)を送信することでフロー制御を解除する。
【０１０１】
このように、本発明は、リンク状態の変化をPauseフレームの送信トリガとして定義する。これによって、イーサネット回線(アクセス回線)を介して対向する装置に対してリンクが切れている間、データ(イーサネット・フレーム)の送信を待機させ、リンク復旧時に送信再開させる。このようにして、イーサネット・フレームをＰＯＳフレームにカプセル化して転送する場合におけるデータ転送の整合性が保証される。
【０１０２】
〔本発明の実施例〕
図９は、本発明が適用されたSONET/SDH通信装置Ａ２の構成例を示す図である。図９において、ＰＯＳ制御部４００と、ファームウェア(リンク制御部)４０１と、ＭＡＣ終端部４０２と、ＳＴＳ終端部４０３と、クロス・コネクト部４０４とを備えている。
【０１０３】
ＭＡＣ終端部４０２は、図２に示したＭＡＣ制御部６１に相当し、イーサネット回線４０５からのＭＡＣフレーム(イーサネット・フレーム)を終端し、ＰＯＳ制御部４００に渡す。また、ＰＯＳ制御部４００からのＭＡＣフレームをイーサネット回線４０５に送出する。また、ＭＡＣ終端部４０２は、ファームウェア(リンク制御部)４０１からの指示に従って、イーサネット回線４０５を介して接続されたＭＡＣフレームの送信側の装置に対するPauseフレームの送信処理を行う。
【０１０４】
ＰＯＳ制御部４００は、図２に示したＰＯＳ制御部５０に相当する。ＰＯＳ制御部４００は、ＭＡＣ終端部４０２からのＭＡＣフレームをＰＯＳフレームにカプセル化してＳＴＳ終端部４０３に渡す。また、ＰＯＳ制御部４００は、ＳＴＳ終端部４０３からのＰＯＳフレームからＭＡＣフレームを取り出してＭＡＣ終端部４０２に渡す。さらに、ＰＯＳ制御部４００は、図３に示したようなリンク断判定処理手順を実行し、リンク状態(リンク切れ)をファームウェア４０１に通知する。
【０１０５】
ファームウェア４０１は、図２に示したリンク制御部６０を実現する。すなわち、ファームウェア４０１は、図５に示したような状態遷移を行い、リンク確立フェーズ１０１において、図６および図７に示すようなネゴシエーションを対向装置との間で行い、フラグ監視機能の有効／無効を設定する。また、フラグ監視機能の無効を設定した場合には、LCP ECHO要求／応答フレームの送受信処理を行う。
【０１０６】
また、ファームウェア４０１は、リンク状態通知をトリガとして、リンク終了フェーズに移行する。さらに、ファームウェア４０１は、ＬＣＰリンク・クローズ状態への遷移を契機(トリガ)として、送信中断を示すPauseフレームの送信をＭＡＣ終端部４０２に指示し、ＬＣＰリンク・オープン状態への遷移(リンク切れ復旧)を契機(トリガ)として、送信再開を示すPauseフレームの送信をＭＡＣ終端部４０２に指示する。
【０１０７】
ＳＴＳ終端部４０３は、ＰＯＳ制御部４００で生成されたＰＯＳフレームをSTS Payloadにマッピングしてクロス・コネクト部４０４に渡す。また、ＳＴＳ終端部４０３は、クロス・コネクト部４０４からのSTS PayloadからＰＯＳフレームを取り出してＰＯＳ制御部４００に渡す。
【０１０８】
クロス・コネクト部４０４は、ＳＴＳ単位でのクロス・コネクトを実施し、STS Payloadを含む光信号を任意の位置に接続し、SONET/SDH信号４０６として対向装置に送信する。
【０１０９】
〔実施形態の作用〕
実施形態で説明した通信装置によれば、PPP over SONET/SDHのようなデータ・リンク層のリンク監視処理として、従来の手法(LCP ECHO要求/応答フレームの送受信)の代わりにフラグ監視処理を行う。これによって、リンク状態監視の為のメッセージ交換(LCP ECHO要求/応答フレームの送受信)に費やす負荷をゼロにすることができる。また、従来の手法に比べて、迅速かつ確実にリンク切れの判定を行うことが可能になる。これによって、課題で述べたような(１)，(２)，(３)，(４)および(６)の問題を解決することができる。
【０１１０】
また、実施形態で説明した通信装置によれば、リンクが切れている間は、イーサネット・フレームを送信する装置に対して送信停止を要求することによりデータ喪失を防止し、リンクの復旧後に当該装置から送信できず蓄積されたデータ(イーサネット・フレーム)の送信を促す。これによって、課題で述べたような(５)の問題を解決でき、ユーザ・データの整合性を保証し、インターネットやイントラネット・アクセスを提供するサービスの品質を向上させることが可能になる。
【０１１１】
さらに、実施形態で説明した通信装置によれば、リンク監視機能を実装しない既存の通信装置との相互接続も、ユーザによる設定を必要とすることなく保証することが可能となる。
【０１１２】
〔その他〕
本実施形態は次の発明を開示する。各項に開示される発明は、必要に応じて可能な限り組み合わせることができる。
【０１１３】
（付記１） 対向装置との間で確立されるデータリンク層のリンクが正常な場合にこのリンクを通じて或る間隔内で順次到着するフラグを受信する受信手段と、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定する判定手段と、
を含む通信装置。（１）
（付記２） 前記判定手段は、前記受信手段が前記リンクからフラグを受信した場合に所定時間を計時するタイマを起動し、次のフラグが前記受信手段で受信される前に前記タイマがタイムアウトになった場合には、前記リンクが異常と判定する
付記１記載の通信装置。
【０１１４】
（付記３） 前記判定手段は、前記タイマがタイムアウトになる前に前記受信手段で次のフラグが受信された場合には、前記タイマをリセットし、前記リンクが正常と判定する
付記２記載の通信装置。
【０１１５】
（付記４） 前記判定手段によって前記リンクが異常と判定された場合に、このリンクを終了させる(リンク制御手段をさらに含む)
付記１〜３のいずれかに記載の通信装置。（２）
（付記５） (前記リンク制御手段は、)前記リンクを終了させた後に、前記リンクの復旧が可能な状態になった場合には、前記リンクを再確立する
付記４記載の通信装置。
【０１１６】
（付記６） 前記判定手段を有効または無効に設定する設定手段をさらに含む付記１〜５のいずれかに記載の通信装置。
【０１１７】
（付記７） 前記判定手段の有効または無効を前記対向装置との間でネゴシエーションするネゴシエーション手段をさらに含む
付記１〜６のいずれかに記載の通信装置。（３）
（付記８） 前記ネゴシエーション手段は、前記判定手段の有効または無効を問い合わせるための情報を前記対向装置に送信し、問い合わせに対する応答を前記対向装置から受信する
付記７記載の通信装置。
【０１１８】
（付記９） 前記ネゴシエーション手段は、前記判定手段の有効を示す情報を前記対向装置に送信し、
前記設定手段は、前記ネゴシエーション手段が前記判定手段の有効を拒否することを示す応答を前記対向装置から受け取った場合には、前記判定手段を無効に設定する
付記８記載の通信装置。
【０１１９】
（付記１０） 前記判定手段が無効に設定された場合に起動し、前記対向装置に前記リンクの正常を検査する検査フレームを送信し、前記対向装置から前記検査フレームに対する応答フレームを所定時間内に受信した場合に前記リンクが正常と判定するリンク監視手段をさらに含む
付記１０記載の通信装置。
【０１２０】
（付記１１） データの送信元から受信する送信対象のデータを前記リンクへ送出する手段と、
前記リンクの異常に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるデータ送信制御手段と
をさらに含む付記４記載の通信装置。
【０１２１】
（付記１２） 前記データ送信制御手段は、前記リンクが再確立される場合に、前記データの送信元にデータ送信を再開させる
付記１１記載の通信装置。
【０１２２】
（付記１３） 対向装置との間で確立しているデータ・リンク層のリンクに、データの送信元から受信する送信対象のデータを送出する手段と、
前記リンクの異常に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるデータ送信制御手段と
を含む通信装置。（４）
（付記１４） 前記データ送信制御手段は、前記リンクが再確立される場合に、前記データの送信元にデータ送信を再開させる
付記１３記載の通信装置。
【０１２３】
（付記１５） 対向装置との間で確立されるデータリンク層のリンクが正常な場合に、このリンクを通じて所定時間内で順次到着するフラグを受信するステップと、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定するステップとを含む通信装置のデータリンク監視制御方法。（５）
（付記１６） 前記リンクからフラグが受信された場合に所定時間を計時するタイマを起動し、次のフラグが受信される前に前記タイマがタイムアウトになった場合には、前記リンクが異常と判定する
付記１５記載の通信装置のデータリンク監視制御方法。
【０１２４】
（付記１７） 前記タイマがタイムアウトになる前に前記受信手段で次のフラグが受信された場合には、前記タイマをリセットし、前記リンクが正常と判定する
付記１６記載の通信装置のデータリンク監視制御方法。
【０１２５】
（付記１８） 前記リンクが異常と判定された場合に、このリンクを終了させる
付記１５〜１７のいずれかに記載の通信装置のデータリンク監視制御方法。
【０１２６】
（付記１９） 前記リンクを終了させた後に、前記リンクの復旧が可能な状態となったときには、前記リンクを再確立する
付記１９記載の通信装置のデータリンク監視制御方法。
【０１２７】
（付記２０） 前記判定を行うか否かを前記対向装置との間でネゴシエーションする
付記１５〜１９のいずれかに記載の通信装置のデータリンク監視制御方法。
【０１２８】
（付記２１） 前記判定を行うか否かを問い合わせるための情報を前記対向装置に送信し、問い合わせに対する応答を前記対向装置から受信する
付記２０記載の通信装置のデータリンク監視制御方法。
【０１２９】
（付記２２） 自装置で前記判定を行うことを示す情報を前記対向装置に送信し、自装置が前記判定を行うことを拒否することを示す応答を前記対向装置から受け取った場合には、前記判定を行わない
付記２１記載の通信装置のデータリンク監視制御方法。
【０１３０】
（付記２３） 前記判定を行わない場合には、前記対向装置に前記リンクの正常を検査する検査フレームを送信し、前記対向装置から前記検査フレームに対する応答フレームを所定時間内に受信した場合に前記リンクが正常と判定するリンク監視処理を行う
付記２２記載の通信装置のデータリンク監視制御方法。
【０１３１】
（付記２４） 送信対象のデータを前記リンクへ送出するステップと、
前記リンクの異常に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるステップと
をさらに含む付記１８記載の通信装置のデータリンク監視制御方法。
【０１３２】
（付記２５） 前記リンクが再確立される場合に、前記データの送信元にデータ送信を再開させる
付記２４記載の通信装置の通信装置のデータリンク監視制御方法。
【０１３３】
（付記２６） 対向装置との間で確立しているデータ・リンク層のリンクに、データの送信元から受信する送信対象のデータを送出するステップと、
前記リンクの異常に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるステップと、
を含む通信装置のデータリンク監視制御方法。
【０１３４】
（付記２７） 前記リンクが再確立される場合に、前記データの送信元にデータ送信を再開させる
付記２６記載の通信装置のデータリンク監視制御方法。
【０１３５】
【発明の効果】
本発明によれば、迅速なリンク状態の判定が可能となる。また、本発明によれば、リンク状態の判定の確実性が向上する。また、本発明によれば、リンク状態に基づくフロー制御が可能となる。
【図面の簡単な説明】
【図１】図１(Ａ)は、PPP over SONET/SDH(ＰＯＳ)フレームの説明図であり、図１(Ｂ)は、フラグの説明図であり、図１(Ｃ)は、ＰＰＰのパケットがやりとりされている状態の説明図であり、図１(Ｄ)は、アイドル状態の説明図である。
【図２】図２は、本発明に係る通信装置の構成を示す図である。
【図３】図３は、ＰＯＳ制御部によるリンク断判定処理の手順を示す図である。
【図４】図４は、リンク制御部の状態遷移図である。
【図５】図５は、フラグ監視機能の有効／無効の設定をＬＣＰに定義する場合のフォーマットを示す図である。
【図６】図６は、ネゴシエーションにおいてフラグ監視機能の有効設定が受諾されるケースを示すシーケンス図である。
【図７】図７は、ネゴシエーションにおいてフラグ監視機能の有効設定が拒否されるケースを示すシーケンス図である。
【図８】図８は、Pauseフレームのフォーマットを示す図である。
【図９】図９は、本発明の実施例に係る通信装置の構成例を示す図である。
【図１０】図１０は、従来技術の説明図である。
【図１１】図１１は、従来技術の説明図である。
【図１２】図１２は、従来技術の説明図である。
【符号の説明】
Ａ,Ａ２,Ｘ,Ｙ 通信装置(SONET/SDH通信装置)
４５ ＰＰＰ部(設定手段，ネゴシエーション手段，リンク監視手段)
５０ ＰＯＳ制御部(受信手段，判定手段)
５１ リンク断監視タイマ(タイマ)
６０ リンク制御部(データ送信制御手段)
６１ ＭＡＣ制御部
【発明の属する技術分野】
本発明は、データ・リンク層のリンクを監視および制御する通信装置に関する。本発明は、例えば、ＩＰパケット又はイーサネット・フレームをＨＤＬＣ(High-level Data Link Control procedure:ハイレベル・データリンク制御手順)フレームに類似したフレーム(HDLC類似フレーム：以降、“HDLC-Likeフレーム”と呼ぶ)にカプセル化し、データ・リンク層のリンクを通じて転送する機能を有するSONET/SDH(Synchronous Optical NETwork/Synchronous Digital Hierarchy)通信装置に適用される。SONET/SDH通信装置は、中継回線インターフェースとしてSONET/SDHを利用する伝送装置、ルータ、スイッチ等の通信装置を含む。
【０００２】
【従来の技術】
インターネットや広域ＬＡＮサービス(ＭＡＮ: Metropolitan Area Network又はＷＡＮ: Wide Area Network)の普及に伴い、アクセス回線としてIEEE 802.3で規格化されたネットワーク(イーサネット（商標）)を実装(収容)し、イーサネットで構築されるローカル・ネットワーク間を相互接続する媒体としてSONET/SDH通信装置が多用されている。SONET/SDH通信装置は、中継回線インターフェースとしてSONET/SDHを利用する伝送装置、ルータ、スイッチ等の通信装置を含む。
【０００３】
ＩＰ(Internet Protocol)パケットをSONET/SDH通信装置間で転送する為のデータ・リンク層の規格としてＰＰＰ(Point to Point Protocol)が規定されている(RFC1661/1662/2615等)。ＰＰＰはポイント-トゥ-ポイント(Point-to-Point)のデータ伝送を保証し、かつユーザ認証等の付加機能を提供している。このため、ＰＰＰはSONET/SDH通信装置を介した広域サービスに適している。
【０００４】
また、イーサネット・フレームをSONET/SDHフレームのペイロード(SONET/SDH Payload)にマッピングする規格(例えば、ITU-T X.86、ITU-T G.7041 GFP)も標準化されつつある。
【０００５】
ところで、提供するサービスの品質を保証する為、SONET/SDH通信装置間におけるデータ・リンク層のリンク状態の監視を確実に行う必要がある。
【０００６】
企業等のエンド・ユーザは、通常、専用線やイーサネットを介してインターネットや遠方に位置するイントラネットにアクセスするために、通信事業者によって提供されるSONET/SDHネットワークを利用する。なぜなら、SONET/SDHネットワークによって提供されるサービスの品質が高いからである(例えば、障害時の伝送路切替えによる迅速な復旧等)。
【０００７】
通常、SONET/SDH通信装置間のデータ転送について、ＰＰＰがデータ・リンク層のプロトコルとして利用される(PPP over SONET/SDH:“ＰＯＳ”と呼ばれる)。図１０は、ＰＰＰを利用してSONET/SDH通信装置間でＬＡＮを相互接続する例を示す図である。
【０００８】
図１０において、各通信装置(通信装置１および２)は、アクセス回線にイーサネットを実装し、イーサネット信号をＰＰＰにカブセル化し、それをSONET/SDHのPayloadにマッピングすることでSONET/SDH信号として転送する装置である。
【０００９】
各通信装置は、100BASE-TXやGigabit Ethernet等のＭＡＣフレームを終端するＭＡＣ部、ＭＡＣフレームをＰＯＳフレームにマッピングするＰＰＰ部、ＰＯＳフレームをSONET/SDH PayloadにマッピングするＳＴＳ部より構成される。実際には、SONET/SDH Payloadをクロス・コネクトする部分やOC-48といった標準フォーマットに変換する部分も存在するがここでは省略する。
【００１０】
ＭＡＣ部で終端されたイーサネット信号は、ＰＰＰ部にてHDLC-Likeフレームにマッピング(Mapping)される。図１１は、ＰＯＳのフレーム構成を示す図である。図１１の最初の行(最上段)に記載されたフレームフォーマットは、HDLC-Likeフレームの構造を示す。
【００１１】
ＭＡＣ部で終端されたイーサネット信号(ユーザ・データ)は、HDLC-Likeフレームの“情報”フィールドに挿入される。情報フィールドの内容は、“プロトコル”フィールドに設定される値により識別される。例えば情報フィールドに挿入されるユーザ・データの上位層がＩＰならばプロトコルフィールドの値は“0x0021”に設定される。
【００１２】
ＰＰＰは、データ・リンク層のプロトコルである。このため、ＰＰＰ終端部(図１０に示した各通信装置１および２のＰＰＰ部)の間でリンク確立の手順を実行する必要がある。リンクが確立した後に、通信装置間でデータ(ユーザ・データ)の伝送が可能になる。ＰＰＰでは、ＬＣＰ(Link Control Protocol：リンク制御プロトコル)によるリンク確立手順が規定されている。図１１には、ＰＯＳでのＬＣＰフレームが定義されている。
【００１３】
ＬＣＰフレームは、ユーザ・データと同様に、図１１の最初の行(最上段)に示すHDLC-Likeフレーム構造を持つ。但し、ＬＣＰフレームは、図１１の２行目(上から２段目)に示すように、ユーザ・データに対するHDLC-Likeフレームと同様に、プロトコルフィールドと、情報フィールドと、パディング(Padding)フィールドとを持つ。情報フィールドには、ＬＣＰに係るデータが挿入され、プロトコルフィールドには、ＬＣＰを示す値(LCP=0xC021)がセットされる。パディングフィールドは、情報フィールドのデータ長を規定以上に保つ為の詰め物である。
【００１４】
図１１の３および４行目(上から３および４段目)には、ＬＣＰフレームの情報フィールド内の構成が定義されている。“Code”フィールドはＬＣＰリンク制御に関する各種要求・応答を識別するための値がセットされる。“Code”フィールドに続く“Identifier”,“Length”,“Data/Option”フィールドの値はＬＣＰリンク制御要求・応答の種類に依存する。なお、HDLC-Likeフレームのフォーマットは、下記の非特許文献１，非特許文献２で説明されている。
【００１５】
図１２は、図１０に示すような通信装置間で行われるＬＣＰリンク制御の手順を示すシーケンス図である。図１２に示すように、上位層からのリンク確立要求，または装置の電源オンもしくはリセット等の外部要因により、ＬＣＰリンクを確立する場合には、通信装置１および通信装置２のＰＰＰ部間で、“ＬＣＰリンク設定要求フレーム”と、ＬＣＰリンク設定要求フレームに対する“ＬＣＰリンク設定確認フレーム”とを送受信する手順が行われる。そして、双方におけるＬＣＰリンク設定確認フレームの受信を以ってリンクが確立する(ＬＣＰリンク・オープン状態)。
【００１６】
その後、ＬＣＰにてオプションとして提供される認証手順が必要に応じて起動される。その後、上位層からのリンク切断要求や外部要因によりリンクを切断する場合には、通信装置１および通信装置２のＰＰＰ部間で“ＬＣＰリンク終了要求フレーム”と“ＬＣＰリンク終了確認フレーム”との送受信という手順を踏む(ＬＣＰリンク・クローズ状態)。なお、上記したＬＣＰリンク・オープンシーケンスは非特許文献３に、ＬＣＰリンク・クローズシーケンスは非特許文献４に開示されている。
【００１７】
上記したようにＰＰＰは、装置(ＰＰＰ部)間でリンクを確立する。このため、通信装置間の信号断(光ファイバの切断)等によりリンクが切断される場合を考慮する必要がある。リンクが切断された後は、ユーザ・データの転送を保証できなくなるので、再びリンク確立(リンク再確立)の手順を踏む必要がある。
【００１８】
ＰＰＰでは、アナログ(電話)回線でモデム利用を想定した物理層(Carrier Detect信号を利用)でのリンク状態監視と共に、ＬＣＰメッセージによるリンク状態監視手順を規定している。前者の物理層監視はＰＯＳに適用することができない。後者では、図１２に示すように、ＬＣＰリンク・オープン状態において、リンク状態を調べたい側(検査側：例えば、図１０に示す通信装置１)が“LCP ECHO要求フレーム”を送信する。LCP ECHO要求フレームを受信する側(応答側：例えば、図１０に示す通信装置２)は、LCP ECHO要求フレームを受信すると“LCP ECHO応答フレーム”を返答する。検査側は一定時間(応答待ちタイマで定義される時間)が経過する前に“LCP ECHO応答フレーム”を応答側から受信した場合はリンク状態は正常と判定し、受信できなかった場合はリンク状態は異常と判定する。
【００１９】
ただし、リンク状態監視について、手順は規定されているが、その実装(機能を実装するか、機能を有効にするか、応答待ちタイマの値をどの位にするか、断検出時に保護を持たせるか、等)は任意である。通常はこのリンク監視機能を有効にしていないか、有効にしていても断判定に保護(一定時間待ってリトライを何回か行う)を持たせている。なお、上記した“LCP ECHO要求フレーム”および“LCP ECHO応答フレーム”は非特許文献５に開示されている。
【００２０】
また、本発明に関連する先行技術として、非特許文献６に記載されるようなＰＰＰにおけるネゴシエーション機能、IEEE 802.3x(フロー制御)で規定されるようなPause(ポーズ)フレームがある。
【００２１】
【非特許文献１】
Network Working Group、“Request For Comments: 1662, PPP in HDLC-Like Framing, 3.1 Frame Format”、[online]、1994年7月、Internet Engineering Task Force、[平成１４年１１月２８日検索]、インターネット＜ URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献２】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 2. PPP Encapsulation”、[online]、1994年7月、Internet E ngineering Task Force、[平成１４年１１月２８日検索]、インターネッ ト＜URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献３】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 3.4 Link Establishment Phase”、[online]、1994年7月、In ternet Engineering Task Force、[平成１４年１１月２８日検索]、イン ターネット＜URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献４】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 3.7 Link Termination Phase”[online]、1994年7月、Intern et Engineering Task Force、[平成１４年１１月２８日検索]、インター ネット＜URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献５】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 5.8 Echo-Request and Echo-Reply”、[online]、1994年7月、Internet Engineering Task Force、[平成１４年１１月２８日検索]、イ ンターネット＜URL:http://rfc-jp.nic.ad.jp/＞
【非特許文献６】
Network Working Group、“Request For Comments: 1661, Point-to-PointProtocol, 4. The Option Negotiation Automation”、[online]、1994年7月、Internet Engineering Task Force、[平成１４年１１月２８日検索 ]、インターネット＜URL:http://rfc-jp.nic.ad.jp/＞
【００２２】
【発明が解決しようとする課題】
上述したように、ＰＯＳでは物理層でのリンク監視方法、すなわちリンク切れおよびその復旧判定手順や条件が規定されていない。故にＬＣＰメッセージによるデータ・リンク層のリンク監視で物理層でのリンク監視を代用することが余儀なく行われている。ここで、ＬＣＰメッセージによるリンク監視は下記問題を有している。
【００２３】
(１) 負荷によりリンク状態を誤認する虞がある。ユーザ・データがバースト的に許された帯域を超過する状態が頻発した場合には、一方の通信装置(検査側)がLCP ECHO要求フレームを送信しても、他方の通信装置(被応答側)がユーザ・データの処理に追われてLCP ECHO応答フレームの返答に遅れると、応答待ちタイマがタイム・アウトする可能性がある。この場合、リンク状態は実際には正常で、負荷により一時的に応答側による応答が遅れただけである。しかしながら、検査側はリンクが切断されたと誤認してしまう。
【００２４】
(２) 問題(１)を防止する為に検査側での断判定に保護(一定時間待ってリトライを何回か実施し、リンク断を指定された回数連続で検出することで、リンク断と判断する)を適用すると、リンク断が実際に発生している場合において検査側が“リンクが切れている”と判定するまでの時間が長くなる。これによって、サービスに支障を来たす期間(リンク切れから復旧までの期間)が延伸する虞がある。
【００２５】
(３) ＬＣＰメッセージによるリンク監視機能が実装されていない、またはリンク監視機能が実装されていても有効に設定されていない場合には、リンク断の判定が実施されない。
【００２６】
(４) SONET/SDH通信装置特有の問題がある。SONET/SDH通信装置はクロス・コネクト機能を有する。クロス・コネクトに対する設定の変更はＰＰＰリンクに影響を与える可能性がある。よって、外線(この場合光信号)の状態をリンク状態の判定に適用するのに加え、クロス・コネクト状態もリンク状態の判定条件として定義する必要がある。外線及びクロス・コネクト状態の監視は、通常ハードウェアまたはファームウェアにより行われる。このような間接的な事象でリンク状態を推測する方法では、監視対象の事象が多い場合には、処理が煩雑になる。また、監視対象の事象が追加された場合はハードウェア又はファームウェアの変更を余儀なくされる。もし、間接的な事象ではなく、これら間接的事象を引き起こす共通の(直接的な)事象をもってリンク状態の判定が可能になれば、このような処理の煩雑さや将来における変更の必要はなくなる。
【００２７】
(５) ＰＰＰリンクが切れた状態では、アクセス回線(イーサネット)側から受信したイーサネット・フレームはSONET/SDH通信装置で廃棄される。このとき、そのイーサネット・フレームを送信した装置(例えば通常のLANスイッチや端末)にはイーサネット・フレームが廃棄されたことが通知されない。なぜなら、リンク状態を監視するＰＰＰ部とイーサネット・フレームを終端するＭＡＣ部は相互に独立しており、ＰＰＰ部からＭＡＣ部にリンク状態を通知する術がなく、更にリンク状態を通知してフロー制御(イーサネット側に対してフレーム送信の一時中断や送信再開を指示する)を実施するという規格が存在しないからである。上記したフレーム廃棄は、ＰＰＰリンク断状態が復旧しリンクが再確立された時点で解除される。ところが、リンク状態が正常になったこともＰＰＰ部からＭＡＣ部に通知されない。このため、イーサネット・フレームの送信側(LANスイッチや端末側)は、リンクが切れている期間に送信したユーザ・データに対する再送等による保護を何ら適用することができない。
【００２８】
(６) 一つのSONET/SDH通信装置に対して他の複数の装置がスター型で接続される運用形態(Server-Client(サーバ-クライアント)型のネットワーク構成)において、Server側装置から定期的にLCP ECHO要求フレームを送信しリンク状態を監視する場合がある。この場合には、接続されるClient側装置の数が多くなる程リンク監視に要する処理が増大し、ユーザ・データ自身を処理する能力を低下させる虞がある。この形態は、本店と各支店を接続しかつ各支店間での通信が不要な場合やセキュリティ上の理由で本店経由でインターネットや別の支店との接続を許容する場合に一般的に適用される。
【００２９】
本発明は、上述した問題に鑑みなされたものであり、迅速なリンク状態の判定を可能とする通信装置を提供することを目的とする。
【００３０】
また、本発明の他の目的は、リンク状態の判定の確実性が向上する通信装置を提供することである。
【００３１】
また、本発明の他の目的は、リンク状態に基づくフロー制御が可能な通信装置を提供することである。
【００３２】
【課題を解決するための手段】
本発明は、上述した目的を達成するために以下のような手段を採用する。すなわち、本発明は、対向装置との間で確立されるデータリンク層のリンクが正常な場合に、このリンクを通じて或る間隔内で順次到着するフラグを受信する受信手段と、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定する判定手段と、を含む通信装置である。
【００３３】
本発明によれば、或る間隔内で順次到着するフラグの受信状態を監視し、フラグが或る間隔内で受信できなくなればリンク切れと判定することができる。これによって、従来の手法(ＬＣＰリンク保守シーケンス)に比べて、リンク切れの判定を迅速に行うことができる。また、リンク切れの判定を確実に行うこともできる。
【００３４】
本発明は、前記判定手段によって前記リンクが切れていると判定された場合にリンク終了フェーズに移行して、このリンクを終了させるように構成するのが好ましい。
【００３５】
また、本発明は、前記判定手段の有効または無効を前記対向装置との間でネゴシエーションするネゴシエーション手段をさらに含むように構成するのが好ましい。
【００３６】
また、本発明は、対向装置との間で確立しているデータ・リンク層のリンクに、データの送信元から受信する送信対象のデータを送出する手段と、
前記リンクのリンク切れの検出に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるデータ送信制御手段とを含む通信装置である。
【００３７】
本発明によれば、リンク切れによってリンクが終了される場合に、データの送信元からのデータ送信を停止させることができる。これによって、通信装置が送信元から受信したデータを廃棄してしまうことを防止することができる。
【００３８】
また、本発明は、前記データ送信制御手段は、前記リンクを再確立した場合に、前記データの送信元にデータ送信を再開させるように構成するのが好ましい。
【００３９】
また、本発明は、対向装置との間で確立されるデータリンク層のリンクが正常な場合にこのリンクを通じて所定時間内で順次到着するフラグを受信するステップと、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定するステップと、を含む通信装置のデータリンク監視制御方法である。
【００４０】
また、本発明は、上記した判定手段を含み、通信装置に実装される、データリンク層のリンク監視装置として特定することも可能である。
【００４１】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。実施の形態における構成は例示であり、本発明は実施の形態の構成に限定されない。
【００４２】
〔本発明の概要〕
本発明の概要を説明する。図１(Ａ)は、PPP over SONET/SDH(ＰＯＳ)フレームの説明図であり、図１(Ｂ)は、フラグの説明図であり、図１(Ｃ)は、ＰＰＰのパケットがやりとりされている状態の説明図であり、図１(Ｄ)は、アイドル状態の説明図である。
【００４３】
図１(Ａ)に示すＰＯＳフレームは、データの送信側と受信側との間で確立したデータ・リンク層のリンク(例えばＰＰＰリンク)上を伝送される。ＰＯＳフレーム１０は、ＰＰＰフレームの一つであり、図１１に示したようなHDLC-Likeフレーム構造を持つ。
【００４４】
ＰＯＳフレーム１０を用いてユーザ・データが伝送される場合には、ユーザ・データはＰＯＳフレーム１０の“情報”フィールドに挿入される。但し、本発明は、情報フィールドの中身には依存しない。
【００４５】
ユーザ・データは、自装置又は対向装置にて送信要求があった場合にのみ送信される性質のものであり、回線(リンク)上を常に流れている訳ではない。ユーザ・データやその他の制御データが流れていない時(アイドル状態)では、図１(Ｂ)に示すようなフラグ２０(ＨＤＬＣのフラグと同様の“0x7E”または“01111110b”の値を持つ)を常に流すことがRFC1662等で規定されている。
【００４６】
即ち、送信側は対向装置(受信側)に送信すべきデータ(送信対象のデータ)が何もない場合にはフラグを常に送信する必要がある。従って、送信側と受信側との間で送信対象のデータがが送受信される場合には、リンク上の状態は、図１(Ｃ)の３０に示すＰＰＰのパケットがやりとりされている状態(フラグと、送信対象のデータを含むＰＰＰフレーム(ＰＯＳフレーム)とがシリアルに転送される状態)となり、送信側で送信対象のデータがない場合には、リンク上の状態は図１(Ｄ)の４０に示すアイドル状態(フラグのみがシリアルに転送される状態)となる。このように、確立されたリンクが正常である場合には、そのリンクを通じてフラグが所定の間隔内で受信側に順次到着する。
【００４７】
一方、受信側は、回線状態(リンク状態)が正常でリンクが確立されている状態では対向装置からユーザ・データや制御データを受信しない場合でもフラグを常に(所定の間隔内で)受信するはずである。そして、受信側は、回線状態に何らかの異常が発生した場合には、フラグを受信できなくなる。このため、受信側でフラグの受信状態を監視すれば、リンク状態の正常／異常を判定することができる。
【００４８】
図２は、本発明に係る通信装置の構成を示す図である。図２には、本発明に係る通信装置としてのSONET/SDH通信装置Ａに搭載されるＰＰＰ部４５の構成が示されている。ＰＰＰ部４５(設定手段，ネゴシエーション手段，リンク監視手段，リンク監視装置に相当)は、PPP over SONET/SDH(ＰＯＳ)制御部５０(受信手段，判定手段に相当)とリンク制御部６０(リンク制御手段，データ送信制御手段に相当)とを備えている。
【００４９】
ＰＯＳ制御部５０は、従来の機能(ＭＡＣ制御部６１(図１０に示すＭＡＣ部に相当)で終端されたＭＡＣフレームをＰＯＳフレームにマッピングする機能、およびＳＴＳ部(図１０参照)で終端されたＰＯＳフレームを受信してＭＡＣフレームにマッピングする機能)に加えて、ＰＯＳフレームのフラグ受信状態を監視する。すなわち、ＰＯＳ制御部５０は、リンクを通って或る間隔内で順次到着するフラグを受信するように構成されている。
【００５０】
リンク制御部６０は、上位層からの要求やその他外部要因という従来の事象に加えて、ＰＯＳ制御部５０から通知されるＰＯＳフレームのフラグ受信状態情報を監視し、それに基づいてリンク状態制御をＰＯＳ制御部５０に対して行う。
【００５１】
SONET/SDH通信装置１００のＰＰＰ部４５間でＰＰＰリンク確立手順が踏まれた後、ＰＰＰリンクが確立している状態(ＬＣＰリンク・オープン状態)で、ＰＯＳ制御部５０は、対向装置からのフラグ受信の有無を判定する。
【００５２】
即ち、ＰＯＳ制御部５０は、所定時間を計時するリンク断監視タイマ(監視タイマ)５１を有し、フラグを受信する毎に監視タイマ５１を起動する。監視タイマ５１の値(監視タイマ５１で計時する所定時間)は、通常状態でリンク断を検出しないことを保証する(ビット)時間とする。
【００５３】
ＰＯＳにおけるフレーム最大長は1,500バイト程度であり、フレームが最大長である場合には、フラグ(データの開始)から次のフラグ(データの終了または2つの連続したフレーム間に挿入される)までの期間は、1,531バイト = 1,531×8 = 12,248ビット時間(フラグ: 1バイト、アドレス: 1バイト、制御: 1バイト、プロトコル: 2バイト、ユーザ・データ: 最大1,522バイト、FCS: 4バイトの合計)となる。このため、最低でも上記期間が経過するまではリンク断と判定しない(タイマがタイムアウトにならない)ように所定時間が設定される。但し、監視タイマ５１の値(所定時間)があまり長く設定されると、実際にリンクが切れている場合の判定が遅くなる。このように、監視タイマ５１に設定される所定時間は、リンク正常時におけるフラグの到着間隔の最大値よりも長く設定することができる。
【００５４】
ＰＯＳ制御部５０は、所定期間フラグを受信しなかった場合には、監視タイマ５１をタイム・アウトさせ、監視タイマ５１のタイム・アウトをリンク制御部６０に通知する(図２の“リンク状態”と書かれた矢印を参照)。
【００５５】
図３は、ＰＯＳ制御部によるリンク断判定処理手順を示す図である。図３において、ＬＣＰリンク・オープン状態(ＬＣＰリンク確立状態)になった時(ステップＳ２００)、ステップＳ２０１にてフラグ監視機能が有効であるか、無効であるかが判断され、有効であれば(Ｓ２０１；ＹＥＳ)、ＰＯＳ制御部５０によるフラグ監視が行われ、無効であれば(Ｓ２０１；ＮＯ)、フラグ監視が行なわれない(ステップＳ２０２：監視停止(これについては後述する))。
【００５６】
フラグ監視が行なわれる(有効である)場合には、ＰＯＳ制御部５０は、ステップＳ２０３にてフラグの受信を待ち、フラグの受信を確認すると、ステップＳ２０４にて監視タイマ５１による計時を開始し、次のフラグの受信判定(ステップＳ２０５)と、監視タイマ５１のタイムアウト判定(ステップＳ２０６)とを含むループ処理を、次のフラグが受信されるか(Ｓ２０５；ＹＥＳ)、または監視タイマ５１がタイムアウトになる(Ｓ２０６；ＹＥＳ)まで、繰り返し実行する。
【００５７】
ＰＯＳ制御部５０は、ステップＳ２０６にて監視タイマ５１のタイムアウト(所定時間の計時)を検知すると(Ｓ２０６；ＹＥＳ)、リンク状態(リンク異常：リンク断判定)をリンク制御部６０に通知し、リンク制御部６０にＬＣＰリンクを終了させる(リンク終了フェーズに移行する：ステップＳ２０７)。
【００５８】
これに対し、ＰＯＳ制御部５０は、監視タイマ５１がタイムアウトする前に、ステップＳ２０５にて次のフラグを受信した場合には、リンクが正常であるものとして、監視タイマ５１を停止させ(ステップＳ２０８)、次のフラグの受信を監視するため、監視タイマ５１を再起動(リセット)する(ステップＳ２０４)。
【００５９】
リンク制御部６０はステート・マシンである。図４は、リンク制御部６０の状態遷移図である。図４には、ＰＰＰで規定されるリンク制御の状態遷移(“RFC1661(Point-to-Point Protocol) 3.2 Phase Diagram”参照)に、本発明に係るフラグ受信監視条件が加えられた状態遷移図が示されている。
【００６０】
図４は、リンク制御部６０にて管理される状態遷移を示す。図４において、１００はリンク停止フェーズであり、物理的あるいは電気的に動作していない状態を示す。物理的あるいは電気的に動作している状態になると、リンク確立フェーズ１０１に移行し、ここでリンクを確立するためにＬＣＰリンク設定要求・確認フレームをお互いに交換する。
【００６１】
ＬＣＰリンク設定要求・確認フレームの交換が正常に完了すると、ＬＣＰリンク・オープン状態１１０となる。この後、ネットワーク層プロトコルフェーズ１０３の前に、必要ならば認証プロトコル１０２が実行される。なお、この認証プロトコルは実施を省略することができる。
【００６２】
ネットワーク層プロトコルフェーズ１０３では、実装されるネットワーク層プロトコルに対応したＮＣＰ(Network Control Program：ネットワーク制御プログラム)がそれぞれ実行される。これによって、ＮＣＰリンク・オープン状態１１１となる。
【００６３】
その後、ＬＣＰリンクを終了する場合は、リンク終了フェーズ１０４に状態を遷移させて、ＬＣＰリンクを終了する。すると、状態がＬＣＰリンク・クローズ状態１１２となる。
【００６４】
リンク制御部６０は、ＬＣＰリンク・オープン状態１１０のときにＰＯＳ制御部５０から通知されるリンク状態情報に基づいてリンク監視を行ない、リンク状態情報からＬＣＰリンクが切れていること(ＬＣＰリンク断)を検出すると、状態をリンク終了フェーズ１０４に遷移させる。このように、ＬＣＰリンクが切れたこと(の検出)がＬＣＰリンクオーブン状態１１０からリンク終了フェーズ１０４への状態遷移のトリガとなっている。
【００６５】
リンク制御部６０がリンク終了フェーズ１０４に遷移すると、自装置と対向装置との間でＬＣＰリンク・クローズ・シーケンス(図１２)が実施され、ＬＣＰリンク・クローズ状態１１２に遷移する。
【００６６】
上記したリンク切れは、データ・リンクが確立される物理リンク(光ファイバ)の切断によって発生する。このような障害は、光ファイバの交換により復旧する。このような物理リンク(光ファイバ)の復旧は、物理層における信号の送受信により検出可能である。リンク制御部６０は、物理層で検出される物理リンクの復旧を検出した場合には、リンク確立フェーズ１０１に移行して、データ・リンク層のリンクを再確立する。
【００６７】
ところで、対向する通信装置の一方に本発明に係る構成(ＰＯＳ制御部５０によるフラグ監視機能)が適用され、他方がアイドル状態でフラグを送信しないこと(フラグ監視機能を持たない)が想定される。この場合には、一方の通信装置が受信側になると、常にリンク断を検出することになる。このようなケースを考慮し、本発明に係る通信装置は、上述したリンク断監視機能を有効にするか無効にするかを設定する機能(有効／無効設定機能)をさらに具備することができる。
【００６８】
図３には、有効／無効設定機能が付加されている場合の処理がステップＳ２０１および２０２として示されている。上述したように、監視機能が“有効”に設定されている場合には、ステップＳ２０１で“ＹＥＳ(有効)”と判定され、上述したフラグ監視機能が動作する(Ｓ２０３〜Ｓ２０７)。これに対し、フラグ監視機能が“無効”に設定されている場合には、ステップＳ２０１で“ＮＯ(無効)”と判定され、監視機能が動作せず(Ｓ２０２)、フラグを受信しない状態でもリンク断は検出されない。
【００６９】
但し、本発明に係る通信装置のＰＰＰ部４５は、LCP ECHO要求フレームによるリンク状態監視機能(図１２参照)を具備し、フラグ監視機能が“無効”である場合には、このリンク状態監視機能を動作させるように構成することが可能である。これによって、本発明に係るリンク状態監視機能を適用していない通信装置とのデータ・リンク層のリンク(ＰＰＰリンク)の相互接続を保証することができる。
【００７０】
さらに、上述した監視機能の有効・無効設定はユーザ・インターフェースを用いて実施することができる。この場合、対向する通信装置毎に設定を実施せねばならない。この場合、監視機能の有効・無効設定を通信装置毎に実施するのは手間がかかる。また、対向する通信装置の一方が有効に設定され、他方が無効に設定される等の通信装置間における矛盾が発生する可能性がある。
【００７１】
このため、ＬＣＰが提供するネゴシエーション機能を利用して、対向する通信装置の一方における設定を他方の通信装置に自動的に反映させる手法を採用することができる。
【００７２】
図５は、監視機能の有効／無効の設定をＬＣＰに定義する場合のフォーマット(監視機能の有効・無効設定が定義されたＬＣＰフレームのフォーマット)を示す図である。
【００７３】
図５において、プロトコル・フィールドの値は、“LCP(0xC021：既存)”であり、情報フィールドの“Code”の値は“Configure-Request(既存)”に設定される。さらに、Data/Optionフィールドに対し、新規に“Type=0x0A(0Ah):
リンク断監視機能”、“Data=0x0000(0000h:有効)/0x0001(0001h:無効)”というリンク断監視設定が定義される。このような監視設定の定義を含むData/Optionフィールドを通信設定オプション３０１と呼ぶ。
【００７４】
図４に示したＬＣＰリンク確立フェーズ１０１では、ＬＣＰリンク確立とＬＣＰ通信設定を行なうためにLink Configurationフレーム(Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject)を用いたネゴシエーションが通信装置間で実施される。Configure-Requestフレームは、ＬＣＰ通信設定要求を行なうものである(通信設定を装置間でネゴシエーションする)。このConfigure-RequestフレームのData/Optionフィールドに対し、図５に示した通信設定オプション301を定義する。
【００７５】
リンク断監視機能のデフォルトは無効に設定される。ＬＣＰリンク確立フェーズ１０１において、最初に、通信装置の一方は、ネゴシエーション側として、通信設定オプション３０１に“有効”を指定してネゴシエーションを行う。通信装置の他方が相手側として“有効”の指定を受諾した場合には、通信装置の一方は、ＬＣＰリンクが確立した後に“有効”の設定に基づいてリンク断監視動作を行う。これに対し、相手側が“有効”の指定を拒否した場合には、監視機能を“無効”に設定し、ＬＣＰリンクが確立してもリンク断監視動作は行なわない。
【００７６】
上記した構成(ネゴシエーション機能)により、ユーザがリンク断監視を有効にするか無効にするかを通信装置毎に設定する手間を省き、また対向装置間での設定矛盾を回避することが可能になる。なお、ネゴシエーション機能については、“RFC1661(Point-to-Point Protocol) 4. The Option Negotiation Automation”に規定されている。
【００７７】
図６は、ネゴシエーションにおいて監視機能の有効設定が受諾されるケースを示すシーケンス図であり、図７は、ネゴシエーションにおいて監視機能の有効設定が拒否されるケースを示すシーケンス図である。
【００７８】
図６において、対向する通信装置Ｘと通信装置Ｙ(それぞれフラグ監視機能および通信設定オプション３０１の認識機能を持つ)とがＰＰＰリンクを確立する場合には、ＬＣＰリンク・オープンシーケンス(リンク・オープンフェーズ)において、最初に、通信装置の一方(図６では通信装置Ｘ)は、相手方(通信装置Ｙ)に対し、“有効”が設定されたＬＣＰリンク設定要求フレーム(“有効”が設定された通信設定オプション３０１を含むConfigure-Requestフレーム)を送信する(ステップＳ６０１)。
【００７９】
このとき、相手側(通信装置Ｙ)が“有効”設定を受諾し、かつConfigure-Requestフレーム内のその他の通信設定オプションの全てを受諾する場合には、通信装置ＹはConfigure-Ack(通信設定肯定応答)フレームを送信する(ステップＳ６０２)。
【００８０】
また、通信装置Ｙは、通信装置Ｘに対し、“有効”が設定された通信設定オプション３０１を含むConfigure-Requestフレームを送信する(ステップＳ６０３)。これに対し、通信装置Ｘは、Configure-Requestフレーム内の“有効”設定を含む全ての通信設定オプションを受諾する場合には、Configure-Ackフレームを通信装置Ｙへ送信する(ステップＳ６０４)。
【００８１】
このようにして、通信装置ＸおよびＹは、相手側からのConfigure-Ackフレームを受信することでＬＣＰリンクを確立し、フラグ監視機能を有効に設定する。これによって、通信装置ＸおよびＹでフラグ監視動作がそれぞれ実施される。
【００８２】
図７において、対向する通信装置Ｘ(フラグ監視機能および通信設定オプション３０１の認識機能を持つ)と通信装置Ｙ(フラグ監視機能および通信設定オプション３０１の認識機能を持たない)とがＰＰＰリンクを確立する場合には、ＬＣＰリンク・オープンシーケンス(リンク・オープンフェーズ)において、通信装置の一方(図７では通信装置Ｘ)が、ステップＳ６０１と同様に、最初に、ステップＳ６０１と同様に、相手方(通信装置Ｙ)に対し、“有効”が設定されたＬＣＰリンク設定要求フレーム(“有効”が設定された通信設定オプション３０１を含むConfigure-Requestフレーム)を送信する(ステップＳ７０１)。
【００８３】
このとき、通信装置Ｙは、通信オプション３０１の“有効”設定を認識できないのでＬＣＰリンク設定要求を拒否する。通信装置Ｙは、ＬＣＰリンク設定要求を拒否する場合には、ＬＣＰリンク設定拒否フレーム(Configure-Reject(通信設定拒否)フレームを通信装置Ｘへ送信する(ステップＳ７０２)。
【００８４】
通信装置Ｘは、Configure-Rejectフレームを受信すると、監視機能設定を指定した通信設定オプション３０１を含まないConfigure-Requestフレームを通信装置Ｙへ送信する(通信オプション３０１なしでネゴシエーションをやり直す：ステップＳ７０３)。
【００８５】
一方、通信装置Ｙは、通信装置Ｘに対し、ネゴシエーション対象の通信設定オプションを含まないConfigure-Requestフレーム(通信設定オプション３０１を含まない)を通信装置Ｙへ送信する(ステップＳ７０４)。
【００８６】
通信装置Ｙは、Configure-Requestフレーム内の通信設定オプションを受諾する場合には、Configure-Ackフレームを通信装置Ｘへ送信する(ステップＳ７０５)。
【００８７】
通信装置Ｘも、通信装置ＹからのConfigure-Requestフレーム内の通信設定オプションを受諾する場合には、Configure-Ackフレームを通信装置Ｙへ送信する(ステップＳ７０６)。
【００８８】
このようにして、通信装置ＸおよびＹは、相手側からのConfigure-Ackフレームを受信することでＬＣＰリンクを確立する。このとき、通信装置Ｘは、フラグ監視機能を無効に設定する。したがって、通信装置Ｘは、フラグ監視動作を実施しない。一方、通信装置Ｙは、フラグ監視機能を持たないので、フラグ監視動作を行わない。
【００８９】
なお、図７において、通信装置Ｙがフラグ監視機能および通信オプション３０１の認識機能を持つ場合でも、所定の条件に従って“有効”設定に対するＬＣＰ設定拒否フレームを相手方に送信するように構成することができる。このとき、ＬＣＰ設定拒否フレームを受信した側は、通信オプション３０１を含まないＬＣＰ設定要求フレーム，または“無効”が設定された通信オプション３０１を含むＬＣＰ設定要求フレームを送信しなおすことができる。
【００９０】
ところで、本発明に係る通信装置Ａは、イーサネット(IEEE 802.3で規定されたネットワーク)を収容しており、イーサネットからのイーサネットフレームをＭＡＣ制御部６１で終端し、ＰＰＰ部でイーサネットフレームをＰＯＳフレームにカプセル化して確立済みのＰＰＰリンクへ送出する。
【００９１】
上述したＰＯＳ制御部５０およびリンク制御部６０の構成により、対向装置でＰＰＰリンクが切れていることが検出された場合には、対向装置におけるリンク制御部６０は、リンク終了フェーズ１０４(図４)に状態遷移し、対向装置間でＬＣＰリンク・クローズ・シーケンス(図１２)が実施され、各通信装置がＬＣＰリンク・クローズ状態となる。
【００９２】
ところが、イーサネットフレームの送信側の装置は、ＰＰＰリンクが切れたことを認識できないので、イーサネットフレームを送信し続ける。このような問題に鑑み、本発明に係る通信装置Ａは次の構成を持つ。
【００９３】
すなわち、通信装置Ａのリンク制御部６０は、図２に示すように、ＰＰＰ(ＬＣＰ)リンクの状態に基づいて、通信装置Ａに搭載されたＭＡＣ制御部６１に対するフロー制御を起動する。
【００９４】
すなわち、リンク制御部６０は、(１)リンク断状態(すなわちＬＣＰリンク・クローズ状態(図４の１１２参照))への遷移を契機として、ＭＡＣ制御部６１に対し、IEEE 802.3x(制御フロー)にて規定されるPauseフレーム(送信中断)をイーサネット側に送信させる制御と、(２)リンク復旧状態(ＬＣＰリンク・オープン状態(図４の１１０参照))への遷移を契機として、ＭＡＣ制御部６１に対し、Pauseフレーム(送信再開)をイーサネット側に送信させる制御を実施する。
【００９５】
IEEE 802.3xで規定されるフロー制御は、次の構成(機能)を持つ。全二重のイーサネット回線から受信するイーサネット・フレームを一旦バッファに蓄積し、そのバッファにフロー制御を起動するしきい値と解除するしきい値を定義する。フレーム量が起動しきい値を超えた場合には、イーサネット回線に対して送信中断を要求するPauseフレームというコマンドを送信する。一方、フレーム量が解除しきい値を下回った場合にはイーサネット回線に対して送信再開を示すPauseフレームを送信する。
【００９６】
フレーム量が起動しきい値を越えるような状況は、イーサネット回線から一時的に転送可能な帯域を超えるフレームを受信した場合に発生する。また、イーサネット回線の帯域に対してそれをマッピングするSONET/SDH信号の帯域が小さい(例えば1Gbpsのイーサネット回線をSTS-12c=622Mbpsにマッピングする)場合に発生する。
【００９７】
送信中断を示すPauseフレームを受信したイーサネット側の(対向)装置は、Pauseフレーム中の中断時間フィールドで指定されたビット時間が経過するまでの間イーサネット・フレームの送信を停止しなければならない。そして、送信再開を示すPauseフレーム(中断時間フィールドが“０”のPauseフレーム)を受信すると、イーサネット・フレームの送信を再開する。
【００９８】
図８は、Pauseフレームのフォーマットを示す図である。PauseフレームはＭＡＣフレーム構造を持つ。図８において、“宛先アドレス”には、Pauseフレーム用に予約されたマルチキャスト・アドレスがセットされる。“送信元アドレス”は、Pauseフレームの送信側のＭＡＣアドレスがセットされるが、特に指定しなくても良い。
【００９９】
“長さ/タイプ”フィールドおよび“操作コード”フィールドには、固定値(各々“0x8808”、“0x0001”)が指定される。“中断時間”フィールドには、指定された０〜65,535の(可変)値がセットされる。ここで指定された値×512ビット時間が経過するまでの間フレームの送信が停止(中断)される。
【０１００】
“512ビット時間”は、転送速度により異なる。例えば、イーサネットが100Mbpsイーサネットである場合には、約5usecであり、最大の中断時間は約330msecとなる。リンクが切れた状態が中断時間を超えて継続する場合、ＭＡＣ制御部６１は定期的に(間隔は転送速度に依存する)Pauseフレーム(送信中断)を送信し、リンクが切れた状態から復旧した時点で中断時間=0のPauseフレーム(送信再開)を送信することでフロー制御を解除する。
【０１０１】
このように、本発明は、リンク状態の変化をPauseフレームの送信トリガとして定義する。これによって、イーサネット回線(アクセス回線)を介して対向する装置に対してリンクが切れている間、データ(イーサネット・フレーム)の送信を待機させ、リンク復旧時に送信再開させる。このようにして、イーサネット・フレームをＰＯＳフレームにカプセル化して転送する場合におけるデータ転送の整合性が保証される。
【０１０２】
〔本発明の実施例〕
図９は、本発明が適用されたSONET/SDH通信装置Ａ２の構成例を示す図である。図９において、ＰＯＳ制御部４００と、ファームウェア(リンク制御部)４０１と、ＭＡＣ終端部４０２と、ＳＴＳ終端部４０３と、クロス・コネクト部４０４とを備えている。
【０１０３】
ＭＡＣ終端部４０２は、図２に示したＭＡＣ制御部６１に相当し、イーサネット回線４０５からのＭＡＣフレーム(イーサネット・フレーム)を終端し、ＰＯＳ制御部４００に渡す。また、ＰＯＳ制御部４００からのＭＡＣフレームをイーサネット回線４０５に送出する。また、ＭＡＣ終端部４０２は、ファームウェア(リンク制御部)４０１からの指示に従って、イーサネット回線４０５を介して接続されたＭＡＣフレームの送信側の装置に対するPauseフレームの送信処理を行う。
【０１０４】
ＰＯＳ制御部４００は、図２に示したＰＯＳ制御部５０に相当する。ＰＯＳ制御部４００は、ＭＡＣ終端部４０２からのＭＡＣフレームをＰＯＳフレームにカプセル化してＳＴＳ終端部４０３に渡す。また、ＰＯＳ制御部４００は、ＳＴＳ終端部４０３からのＰＯＳフレームからＭＡＣフレームを取り出してＭＡＣ終端部４０２に渡す。さらに、ＰＯＳ制御部４００は、図３に示したようなリンク断判定処理手順を実行し、リンク状態(リンク切れ)をファームウェア４０１に通知する。
【０１０５】
ファームウェア４０１は、図２に示したリンク制御部６０を実現する。すなわち、ファームウェア４０１は、図５に示したような状態遷移を行い、リンク確立フェーズ１０１において、図６および図７に示すようなネゴシエーションを対向装置との間で行い、フラグ監視機能の有効／無効を設定する。また、フラグ監視機能の無効を設定した場合には、LCP ECHO要求／応答フレームの送受信処理を行う。
【０１０６】
また、ファームウェア４０１は、リンク状態通知をトリガとして、リンク終了フェーズに移行する。さらに、ファームウェア４０１は、ＬＣＰリンク・クローズ状態への遷移を契機(トリガ)として、送信中断を示すPauseフレームの送信をＭＡＣ終端部４０２に指示し、ＬＣＰリンク・オープン状態への遷移(リンク切れ復旧)を契機(トリガ)として、送信再開を示すPauseフレームの送信をＭＡＣ終端部４０２に指示する。
【０１０７】
ＳＴＳ終端部４０３は、ＰＯＳ制御部４００で生成されたＰＯＳフレームをSTS Payloadにマッピングしてクロス・コネクト部４０４に渡す。また、ＳＴＳ終端部４０３は、クロス・コネクト部４０４からのSTS PayloadからＰＯＳフレームを取り出してＰＯＳ制御部４００に渡す。
【０１０８】
クロス・コネクト部４０４は、ＳＴＳ単位でのクロス・コネクトを実施し、STS Payloadを含む光信号を任意の位置に接続し、SONET/SDH信号４０６として対向装置に送信する。
【０１０９】
〔実施形態の作用〕
実施形態で説明した通信装置によれば、PPP over SONET/SDHのようなデータ・リンク層のリンク監視処理として、従来の手法(LCP ECHO要求/応答フレームの送受信)の代わりにフラグ監視処理を行う。これによって、リンク状態監視の為のメッセージ交換(LCP ECHO要求/応答フレームの送受信)に費やす負荷をゼロにすることができる。また、従来の手法に比べて、迅速かつ確実にリンク切れの判定を行うことが可能になる。これによって、課題で述べたような(１)，(２)，(３)，(４)および(６)の問題を解決することができる。
【０１１０】
また、実施形態で説明した通信装置によれば、リンクが切れている間は、イーサネット・フレームを送信する装置に対して送信停止を要求することによりデータ喪失を防止し、リンクの復旧後に当該装置から送信できず蓄積されたデータ(イーサネット・フレーム)の送信を促す。これによって、課題で述べたような(５)の問題を解決でき、ユーザ・データの整合性を保証し、インターネットやイントラネット・アクセスを提供するサービスの品質を向上させることが可能になる。
【０１１１】
さらに、実施形態で説明した通信装置によれば、リンク監視機能を実装しない既存の通信装置との相互接続も、ユーザによる設定を必要とすることなく保証することが可能となる。
【０１１２】
〔その他〕
本実施形態は次の発明を開示する。各項に開示される発明は、必要に応じて可能な限り組み合わせることができる。
【０１１３】
（付記１） 対向装置との間で確立されるデータリンク層のリンクが正常な場合にこのリンクを通じて或る間隔内で順次到着するフラグを受信する受信手段と、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定する判定手段と、
を含む通信装置。（１）
（付記２） 前記判定手段は、前記受信手段が前記リンクからフラグを受信した場合に所定時間を計時するタイマを起動し、次のフラグが前記受信手段で受信される前に前記タイマがタイムアウトになった場合には、前記リンクが異常と判定する
付記１記載の通信装置。
【０１１４】
（付記３） 前記判定手段は、前記タイマがタイムアウトになる前に前記受信手段で次のフラグが受信された場合には、前記タイマをリセットし、前記リンクが正常と判定する
付記２記載の通信装置。
【０１１５】
（付記４） 前記判定手段によって前記リンクが異常と判定された場合に、このリンクを終了させる(リンク制御手段をさらに含む)
付記１〜３のいずれかに記載の通信装置。（２）
（付記５） (前記リンク制御手段は、)前記リンクを終了させた後に、前記リンクの復旧が可能な状態になった場合には、前記リンクを再確立する
付記４記載の通信装置。
【０１１６】
（付記６） 前記判定手段を有効または無効に設定する設定手段をさらに含む付記１〜５のいずれかに記載の通信装置。
【０１１７】
（付記７） 前記判定手段の有効または無効を前記対向装置との間でネゴシエーションするネゴシエーション手段をさらに含む
付記１〜６のいずれかに記載の通信装置。（３）
（付記８） 前記ネゴシエーション手段は、前記判定手段の有効または無効を問い合わせるための情報を前記対向装置に送信し、問い合わせに対する応答を前記対向装置から受信する
付記７記載の通信装置。
【０１１８】
（付記９） 前記ネゴシエーション手段は、前記判定手段の有効を示す情報を前記対向装置に送信し、
前記設定手段は、前記ネゴシエーション手段が前記判定手段の有効を拒否することを示す応答を前記対向装置から受け取った場合には、前記判定手段を無効に設定する
付記８記載の通信装置。
【０１１９】
（付記１０） 前記判定手段が無効に設定された場合に起動し、前記対向装置に前記リンクの正常を検査する検査フレームを送信し、前記対向装置から前記検査フレームに対する応答フレームを所定時間内に受信した場合に前記リンクが正常と判定するリンク監視手段をさらに含む
付記１０記載の通信装置。
【０１２０】
（付記１１） データの送信元から受信する送信対象のデータを前記リンクへ送出する手段と、
前記リンクの異常に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるデータ送信制御手段と
をさらに含む付記４記載の通信装置。
【０１２１】
（付記１２） 前記データ送信制御手段は、前記リンクが再確立される場合に、前記データの送信元にデータ送信を再開させる
付記１１記載の通信装置。
【０１２２】
（付記１３） 対向装置との間で確立しているデータ・リンク層のリンクに、データの送信元から受信する送信対象のデータを送出する手段と、
前記リンクの異常に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるデータ送信制御手段と
を含む通信装置。（４）
（付記１４） 前記データ送信制御手段は、前記リンクが再確立される場合に、前記データの送信元にデータ送信を再開させる
付記１３記載の通信装置。
【０１２３】
（付記１５） 対向装置との間で確立されるデータリンク層のリンクが正常な場合に、このリンクを通じて所定時間内で順次到着するフラグを受信するステップと、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定するステップとを含む通信装置のデータリンク監視制御方法。（５）
（付記１６） 前記リンクからフラグが受信された場合に所定時間を計時するタイマを起動し、次のフラグが受信される前に前記タイマがタイムアウトになった場合には、前記リンクが異常と判定する
付記１５記載の通信装置のデータリンク監視制御方法。
【０１２４】
（付記１７） 前記タイマがタイムアウトになる前に前記受信手段で次のフラグが受信された場合には、前記タイマをリセットし、前記リンクが正常と判定する
付記１６記載の通信装置のデータリンク監視制御方法。
【０１２５】
（付記１８） 前記リンクが異常と判定された場合に、このリンクを終了させる
付記１５〜１７のいずれかに記載の通信装置のデータリンク監視制御方法。
【０１２６】
（付記１９） 前記リンクを終了させた後に、前記リンクの復旧が可能な状態となったときには、前記リンクを再確立する
付記１９記載の通信装置のデータリンク監視制御方法。
【０１２７】
（付記２０） 前記判定を行うか否かを前記対向装置との間でネゴシエーションする
付記１５〜１９のいずれかに記載の通信装置のデータリンク監視制御方法。
【０１２８】
（付記２１） 前記判定を行うか否かを問い合わせるための情報を前記対向装置に送信し、問い合わせに対する応答を前記対向装置から受信する
付記２０記載の通信装置のデータリンク監視制御方法。
【０１２９】
（付記２２） 自装置で前記判定を行うことを示す情報を前記対向装置に送信し、自装置が前記判定を行うことを拒否することを示す応答を前記対向装置から受け取った場合には、前記判定を行わない
付記２１記載の通信装置のデータリンク監視制御方法。
【０１３０】
（付記２３） 前記判定を行わない場合には、前記対向装置に前記リンクの正常を検査する検査フレームを送信し、前記対向装置から前記検査フレームに対する応答フレームを所定時間内に受信した場合に前記リンクが正常と判定するリンク監視処理を行う
付記２２記載の通信装置のデータリンク監視制御方法。
【０１３１】
（付記２４） 送信対象のデータを前記リンクへ送出するステップと、
前記リンクの異常に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるステップと
をさらに含む付記１８記載の通信装置のデータリンク監視制御方法。
【０１３２】
（付記２５） 前記リンクが再確立される場合に、前記データの送信元にデータ送信を再開させる
付記２４記載の通信装置の通信装置のデータリンク監視制御方法。
【０１３３】
（付記２６） 対向装置との間で確立しているデータ・リンク層のリンクに、データの送信元から受信する送信対象のデータを送出するステップと、
前記リンクの異常に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるステップと、
を含む通信装置のデータリンク監視制御方法。
【０１３４】
（付記２７） 前記リンクが再確立される場合に、前記データの送信元にデータ送信を再開させる
付記２６記載の通信装置のデータリンク監視制御方法。
【０１３５】
【発明の効果】
本発明によれば、迅速なリンク状態の判定が可能となる。また、本発明によれば、リンク状態の判定の確実性が向上する。また、本発明によれば、リンク状態に基づくフロー制御が可能となる。
【図面の簡単な説明】
【図１】図１(Ａ)は、PPP over SONET/SDH(ＰＯＳ)フレームの説明図であり、図１(Ｂ)は、フラグの説明図であり、図１(Ｃ)は、ＰＰＰのパケットがやりとりされている状態の説明図であり、図１(Ｄ)は、アイドル状態の説明図である。
【図２】図２は、本発明に係る通信装置の構成を示す図である。
【図３】図３は、ＰＯＳ制御部によるリンク断判定処理の手順を示す図である。
【図４】図４は、リンク制御部の状態遷移図である。
【図５】図５は、フラグ監視機能の有効／無効の設定をＬＣＰに定義する場合のフォーマットを示す図である。
【図６】図６は、ネゴシエーションにおいてフラグ監視機能の有効設定が受諾されるケースを示すシーケンス図である。
【図７】図７は、ネゴシエーションにおいてフラグ監視機能の有効設定が拒否されるケースを示すシーケンス図である。
【図８】図８は、Pauseフレームのフォーマットを示す図である。
【図９】図９は、本発明の実施例に係る通信装置の構成例を示す図である。
【図１０】図１０は、従来技術の説明図である。
【図１１】図１１は、従来技術の説明図である。
【図１２】図１２は、従来技術の説明図である。
【符号の説明】
Ａ,Ａ２,Ｘ,Ｙ 通信装置(SONET/SDH通信装置)
４５ ＰＰＰ部(設定手段，ネゴシエーション手段，リンク監視手段)
５０ ＰＯＳ制御部(受信手段，判定手段)
５１ リンク断監視タイマ(タイマ)
６０ リンク制御部(データ送信制御手段)
６１ ＭＡＣ制御部
Claims (5)
- 対向装置との間で確立されるデータ・リンク層のリンクが正常な場合に、このリンクを通じて或る間隔内で順次到着するフラグを受信する受信手段と、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定する判定手段と、
を含む通信装置。 - 前記判定手段によって前記リンクが異常と判定された場合に、このリンクを終了させる
請求項１記載の通信装置。 - 前記判定手段の有効または無効を前記対向装置との間でネゴシエーションするネゴシエーション手段をさらに含む
請求項１または２記載の通信装置。 - 対向装置との間で確立しているデータ・リンク層のリンクに、データの送信元から受信する送信対象のデータを送出する送出手段と、
前記リンクの異常に従って前記リンクが終了される場合に、前記データの送信元にデータ送信を停止させるデータ送信制御手段と
を含む通信装置。 - 対向装置との間で確立されるデータリンク層のリンクが正常な場合に、このリンクを通じて或る間隔内で順次到着するフラグを受信するステップと、
フラグの受信状態に基づいて前記リンクが正常か異常かを判定するステップと、
を含む通信装置のデータリンク監視制御方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002372467A JP2004207878A (ja) | 2002-12-24 | 2002-12-24 | 通信装置 |
| US10/727,558 US20040167978A1 (en) | 2002-12-24 | 2003-12-05 | Communication apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002372467A JP2004207878A (ja) | 2002-12-24 | 2002-12-24 | 通信装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004207878A true JP2004207878A (ja) | 2004-07-22 |
Family
ID=32811064
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002372467A Pending JP2004207878A (ja) | 2002-12-24 | 2002-12-24 | 通信装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20040167978A1 (ja) |
| JP (1) | JP2004207878A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006352484A (ja) * | 2005-06-15 | 2006-12-28 | Ntt Electornics Corp | 回線接続装置 |
| JP2007180716A (ja) * | 2005-12-27 | 2007-07-12 | Kyocera Corp | 通信中継装置、通信装置、通信中継方法及び通信方法 |
| US8699526B2 (en) | 2008-11-27 | 2014-04-15 | Fujitsu Limited | Communication control method and transmitting apparatus |
| US10142169B2 (en) | 2016-01-19 | 2018-11-27 | Fujitsu Limited | Diagnosis device, diagnosis method, and non-transitory recording medium storing diagnosis program |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7340163B2 (en) * | 2002-12-16 | 2008-03-04 | Alcatel Lucent | Signaling protocol and architecture for protection rings |
| JP3959402B2 (ja) * | 2004-03-19 | 2007-08-15 | 株式会社日立コミュニケーションテクノロジー | 通信接続装置及び通信端末ならびにこれを用いた通信方法 |
| JP4368716B2 (ja) * | 2004-03-25 | 2009-11-18 | Ｎｅｃエレクトロニクス株式会社 | 通信回路および通信方法 |
| US7483996B2 (en) * | 2004-11-29 | 2009-01-27 | Cisco Technology, Inc. | Techniques for migrating a point to point protocol to a protocol for an access network |
| US8059527B2 (en) * | 2005-02-19 | 2011-11-15 | Cisco Technology, Inc. | Techniques for oversubscribing edge nodes for virtual private networks |
| US8059567B1 (en) * | 2006-06-29 | 2011-11-15 | Ericsson Ab | Distributing mobile stations across carriers of plural frequency bands |
| US9414429B2 (en) * | 2007-06-28 | 2016-08-09 | Qualcomm Incorporated | Method and apparatus for maintaining an always-on data session in a wireless communication network |
| US8248954B2 (en) | 2009-08-31 | 2012-08-21 | Hubbell Incorporated | System and method for enhancement of Ethernet link loss forwarding |
| EP2645261B1 (en) * | 2010-11-26 | 2018-09-26 | Fujitsu Limited | Management apparatus, management system, management method and set of an application source program, a first program and a second program |
| CN103684672A (zh) * | 2012-09-20 | 2014-03-26 | 中兴通讯股份有限公司 | 以太网数据传输速率的调整方法及装置 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6349331B1 (en) * | 1998-06-05 | 2002-02-19 | Lsi Logic Corporation | Multiple channel communication system with shared autonegotiation controller |
| US6795450B1 (en) * | 2000-09-28 | 2004-09-21 | Tdk Semiconductor Corporation | Method and apparatus for supporting physical layer link-suspend operation between network nodes |
| US7327754B2 (en) * | 2000-09-28 | 2008-02-05 | Teridian Semiconductor, Corp. | Apparatus and method for freezing the states of a receiver during silent line state operation of a network device |
| US7292597B2 (en) * | 2000-09-28 | 2007-11-06 | Teridian Semiconductor Corp. | Method and apparatus for transparent implementation of link-suspend capabilities in network devices |
| US7317691B2 (en) * | 2000-09-28 | 2008-01-08 | Teridian Semiconductor, Corp. | Method for initializing a link suspend device for optimum receive recovery |
| US7317732B2 (en) * | 2000-09-28 | 2008-01-08 | Teridian Semiconductor, Corp. | Method and apparatus for handling link suspend pulse and silent line state transitions of a network device |
-
2002
- 2002-12-24 JP JP2002372467A patent/JP2004207878A/ja active Pending
-
2003
- 2003-12-05 US US10/727,558 patent/US20040167978A1/en not_active Abandoned
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006352484A (ja) * | 2005-06-15 | 2006-12-28 | Ntt Electornics Corp | 回線接続装置 |
| JP2007180716A (ja) * | 2005-12-27 | 2007-07-12 | Kyocera Corp | 通信中継装置、通信装置、通信中継方法及び通信方法 |
| US8699526B2 (en) | 2008-11-27 | 2014-04-15 | Fujitsu Limited | Communication control method and transmitting apparatus |
| US10142169B2 (en) | 2016-01-19 | 2018-11-27 | Fujitsu Limited | Diagnosis device, diagnosis method, and non-transitory recording medium storing diagnosis program |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040167978A1 (en) | 2004-08-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4212476B2 (ja) | イーサネット上でｓｄｈ／ｓｏｎｅｔ自動保護スイッチングをサポートするための方法 | |
| US7957267B2 (en) | Fault detection device | |
| US6756898B2 (en) | Network termination device, alarm transfer system and alarm transferring method | |
| JP2004207878A (ja) | 通信装置 | |
| JP2967178B2 (ja) | パケットモードデータ接続の再ルーチング方法 | |
| EP1816803B1 (en) | Transmission processing method for data frame and system thereof | |
| WO2007016833A1 (fr) | Procédé de déclenchement de détection de panne de détection de transfert bidirectionnel | |
| CN102333011B (zh) | 单向链路检测方法及装置 | |
| WO2002080465A2 (en) | Selective protection for ring topologies | |
| WO2006108352A1 (fr) | Procede de gestion de panne et appareil permettant l'interfonctionnement entre ethernet et un reseau de commutation multiprotocole par etiquette | |
| JPH10336178A (ja) | コネクション管理方法及び管理システム | |
| CN100403705C (zh) | Ppp封装接口的环回检测方法 | |
| WO2004045145A1 (en) | Method of transmitting ethernet port link state | |
| JP5071696B2 (ja) | シグナリング処理装置、リンク切替方法 | |
| JP2011182241A (ja) | 伝送装置および警報送信方法 | |
| Cisco | X.25 and LAPB Commands | |
| Cisco | X.25 and LAPB Commands | |
| Cisco | X.25 and LAPB Commands | |
| JP2003087291A (ja) | Ｌａｎ間接続システムおよびその警報転送方式 | |
| JP3224521B2 (ja) | Ｆｃ／ａｔｍ複合ネットワークの通信制御方法及びネットワーク間接続装置 | |
| JPH08161248A (ja) | 情報処理装置 | |
| JP2003018159A (ja) | プロトコル変換装置及び通信システム | |
| JP2012129864A (ja) | 通信システム及びユーザアクセス装置を制御する方法 | |
| JP2004289744A (ja) | マルチポートスイッチ | |
| JP3785370B2 (ja) | パケット転送装置、伝送装置、パケット転送システム及びネットワーク故障復旧方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041026 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060809 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060815 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061016 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070508 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070911 |