JP2004535133A - Method for optimal use of SCTP in MPLS networks - Google Patents
Method for optimal use of SCTP in MPLS networks Download PDFInfo
- Publication number
- JP2004535133A JP2004535133A JP2003513134A JP2003513134A JP2004535133A JP 2004535133 A JP2004535133 A JP 2004535133A JP 2003513134 A JP2003513134 A JP 2003513134A JP 2003513134 A JP2003513134 A JP 2003513134A JP 2004535133 A JP2004535133 A JP 2004535133A
- Authority
- JP
- Japan
- Prior art keywords
- network
- information
- label
- protocol
- path
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
2つのエンティティの間でのネットワークを介して情報を交換するための方法が提案される。この方法では、ラベルによって特徴付けられており、目標エンティティ及び出所エンティティが一義的に検出されているネットワーク経路をネットワーク間で情報を伝送するために使用する第1のプロトコルと、第1のプロトコルを基礎とする第2のトランスポートプロトコルとを用いる。トランスポートプロトコルは情報の受信を確認情報によって保証する。またこの方法は、第1のネットワーク経路を介してネットワーク経路の1からnのラベルが交換される第1の初期化ステップと、情報が1からnのネットワーク経路によって交換される第2の情報交換ステップとを用いる。有利には第1のプロトコルはMPLSであり、各FECは一義的な目標エンティティ及び一義的な出所エンティティを表す。有利には第2のプロトコルはSCTPであり、IPアドレスはネットワーク経路のラベルに置換される。A method is proposed for exchanging information over a network between two entities. In this method, a first protocol is used to transmit information between networks, characterized by a label, wherein a target entity and a source entity are uniquely detected, and a first protocol is used. Use the underlying second transport protocol. The transport protocol guarantees receipt of the information by means of confirmation information. The method also includes a first initialization step in which labels 1 to n of the network path are exchanged via the first network path, and a second information exchange in which information is exchanged by the network paths 1 to n. Steps are used. Advantageously, the first protocol is MPLS, each FEC representing a unique target entity and a unique source entity. Advantageously, the second protocol is SCTP, wherein the IP address is replaced by the label of the network path.
Description
【技術分野】
【0001】
SCTP(ストリーム・コントロール・トランスポート・プロトコル、Stream Control Transmission Protocol)[RFC2960]は高いネットワーク冗長性を提供するトランスポートプロトコルである。すなわち、送信された全てのデータは正確な順序で到来することが保証されている。例えばTCP[RFC793](IP[RFC7911]によって実現される)のように、考えられる1つのトランスポート経路のみが使用されるのでなく、複数のトランスポート経路が使用される。このことはPSTNネットワークにおけるシグナリングのように、非常に高いアベイラビリティを実現しなければならない適用では必要である。この際ネットワーク層としてIPが使用される。SCTPはコネクション確立の際に2つのパートナ間で交換されるメッセージにおける適切な(総称)パラメータによってIPを支援する。例えばUMTSを用いる無線通信において使用されるような今日の「IP」コアネットワークでは、純粋なIPはますます省略される。むしろ個々のネットワークエレメント間におけるMPLS(マルチ・プロトコル・ラベル・スイッチング、Multi Protocol Label Switching)[RFC3031])を用いて直接的なLSP(ラベル交換される経路、Label Switched Path)がトラフィックエンジニアリングも使用して確立される。公知の方法は文献[RFC2960]及び[RFC3031]に公開されている。この際特に...(ここではさらにトラフィックエンジニアリングについての情報が必要とされる)が問題である。
【0002】
本発明の課題は、SCTPを最適にMPLSネットワークにおいて使用することである。
【0003】
この課題は独立請求項の特徴によって、殊にラベルによって特徴付けられており、目標エンティティ及び出所エンティティを一義的に検出しているエンティティネットワーク経路間での情報の伝送に使用される第1のプロトコルを用いて、2つのエンティティ間のネットワークを介して情報を伝送する方法によって解決される。この第1のプロトコルは、情報を目標エンティティにルーティングするためにのみ使用される。情報がまた実際にも到来しているか否かを検査するというタスクは引き受けられない。このために第2のトランスポートプロトコルが必要である。第1のプロトコルに基づく第2のトランスポートプロトコルは、出所エンティティに送り返される確認情報によって情報の受信を確認する。本発明の方法は情報を伝送するための経路を1つしか準備しないのではなく、複数の経路を準備する。このことは通信の確立時に伝送されなければならない。
【0004】
第1の初期化ステップにおいて、第1のネットワーク経路を介して別のネットワーク経路の1からnのラベルが交換される。これらの各ネットワーク経路は、エンティティ間の一義的な情報交換を許容する。通信と情報交換を行うべきネットワーク経路が交換された後に、伝送すべき情報が1からnのネットワーク経路を介して伝送される。個々のネットワーク経路への負荷状況または応答特性に応じて、伝送すべき情報をより負荷の少ないネットワーク経路に分配することができる。
【0005】
衝突の回避またスループットの向上のために、ネットワーク経路は単一方向の情報交換にのみ使用される。双方向の使用も同様に考えられるが、これはSCTPの設定には対応しない。
【0006】
有利な実施形態においては第1のプロトコルはMPLSである。プロトコルの詳細な構成は[RFC3031]に見出せる。さらにこのプロトコルが原則として以下に説明される。基本的にネットワークプロトコルは個々の層ないしレイヤによって表される。MPLSプロトコルはここでレイヤ2に配置されている。このプロトコルには通常の場合、情報パケットの受信側エンティティ及び送信側エンティティの一義性を保証するためにレイヤ3におけるプロトコルが設けられている。このレイヤ3においてはTCPないし択一的にSCTPがレイヤ4におけるトランスポートプロトコルとして使用される。この2つのプロトコルは、所定の時間窓において受信側の確認が送信側に到来したときに新たなパケットが送信されることによって、情報パケットが実際にも到来したことを保証する。本発明によってレイヤ3したがってオーバヘッドを省略することができる。
【0007】
MPLSネットワークにおいてはいわゆる「転送同等クラス」(FECs)が使用される。このクラスは所定のIPアドレスをラベルにマッピングすることに使用される。これに対してIPアドレスと同等クラスとの間には全単写(bijektiv)の関係が存在する場合には、ラベルをレイヤ3のタスクを担うために使用することができる。すなわち、送信側IPアドレス及び受信側IPアドレスに関する単に1つのラベルが使用される。これによって各FECは一義的な目標エンティティ及び出所エンティティを表す。通常の場合、SCTPにおいては目標アドレスないし出所アドレスとして監視され、情報の交換を行う多数のIPアドレスが交換される。
【0008】
したがってエンティティは複数のIPアドレスを有する。マルチホームエンティティと呼ばれる。SCTPに関する詳細はRFC2960ないし以下に見出せる。エンティティは通常の場合サーバまたは公知のコンピュータである。しかしながら、例えばルータのような別のネットワーク要素も考えられる。
【0009】
本発明による方法のトランスポートプロトコルはSCTPであり、IPアドレスがネットワーク経路のラベルに置換される。別の実施形態においては、情報パケットのスタックに配置されており、情報を個々の出所エンティティ及び目標エンティティに一義的に対応付ける特別な経路Idラベルが採用される。これによって上述の択一形態とは異なり、選択される経路は一義的なものである必要は無い。経路Idラベルの使用は、受信側が経路IPラベルに基づいて情報は何処に由来するのかを識別できるので、IPアドレスを省略することができる。
【0010】
トランスポートプロトコルは基本的に、情報が到来し且つその順序が保持されたままにするタスクを保証する。このためにTCPからも公知であるSCTPの公知の方法が使用される。ばらばらにされた情報を包含する個々のパケットは番号を有する。この番号に基づいて構成の順序を確認することができる。TSN(伝送シーケンス番号、Transmission Sequence Number)が各情報パケットに割り当てられる。受信側エンティティないし目標エンティティの各応答は、事前に送信側エンティティないし出所エンティティから伝送されたTSNを包含する。これによってパケットが実際に到来しているか、または消失しているか否かを確認することができる。応答がRTT(ラウンドトリップ時間)内に到来しない場合にはパケットは新たに送信される。RTO(再伝送タイムアウト)は時間間隔を確定し、この時間間隔の最後にはパケットの新たな伝送が行われる。
【0011】
情報を交換するためのネットワーク経路を使用できるようになる前に、このネットワーク経路を確立する必要がある。このために、有利にはIPアドレスでもって動作するトラフィックエンジニアリングに関する公知の法方が使用され、ルータ/スイッチは経路に対して目標エンティティ及び出所エンティティは一義的であるようにコンフィギュレーションされる。この方法の詳細な機能は...(情報がまだ足りない)から得ることができる。
【0012】
別の実施形態においては伝送の際にラベルスタッキングが使用される。各データパケットにはスタックが割り当てられ、このスタックにおいてラベルが監視される。各ラベルは上述したような同等クラスを表す。ラベルを備えたデータパケットがルータに到来すると、最上ラベルがスタックから取り除かれ、現在のルータにおけるこの同等クラスに対応する新たなラベルに置換される。したがって開始ラベル及び終了ラベルに基づいて、パケットの行程ないし経路をその情報でもって事前に指定することができる。SCTPはスループットないし応答時間に依存して情報の伝送時に異なるネットワーク経路を選択する。したがって一定に高いスループットが保証される。
【0013】
本発明の別の構成部分は、本発明による方法を実施するための手段を有する、ネットワークを介して情報を交換するための装置に関する。有利にはこの装置は、ネットワークインタフェースを有するコンピュータの形態の端末機器である。さらにこの装置は経路の出発点に存在するルータである。この装置はラベルを相応の端末機器に割り当てることができなければならない。
【0014】
図面には本発明の考えられる実施形態が示されている。ここで、
図1はラベルスタッキングを使用するルータを有するネットワークを示す。各ルータは先行するルータのラベルを交換し、自身の固有のラベルと置換し、この際一義性を保証するためにスタック内に配置されている経路IDラベルが付加的に使用される。
図2はラベルスタッキングを使用するルータを有するネットワークを示す。各ルータは先行するルータのラベルを交換し、自身の固有のラベルと置換し、この際ラベルは一義的な経路を表す。
図3は従来技術を表すネットワークを示す。IPアドレスがデータパケット内に配置されている。
【0015】
図1は、2つのエンティティ11を有するMPLSネットワークを示す。これらのエンティティ11は2つの経路によって相互に接続されている。データパケット12は、相応の目標エンティティ11に到着するために、ネットワークを通るルータ16を介し導かれる。経路は経路Idラベルによって特徴付けられる。第1の経路は経路Idラベル「経路ID1」を有する。第2の経路は経路Idラベル「経路ID2」によって特徴付けられる。各データパケット12はラベルが存在する1つのスタックを有する。最上ラベル15によってFFCが検出される。最初の伝送時にはデータパケットには番号0を有するラベルが割り当てられた。第1のルータはこのラベルをラベル1と交換する。この経路における最後のルータはラベルを番号4を有するラベルと交換する。応答時には第2の経路が使用される。ここでも同様にデータパケットのスタックには相応のラベルが設けられており、これらのラベルが各ルータによって交換される。経路を決定するラベルは決して交換されず、したがって受信側は何処からパケットが送信されたかを一義的に確認することができる。
【0016】
図2は経路IDラベルの無い実施形態を示す。しかしながらここでは、各ラベルは一義的な1つの経路に対応付けられていることを前提とする。経路は出所エンティティと目標エンティティが一義的である場合には常に一義的である。
【0017】
図3は、IPアドレスが伝送すべき情報14内に配置されている従来技術を示す。通常のようにラベルが一義的で無く、単に同等クラスを検出する場合には、ルーティング決定のために伝送すべき情報におけるIPアドレスが分析されることが必要になる可能性がある。この分析は非常に面倒なものとなる可能性があり、ルータにおける付加的なロジックを必要とする。
【0018】
以下では詳細に、個々のプロトコル及びその変形を検討する。
【0019】
MPLSネットワークでは、パケットがあるルータから次のルータへと移動する。各ルータは転送に関する独立した決定を行う。すなわち、各ルータはパケットのヘッダを分析し、また各ルータはルータアルゴリズムを用いてプログラムを実行する。各ルータは新たなルートをルータアルゴリズムの結果に依存して選択する。したがって次のルータの選択は2つのステップで行われる。第1のステップは、考えられるパケットの全体の量を多数の同等クラス(FEC)に分割する。第2のステップは、各FECを1つのルートにマッピングする。転送の決定に関しては、同一のFECに属するパケットは区別されない。同一のFECに属する異なるパケットを区別することはできない。異なる目標アドレスまたは出所アドレスを有するパケットは異なるパケットとみなす。しかしながらMPLSを本発明に使用できるようにするためには、経路したがって同等クラスは一義的である必要がある。すなわち、同等クラスは一義的な出所エンティティ及び目標エンティティないしそのアドレスを表す。
【0020】
MPLSネットワークにおいてはFECへの対応付けは一度のみ、すなわちパケットがネットワークに到来したときに行われる。1つのパケットが対応付けられているFECは、ラベルと称される短い値としてコーディングされる。パケットが次のルートに送信される場合にはラベルも一緒に送信される。後続のルータではパケットのさらなる内容の分析は行われない。ラベルのみが検査される。ラベルはテーブルのためのインデックスとして使用され、このテーブルから次のルート及び次のラベルを得ることができる。古いラベルは新たなラベルに置換され、パケットは次のルートへと転送される。
【0021】
MPLSネットワークにおいて転送はラベルによってのみ制御される。このことは多数の利点を有する。つまりルータは僅かな性能を有してさえいれば良い。ルータは単にラベルを分析し、古いラベルを新たなラベルに置換するためにどのルートがこのラベルに割り当てられているかをテーブルにおいて検査できさえすればよい。さらにこの簡単なタスクによって高いスループットを実現することができる。さらなる利点はRFC3031から得ることができる。
【0022】
以下では幾つかの原則を規定する。ラベルは短く局所的で特徴的な識別子であり、FECを識別するために固定長を有する。ラベルはパケットが対応付けられているFECを表すために使用される。FECの基本的な使用においては、このFECはネットワーク層の目標アドレスに基づいて割り当てられる。しかしながらFECの本来的な使用においてはネットワークアドレスのコーディングは問題ではない。正にこの点に本発明との相違が生じる。ラベルが一義的な経路へと一義的に割り当てられることによって、ネットワークアドレスのコーディングが問題である。
【0023】
ルータがパケットを同一の同等クラスに対応付けることを保証するために、ルータはどのパケットがラベルに割り当てられるかが分かる情報を規則的に交換しなければならない。さらに同一のラベルが異なるルータに使用されないことは重要であり、その点ではこれによって先行のルータの一義的な識別は不可能となる。さらに、アップストリーム及びダウンストリームに異なる処理が施されることに言及すべきである。つまりこれらのストリームは絶対に同一のラベルを有さない。MPLSアーキテクチャにおいては、所定のラベルを所定の同等クラスに結合させるという決定が、この結合に関してダウンストリームであるルータによって行われる。ダウンストリームであるルータはアップストリームであるルータにこの結合について情報を付与する。この情報を例えばピギーバック(Huckepack)情報として別のパケットに転用することができる。
【0024】
別の実施形態においてはMPLSは階層を支援し、この際ラベルが設けられているパケットの処理は完全に階層レベルから独立している。ラベルを有さないパケットはスタックが空であるラベルとみなすことができる。スタックの使用はパケットのトンネルを言及する際に明らかになる。そのようなトンネルは文献RFC3031から得ることができる。パケットが2つのルータ間のネットワーク経路によって案内される場合には、パケットは常にトンネリングされ、ここでこのネットワーク経路はやはり多数のルータを包含する。
【0025】
例えばルータR1からR4を包含する明示的な経路が予め設定されており、ルータR1とR2との間にルータR1.1、R1.2、R1.3を包含する経路が存在する場合には、別のラベルがルータR1によってスタックにプッシュされる。ルータR1.1、R1.2、R1.3はこの新たな第2の要素において動作する。パケットがルータR2に到来すると直ぐに、最上要素がスタックからポップされる。ラベルがスタックに無い場合には問題となる。通常のMPLSアーキテクチャにおいては、同等クラスを検出するために、ネットワークアドレス(通常の場合はIPアドレス)が分析される。本発明を使用する場合にはこの状況は生じてはならない。MPLSは2種類のルート選択を提供する。一方のルート選択はルートを既に出発地点において確定する。通過しなければならない個々のルートが検出される。これは明示的なルートである。ホップ・バイ・ホップルートではルータは明示的には確定されないので、各ルータはテーブルに基づいてどのルータが次のルータであるべきかを確定することができる。本発明を2つのルート選択の可能性でもって動作することができる。
【0026】
SCTPは、本来的にIPのようにパケットネットワークを構築する信頼に足るトランスポートプロトコルである。しかしながら、本発明の実施形態においてはこのIPは使用されない。これによってネットワークスキーマのレイヤ3を節約することができる。
【0027】
SCTPの利点は以下の通りである:
1.手段無しでのユーザデータの確認された誤りの無い伝送
2.MTU(最大伝送ユニット、Maximum Transmission Unit)の範囲におけるデータフラグメント。MTUはパケットベースのネットワーク(例えばTCP/IP)において、これからさらに伝送できるパケットの量を表す。TCP/IPはその都度の伝送においてパケットの量を検出するためにMTUを使用する。(ルータがもはや伝送できない)過度に大きいパケットが生じた場合には、相応の計算機へと送り返される。
3.複数の経路を介するデータ伝送。これらのデータは、本来の順序とは一致しない情報の伝送を防止するために連続する番号を有する。
4.アソシエーションの両端におけるマルチホームのエンティティを支援することによる高い誤り耐性。
【0028】
本来の実施形態においては、SCTPがユーザアプリケーションとIPのようなコネクションレスのパケットネットワークとの間のレイヤと見なされた。しかしながらここでの形態ではIPネットワークは冗長的なものとなる。この利点は既に上記で説明している。SCTPはその性質において2つのエンティティの間のコネクション指向のアソシエーションであるが、そのコンセプトからTCPよりも広範に設計されている。
【0029】
アソシエーションはSCTPユーザの問合せによって開始される。RFC2522における記載と類似するクッキーメカニズムは、セキュリティ攻撃に対する保護を保証するためにアソシエーションの初期化中に使用される。さらにコネクションの終了をユーザが望んだ場合には、コネクションが終了される。したがってTCPから公知のようなハーフオープンな状態は排除されている。コネクションが閉じられると、新しいデータは受け取られない。
【0030】
SCTPにおけるデータストリームの個数はコネクションの初期化の時点に確認される。個数は2つのエンティティによって確認される。このストリームを介して交換される情報は相応の番号を有する。内部的にはSCTPは各情報ないし各情報パケットに一義的なストリームシーケンス番号を割り当てる。異なるストリームを使用することによって、ストリームの内の一方が阻止されている場合でも情報は伝送されることが保証される。本発明においては、ストリームはラベルによって特徴付けられている個々のネットワーク経路に対応する。TSN(トランスミッションシーケンス番号)は各データパケットに割り当てられる。TSNは各ストリームシーケンス番号に依存しない。受信側ないし目標エンティティは、パケットの受信をTSNを送り返すことにより通知する。これによって、全てのパケットが到来することが保証される。パケットが消失してしまったようであれば、このパケットは新たに送信される。さらに、タイマによってパケットを新たに送信すべきか否かが確認される。応答時間が遵守されないようであればタイマは高くセットされ、パケットは新たに送信される。タイマはパケットに対する応答が得られるまで最大限になるまで高くセットされる。
【0031】
検査フィールドによってパケットの首尾一貫性が検査される。
【0032】
以下ではコネクションの確立を説明し、これにより公知のSCTPは修正された本発明によるプロトコルとは異なることを示唆する。
【0033】
2つのSCTPエンティティ(AとZ)の間で最初のデータ伝送を行うことができるようになる前に、SCTPアソシエーションが形成される完全な初期化プロセスが実施されなければならない。
【0034】
アソシエーションが確立された後では、単一方向のデータストリームを経路を介して伝送することができる。初期化プロセスを以下のステップから構成することができる。エンティティAは先ず初期化パケットをエンティティZに送信する。この初期化パケットは相応のフィールド(タグ_A)に検査タグを包含する。タグは相応の乱数である。この初期化パケットが伝送された後にタイマが開始される。エンティティAはクッキー待機状態に移行する。エンティティZはこれに基づき即座に初期化応答パケットでもって応答する。ここでIPアドレスの代わりにラベルないし経路IDラベルが交換される。経路IDラベルは、ラベルによって表される経路が一義的でない場合には常に交換される。最後のルータにおいて目標エンティティを一義的に検出できない場合には、経路は常に一義的なものではない。最後のラベルの同等クラスが一義的でない、すなわち全単写である場合には常にこれが該当する。エンティティZは検査フィールドタグ_A及びタグ_Z並びにクッキーを確認として送信する必要がある。この確認を受け取るとタイマはエンティティAによって停止される。同様に状態も変化する。これに基づいて、クッキーが得られたことを通知するクッキー応答がエンティティZに送信される。
【0035】
続けてタイマがエンティティAによって新たに開始される。このタイマは、エンティティZがクッキー応答を受け取ったことを確認すると止められる。コネクションの中断は相応のエンティティに常に通知されなければならない。コネクションないしアソシエーションがそのように確立されると、経路を介してデータが交換される。コネクションを監視するために規則的に検査情報が伝送される。これによってコネクションの状態を検出することができる。
【0036】
さらなる詳細はRFC2960から得ることができる。
【図面の簡単な説明】
【0037】
【図1】ラベルスタッキングを使用するルータを備えたネットワークである。
【図2】ラベルスタッキングを使用するルータを備えたネットワークである。
【図3】従来技術によるネットワークである。【Technical field】
[0001]
SCTP (Stream Control Transport Protocol, Stream Control Transmission Protocol) [RFC2960] is a transport protocol that provides high network redundancy. That is, it is guaranteed that all transmitted data arrives in the correct order. Instead of using only one possible transport path, such as TCP [RFC793] (implemented by IP [RFC7911]), multiple transport paths are used. This is necessary in applications where very high availability must be achieved, such as signaling in PSTN networks. At this time, IP is used as a network layer. SCTP supports IP with appropriate (generic) parameters in messages exchanged between two partners during connection establishment. In today's "IP" core networks, such as those used in wireless communications using UMTS, pure IP is increasingly omitted. Rather, direct LSPs (Label Switched Paths) using MPLS (Multi Protocol Label Switching) [RFC 3031] between individual network elements also use traffic engineering. Established. Known methods are published in the literature [RFC2960] and [RFC3031]. This is especially the case ... (where more information about traffic engineering is needed).
[0002]
It is an object of the present invention to use SCTP optimally in MPLS networks.
[0003]
This task is characterized by the features of the independent claims, in particular by the label, a first protocol used for the transmission of information between entity network paths uniquely detecting the target entity and the source entity. By transmitting information over a network between two entities. This first protocol is used only to route information to the target entity. The task of checking whether information is also actually arriving cannot be undertaken. For this, a second transport protocol is required. A second transport protocol based on the first protocol confirms receipt of the information by confirmation information sent back to the source entity. The method of the present invention does not prepare only one path for transmitting information, but prepares a plurality of paths. This must be transmitted when the communication is established.
[0004]
In a first initialization step, labels 1 to n of another network path are exchanged via the first network path. Each of these network paths allows a unique exchange of information between the entities. After the network paths for communication and information exchange are exchanged, the information to be transmitted is transmitted via network paths 1 to n. The information to be transmitted can be distributed to the network path with a smaller load according to the load situation or the response characteristic of each network path.
[0005]
To avoid collisions and increase throughput, network paths are used only for unidirectional information exchange. Bidirectional use is also conceivable, but does not correspond to SCTP settings.
[0006]
In a preferred embodiment, the first protocol is MPLS. The detailed structure of the protocol can be found in [RFC3031]. This protocol is further described below in principle. Basically, network protocols are represented by individual layers. The MPLS protocol is now located at layer 2. This protocol is usually provided with a
[0007]
In the MPLS network, so-called “transfer equivalent classes” (FECs) are used. This class is used to map a given IP address to a label. On the other hand, if there is a bijektiv relationship between the IP address and the equivalent class, the label can be used to carry out
[0008]
Thus, an entity has multiple IP addresses. Called a multihomed entity. Details regarding SCTP can be found in RFC 2960 or below. The entity is usually a server or a known computer. However, other network elements, such as routers, are also conceivable.
[0009]
The transport protocol of the method according to the invention is SCTP, where the IP address is replaced by the label of the network path. In another embodiment, a special path Id label is employed that is placed on the stack of information packets and uniquely maps information to individual source and target entities. Thus, unlike the alternative embodiment described above, the selected route does not need to be unique. The use of the path Id label can omit the IP address because the receiving side can identify where the information comes from based on the path IP label.
[0010]
Transport protocols basically guarantee the task of arriving information and keeping its order preserved. For this purpose, a known method of SCTP, which is also known from TCP, is used. Each packet containing the fragmented information has a number. The configuration order can be confirmed based on this number. A TSN (Transmission Sequence Number) is assigned to each information packet. Each response of the receiving entity or the target entity contains the TSN previously transmitted from the transmitting entity or the source entity. This makes it possible to confirm whether the packet has actually arrived or has been lost. If the response does not arrive within the RTT (round trip time), the packet is newly transmitted. RTO (Retransmission Timeout) defines a time interval, at the end of which a new transmission of the packet takes place.
[0011]
Before a network path for exchanging information can be used, it must be established. To this end, known methods for traffic engineering, which operate with IP addresses, are preferably used, and the router / switch is configured such that the target and source entities are unique for the path. The detailed function of this method is. . . (Not enough information).
[0012]
In another embodiment, label stacking is used during transmission. Each data packet is assigned a stack in which a label is monitored. Each label represents an equivalent class as described above. When a data packet with a label arrives at the router, the top label is removed from the stack and replaced with a new label corresponding to this equivalent class at the current router. Therefore, based on the start label and the end label, the path or route of the packet can be designated in advance with the information. SCTP selects different network paths when transmitting information depending on the throughput or response time. Therefore, a constant high throughput is guaranteed.
[0013]
Another component of the invention relates to an apparatus for exchanging information over a network, comprising means for implementing the method according to the invention. Advantageously, the device is a terminal in the form of a computer with a network interface. Furthermore, this device is a router that exists at the starting point of the route. This device must be able to assign labels to the corresponding terminal equipment.
[0014]
The drawings show possible embodiments of the invention. here,
FIG. 1 shows a network having a router that uses label stacking. Each router exchanges the label of the preceding router and replaces it with its own unique label, with the additional use of the path ID label located in the stack to ensure uniqueness.
FIG. 2 shows a network with a router that uses label stacking. Each router exchanges the label of the preceding router and replaces it with its own unique label, where the label represents a unique route.
FIG. 3 shows a network representing the prior art. The IP address is located in the data packet.
[0015]
FIG. 1 shows an MPLS network having two
[0016]
FIG. 2 shows an embodiment without a path ID label. However, here, it is assumed that each label is associated with one unique route. A path is unique whenever the source and target entities are unique.
[0017]
FIG. 3 shows the prior art where the IP address is located in the
[0018]
In the following, the individual protocols and their variants are considered in detail.
[0019]
In an MPLS network, a packet moves from one router to the next. Each router makes independent decisions on forwarding. That is, each router analyzes the header of the packet, and each router executes a program using a router algorithm. Each router selects a new route depending on the result of the router algorithm. Therefore, the selection of the next router is performed in two steps. The first step divides the total amount of possible packets into a number of equivalent classes (FEC). The second step maps each FEC to one route. Regarding the transfer decision, packets belonging to the same FEC are not distinguished. Different packets belonging to the same FEC cannot be distinguished. Packets with different target or source addresses are considered different packets. However, in order for MPLS to be usable in the present invention, the path and hence the equivalent class need to be unique. That is, the equivalent class represents a unique source entity and a target entity or their addresses.
[0020]
In the MPLS network, the association with the FEC is performed only once, that is, when a packet arrives at the network. The FEC associated with one packet is coded as a short value called a label. When the packet is transmitted to the next route, the label is transmitted together. Subsequent routers do not analyze the packet further. Only the label is inspected. The label is used as an index for the table from which the next route and next label can be obtained. The old label is replaced with the new label and the packet is forwarded to the next route.
[0021]
In MPLS networks, forwarding is controlled only by label. This has a number of advantages. In other words, the router only needs to have a slight performance. The router need only be able to analyze the label and check in a table which route is assigned to this label in order to replace the old label with the new label. Furthermore, high throughput can be realized by this simple task. Further benefits can be obtained from RFC 3031.
[0022]
The following defines some principles. Labels are short, local and characteristic identifiers and have a fixed length to identify FEC. The label is used to indicate the FEC to which the packet is associated. In basic use of the FEC, the FEC is assigned based on a network layer target address. However, the coding of network addresses is not a problem in the original use of FEC. In this respect, a difference from the present invention occurs. The coding of network addresses is problematic because labels are uniquely assigned to unique paths.
[0023]
To ensure that routers map packets to the same equivalent class, routers must regularly exchange information that knows which packets are assigned to labels. Furthermore, it is important that the same label is not used for different routers, in which case unambiguous identification of the preceding router is not possible. Furthermore, it should be mentioned that different processing is performed on the upstream and downstream. That is, these streams never have the same label. In the MPLS architecture, the decision to bind a given label to a given equivalent class is made by a router that is downstream with respect to this binding. The downstream router informs the upstream router about this connection. This information can be diverted to another packet as, for example, piggyback (Huckepack) information.
[0024]
In another embodiment, MPLS supports hierarchy, where the processing of labeled packets is completely independent of the hierarchy level. A packet without a label can be considered a label with an empty stack. The use of stacks becomes apparent when referring to packet tunnels. Such a tunnel can be obtained from document RFC 3031. When a packet is guided by a network path between two routers, the packet is always tunneled, where the network path also includes multiple routers.
[0025]
For example, if an explicit route including routers R1 to R4 is set in advance and a route including routers R1.1, R1.2, and R1.3 exists between routers R1 and R2, Another label is pushed onto the stack by router R1. Routers R1.1, R1.2, R1.3 operate on this new second element. As soon as the packet arrives at router R2, the top element is popped off the stack. This is a problem if the label is not on the stack. In a typical MPLS architecture, a network address (usually an IP address) is analyzed to detect an equivalent class. This situation must not occur when using the present invention. MPLS provides two types of route selection. One route selection establishes the route at the point of departure. Individual routes that must be traversed are detected. This is an explicit route. Since routers are not explicitly determined in the hop-by-hop route, each router can determine which router should be the next router based on the table. The invention can be operated with two route selection possibilities.
[0026]
SCTP is essentially a reliable transport protocol that constructs a packet network like IP. However, this IP is not used in the embodiment of the present invention. This can save
[0027]
The advantages of SCTP are:
1. 1. Confirmed error-free transmission of user data without means Data fragment in the range of MTU (Maximum Transmission Unit). The MTU indicates the amount of packets that can be transmitted further in a packet-based network (eg, TCP / IP). TCP / IP uses the MTU to detect the amount of packets in each transmission. If an excessively large packet occurs (the router can no longer transmit), it is sent back to the corresponding computer.
3. Data transmission over multiple paths. These data have consecutive numbers to prevent transmission of information that does not match the original order.
4. High error resilience by supporting multi-homed entities at both ends of the association.
[0028]
In the original embodiment, SCTP was viewed as a layer between the user application and a connectionless packet network such as IP. However, in this embodiment, the IP network is redundant. This advantage has already been described above. SCTP, by its nature, is a connection-oriented association between two entities, but from its concept is designed more extensively than TCP.
[0029]
The association is initiated by an SCTP user query. A cookie mechanism similar to that described in RFC 2522 is used during association initialization to ensure protection against security attacks. If the user further desires to terminate the connection, the connection is terminated. Therefore, the half-open state as known from TCP is excluded. When the connection is closed, no new data will be received.
[0030]
The number of data streams in SCTP is confirmed at the time of connection initialization. The number is ascertained by two entities. The information exchanged via this stream has a corresponding number. Internally, SCTP assigns a unique stream sequence number to each information or each information packet. Using different streams ensures that information is transmitted even if one of the streams is blocked. In the present invention, a stream corresponds to an individual network path characterized by a label. A TSN (transmission sequence number) is assigned to each data packet. TSN does not depend on each stream sequence number. The receiving or target entity signals receipt of the packet by sending back a TSN. This ensures that all packets arrive. If the packet has disappeared, this packet is newly transmitted. Further, it is confirmed by the timer whether or not the packet should be newly transmitted. If the response time does not comply, the timer is set high and the packet is sent anew. The timer is set as high as possible until a response to the packet is obtained.
[0031]
The check field checks the packet for consistency.
[0032]
The following describes the establishment of a connection, which suggests that the known SCTP is different from the modified protocol according to the invention.
[0033]
Before an initial data transmission can take place between two SCTP entities (A and Z), a complete initialization process in which the SCTP association is formed must be performed.
[0034]
After the association is established, a unidirectional data stream can be transmitted over the path. The initialization process can consist of the following steps. Entity A first sends an initialization packet to entity Z. This initialization packet includes a check tag in a corresponding field (tag_A). The tag is a corresponding random number. After the initialization packet is transmitted, a timer is started. Entity A transitions to a cookie waiting state. Entity Z responds immediately with an initialization response packet based on this. Here, labels or route ID labels are exchanged instead of IP addresses. Route ID labels are exchanged whenever the route represented by the label is not unique. If the target entity cannot be unambiguously detected at the last router, the route is not always unique. This is always the case if the last label's equivalent class is not unique, ie it is a single shot. Entity Z needs to send the check field tag_A and tag_Z and the cookie as confirmation. Upon receiving this confirmation, the timer is stopped by entity A. Similarly, the state changes. Based on this, a cookie response is sent to entity Z notifying that the cookie has been obtained.
[0035]
Subsequently, the timer is newly started by the entity A. This timer is stopped upon confirming that Entity Z has received the cookie response. The interruption of the connection must always be notified to the corresponding entity. When a connection or association is so established, data is exchanged over the path. Inspection information is regularly transmitted to monitor the connection. As a result, the state of the connection can be detected.
[0036]
Further details can be obtained from RFC 2960.
[Brief description of the drawings]
[0037]
FIG. 1 is a network with a router that uses label stacking.
FIG. 2 is a network with a router using label stacking.
FIG. 3 is a network according to the prior art.
Claims (12)
ラベルによって特徴付けられており、目標エンティティ及び出所エンティティが一義的に検出されているネットワーク経路を前記エンティティ間で情報を伝送するために使用する第1のプロトコルを用い、
前記第1のプロトコルを基礎とする第2のトランスポートプロトコルを用い、該トランスポートプロトコルは情報の受信を確認情報によって保証し、
第1のネットワーク経路を介して、エンティティ間の情報交換を許容するネットワーク経路の1からnのラベルを交換する第1の初期化ステップを用い、
1からnのネットワーク経路を介して情報を交換する第2の情報交換ステップを用いることを特徴とする、2つのエンティティ間のネットワークを介して情報を伝送する方法。In a method for transmitting information over a network between two entities,
Using a first protocol, characterized by a label, wherein the target entity and the source entity use a network path uniquely detected to transmit information between said entities;
Using a second transport protocol based on said first protocol, said transport protocol guaranteeing receipt of information by confirmation information;
Using a first initialization step of exchanging labels 1 to n of the network paths that allow information exchange between entities via the first network path;
A method for transmitting information over a network between two entities, characterized by using a second information exchange step of exchanging information over 1 to n network paths.
ラベルによって特徴付けられており、目標エンティティ及び出所エンティティが別の経路IDラベルによって一義的に検出されているネットワーク経路をエンティティ間において情報を伝送するために使用する第1のプロトコルを用い、
前記第1のプロトコルを基礎とする第2のトランスポートプロトコルを用い、該トランスポートプロトコルは情報の受信を確認情報によって保証し、
第1のネットワーク経路を介して、エンティティ間の情報交換を許容するネットワーク経路の1からnの経路IDラベルを交換する第1の初期化ステップを用い、
1からnのネットワーク経路を介して情報を交換する第2の情報交換ステップを用いることを特徴とする、2つのエンティティ間のネットワークを介して情報を伝送する方法。In a method for transmitting information over a network between two entities,
Using a first protocol, characterized by a label, wherein the target entity and the source entity use a network path for transmitting information between the entities uniquely detected by another path ID label,
Using a second transport protocol based on said first protocol, said transport protocol guaranteeing receipt of information by confirmation information;
Using a first initialization step of exchanging 1 to n path ID labels of network paths that allow information exchange between entities via the first network path;
A method for transmitting information over a network between two entities, characterized by using a second information exchange step of exchanging information over 1 to n network paths.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10133473A DE10133473C1 (en) | 2001-07-10 | 2001-07-10 | Process for the optimized use of SCTP (Stream Control Transmission Protocol) in MPLS (Multi Protocol Label Switching) networks |
PCT/DE2002/002381 WO2003007484A2 (en) | 2001-07-10 | 2002-07-01 | Method for the optimised use of sctp (stream control transmission protocol) in mpls (multi protocol label switching) networks |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004535133A true JP2004535133A (en) | 2004-11-18 |
JP4008879B2 JP4008879B2 (en) | 2007-11-14 |
Family
ID=7691271
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003513134A Expired - Fee Related JP4008879B2 (en) | 2001-07-10 | 2002-07-01 | Method for optimal use of SCTP in an MPLS network |
Country Status (8)
Country | Link |
---|---|
US (1) | US20040243670A1 (en) |
EP (1) | EP1405422B1 (en) |
JP (1) | JP4008879B2 (en) |
KR (1) | KR20030059129A (en) |
CN (1) | CN1554169A (en) |
DE (2) | DE10133473C1 (en) |
ES (1) | ES2268066T3 (en) |
WO (1) | WO2003007484A2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8908519B2 (en) | 2009-01-19 | 2014-12-09 | Nec Corporation | SCTP communication method |
Families Citing this family (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6360100B1 (en) | 1998-09-22 | 2002-03-19 | Qualcomm Incorporated | Method for robust handoff in wireless communication system |
US7668541B2 (en) | 2003-01-31 | 2010-02-23 | Qualcomm Incorporated | Enhanced techniques for using core based nodes for state transfer |
US6862446B2 (en) | 2003-01-31 | 2005-03-01 | Flarion Technologies, Inc. | Methods and apparatus for the utilization of core based nodes for state transfer |
JP4587446B2 (en) | 2003-08-07 | 2010-11-24 | キヤノン株式会社 | NETWORK SYSTEM, SWITCH DEVICE, ROUTE MANAGEMENT SERVER, ITS CONTROL METHOD, COMPUTER PROGRAM, AND COMPUTER-READABLE STORAGE MEDIUM |
DE10339280B4 (en) * | 2003-08-26 | 2006-09-07 | Siemens Ag | Selection procedure for message paths in communication systems |
US20050169169A1 (en) * | 2004-01-30 | 2005-08-04 | Srinivas Gadde | Determination of an endpoint association from a transport address |
US9078084B2 (en) | 2005-12-22 | 2015-07-07 | Qualcomm Incorporated | Method and apparatus for end node assisted neighbor discovery |
US8983468B2 (en) | 2005-12-22 | 2015-03-17 | Qualcomm Incorporated | Communications methods and apparatus using physical attachment point identifiers |
US8982835B2 (en) | 2005-09-19 | 2015-03-17 | Qualcomm Incorporated | Provision of a move indication to a resource requester |
US8509799B2 (en) | 2005-09-19 | 2013-08-13 | Qualcomm Incorporated | Provision of QoS treatment based upon multiple requests |
US9736752B2 (en) | 2005-12-22 | 2017-08-15 | Qualcomm Incorporated | Communications methods and apparatus using physical attachment point identifiers which support dual communications links |
US9066344B2 (en) | 2005-09-19 | 2015-06-23 | Qualcomm Incorporated | State synchronization of access routers |
WO2007035793A1 (en) * | 2005-09-19 | 2007-03-29 | Qualcomm Incorporated | State synchronization of access routers |
US8982778B2 (en) | 2005-09-19 | 2015-03-17 | Qualcomm Incorporated | Packet routing in a wireless communications environment |
US9083355B2 (en) | 2006-02-24 | 2015-07-14 | Qualcomm Incorporated | Method and apparatus for end node assisted neighbor discovery |
EP1830523A1 (en) * | 2006-03-02 | 2007-09-05 | BRITISH TELECOMMUNICATIONS public limited company | Multi-protocol label switching |
US7616643B2 (en) | 2006-04-19 | 2009-11-10 | Cisco Technology, Inc. | Techniques for integrated routing of call circuit signaling and the internet protocol |
US9155008B2 (en) | 2007-03-26 | 2015-10-06 | Qualcomm Incorporated | Apparatus and method of performing a handoff in a communication network |
US8830818B2 (en) | 2007-06-07 | 2014-09-09 | Qualcomm Incorporated | Forward handover under radio link failure |
US9094173B2 (en) | 2007-06-25 | 2015-07-28 | Qualcomm Incorporated | Recovery from handoff error due to false detection of handoff completion signal at access terminal |
JP5451260B2 (en) * | 2009-08-28 | 2014-03-26 | キヤノン株式会社 | Control device, control system, command transmission method, and program |
US8615241B2 (en) | 2010-04-09 | 2013-12-24 | Qualcomm Incorporated | Methods and apparatus for facilitating robust forward handover in long term evolution (LTE) communication systems |
EP2381621A1 (en) * | 2010-04-21 | 2011-10-26 | Thomson Licensing | Method for evaluating an available path bitrate based on an acknowledgment path selection |
EP2672671A1 (en) | 2012-06-04 | 2013-12-11 | Thomson Licensing | Data transmission using a multihoming protocol such as SCTP |
US10389618B2 (en) * | 2017-01-23 | 2019-08-20 | Cisco Technology, Inc. | Distributing network path information in a network environment |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE69123149T2 (en) * | 1991-09-03 | 1997-03-13 | Hewlett Packard Co | Message routing apparatus |
SE515465C2 (en) * | 1998-12-15 | 2001-08-13 | Telia Ab | Improvements in, or relating to, data transmission systems |
WO2000076126A2 (en) * | 1999-06-07 | 2000-12-14 | Nortel Networks Limited | System and method for loop avoidance in multi-protocol label switching |
CA2319944A1 (en) * | 1999-09-21 | 2001-03-21 | Alcatel Usa Sourcing Lp | System and method for transporting in/ain signaling over an internet protocol (ip) network |
US7600039B2 (en) * | 2000-02-16 | 2009-10-06 | Motorola, Inc. | Label-based multiplexing |
US7099327B1 (en) * | 2000-10-12 | 2006-08-29 | Lucent Technologies Inc. | Data communications networks with high performance and reliability |
US7082102B1 (en) * | 2000-10-19 | 2006-07-25 | Bellsouth Intellectual Property Corp. | Systems and methods for policy-enabled communications networks |
US7099334B2 (en) * | 2001-03-29 | 2006-08-29 | Nortel Networks Limited | ATM over MPLS connection establishment mechanism |
US7542419B2 (en) * | 2001-04-02 | 2009-06-02 | International Business Machines Corporation | Method and apparatus for managing aggregate bandwidth at a server |
US7298700B1 (en) * | 2001-05-24 | 2007-11-20 | At&T Corp. | Method for unidirectional and bidirectional label switched path setup in a label switched network |
-
2001
- 2001-07-10 DE DE10133473A patent/DE10133473C1/en not_active Expired - Fee Related
-
2002
- 2002-07-01 KR KR10-2003-7003429A patent/KR20030059129A/en not_active Application Discontinuation
- 2002-07-01 ES ES02754294T patent/ES2268066T3/en not_active Expired - Lifetime
- 2002-07-01 EP EP02754294A patent/EP1405422B1/en not_active Expired - Fee Related
- 2002-07-01 WO PCT/DE2002/002381 patent/WO2003007484A2/en active IP Right Grant
- 2002-07-01 CN CNA02817688XA patent/CN1554169A/en active Pending
- 2002-07-01 DE DE50208079T patent/DE50208079D1/en not_active Expired - Lifetime
- 2002-07-01 US US10/483,339 patent/US20040243670A1/en not_active Abandoned
- 2002-07-01 JP JP2003513134A patent/JP4008879B2/en not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8908519B2 (en) | 2009-01-19 | 2014-12-09 | Nec Corporation | SCTP communication method |
Also Published As
Publication number | Publication date |
---|---|
CN1554169A (en) | 2004-12-08 |
KR20030059129A (en) | 2003-07-07 |
WO2003007484A2 (en) | 2003-01-23 |
DE50208079D1 (en) | 2006-10-19 |
WO2003007484A3 (en) | 2003-05-30 |
JP4008879B2 (en) | 2007-11-14 |
EP1405422B1 (en) | 2006-09-06 |
ES2268066T3 (en) | 2007-03-16 |
US20040243670A1 (en) | 2004-12-02 |
DE10133473C1 (en) | 2003-02-20 |
EP1405422A2 (en) | 2004-04-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4008879B2 (en) | Method for optimal use of SCTP in an MPLS network | |
JP4627669B2 (en) | Packet transfer apparatus and transfer control method thereof | |
Stewart et al. | SCTP: new transport protocol for TCP/IP | |
US8374095B2 (en) | Connection verification for MPLS label switched paths and pseudowires | |
CN101297516B (en) | Approaches for automatically switching message authentication keys | |
US7706381B2 (en) | Approaches for switching transport protocol connection keys | |
US7706281B2 (en) | Selecting paths in multi-homed transport-layer network associations | |
CN1938982B (en) | Method and apparatus for preventing network attacks by authenticating internet control message protocol packets | |
US20070171828A1 (en) | Method of determining a maximum transmission unit value of a network path using transport layer feedback | |
CN1933486B (en) | IP communication device and IP communication system therefor | |
US6892329B2 (en) | Selective protection for ring topologies | |
US20080137669A1 (en) | Network of nodes | |
US20050201375A1 (en) | Uninterrupted transfer method in IP network in the event of line failure | |
JP5363658B1 (en) | RELAY DEVICE, RELAY DEVICE CONTROL METHOD, AND NETWORK SYSTEM | |
CN109510690B (en) | Method for transmitting messages, network component and computer-readable storage medium | |
US6611874B1 (en) | Method for improving routing distribution within an internet and system for implementing said method | |
US8259717B2 (en) | Transparent network service enhancement | |
CN114631297A (en) | Method and network device for multipath communication | |
KR100810558B1 (en) | Method and devices for header compression in packet-oriented networks | |
US7535916B2 (en) | Method for sharing a transport connection across a multi-processor platform with limited inter-processor communications | |
EP2164208B1 (en) | Method for determining a data transport unit parameter for the communication between two stations in a network of stations and network device adapted to act as a sending station | |
Ravier et al. | Experimental studies of SCTP multi-homing | |
CN101594264B (en) | Method for detecting state of virtual link | |
US20240089198A1 (en) | Packet processing method and system, and network device | |
CN113472666B (en) | Message forwarding method and device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050701 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061227 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070112 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20070323 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20070330 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070706 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070801 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070830 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100907 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100907 Year of fee payment: 3 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100907 Year of fee payment: 3 |
|
R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100907 Year of fee payment: 3 |
|
R370 | Written measure of declining of transfer procedure |
Free format text: JAPANESE INTERMEDIATE CODE: R370 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100907 Year of fee payment: 3 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100907 Year of fee payment: 3 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100907 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110907 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |