JP4548930B2 - ラベル・スイッチング・ルータ - Google Patents

ラベル・スイッチング・ルータ Download PDF

Info

Publication number
JP4548930B2
JP4548930B2 JP2000348004A JP2000348004A JP4548930B2 JP 4548930 B2 JP4548930 B2 JP 4548930B2 JP 2000348004 A JP2000348004 A JP 2000348004A JP 2000348004 A JP2000348004 A JP 2000348004A JP 4548930 B2 JP4548930 B2 JP 4548930B2
Authority
JP
Japan
Prior art keywords
lsp
label
bidirectional
setting
tlv
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.)
Expired - Fee Related
Application number
JP2000348004A
Other languages
English (en)
Other versions
JP2002152263A (ja
Inventor
徹 榎
好織 青柳
祐司 大原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2000348004A priority Critical patent/JP4548930B2/ja
Priority to US09/818,352 priority patent/US6895008B2/en
Publication of JP2002152263A publication Critical patent/JP2002152263A/ja
Application granted granted Critical
Publication of JP4548930B2 publication Critical patent/JP4548930B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]

Description

【0001】
【発明の属する技術分野】
本発明は、ラベル・スイッチング・ルータ(Label Switching Router:以下、LSR)に関し、特にLSP(Label Switched Path)の一端に位置するラベル・スイッチング・ルータに関する。
【0002】
【従来の技術】
図28は、従来のルータが宛先アドレスを参照して第3層でソフトウェア処理によるパケット転送処理を行う様子を示したものである。入口ルータ1から送信されるIPパケットP1は、中間ルータ2を経由して、出口ルータ3に達する。
【0003】
これに対し、図29は、MPLS(Multi Protocol Label Switching)対応ルータであるLSR1〜3によるパケット転送処理を示したものである。MPLSは、FEC(Forwarding Equivalence Class)により指定されるIP通信トラフィックに対して20ビットのラベルを割り当てることにより、第2.5層において固定長ラベル(シム・ヘッダ)でのハードウェア処理によるスイッチングを可能とし、パケットを高速に転送する技術である。
【0004】
同図に示す如く、IPパケットP1は、入口LSR1においてラベルaが付加され、中間LSR2に送信される。中間LSR2では、IPパケットP1のラベルをaからbに付け替えて出口LSR3に送信する。この場合、中間LSR2において、ラベルaは入ラベル、ラベルbは出ラベルとなる。出口LSR3では、ラベルbを削除することにより元のIPパケットP1を得る。
【0005】
また、図30は一般的なLSRの構成例を示したものであり、LSR100は、回線インタフェース101及び106、CPU102、スイッチ103、検索用LSI104、メモリ105、及び検索テーブル用メモリ107によって構成され、これは図29におけるLSR1〜3も同様である。
【0006】
LSR100内のCPU102は、メモリ105に保持された各種データを使用して、MPLS機能を実現するものである。
動作において、回線インタフェース101を介して回線から受信されたフレーム(入ラベルとして例えばラベルaが付加されている)は、スイッチ103に送られる。スイッチ103は、検索用LSI104に対し、入ラベルに対応する出ラベルを問い合わせる。検索用LSI104は、検索テーブル用メモリ107中に保持されているCPU102から設定された検索テーブルを参照して出ラベル(例えばラベルb)を決定する。
【0007】
スイッチ103は、検索用LSI104から通知されたラベルbを出ラベルとして付したフレームを回線インタフェース106を介して、回線上に送信する。
なお、LSRが上述のような動作を行うためには、入ラベルと出ラベルの対応関係を事前に設定してLSPを確立しておく必要がある。このようなLSP設定処理について、図31を参照して以下に説明する。
【0008】
同図において、通信回線70に接続されたLSR100は、MPLS処理部60、ラベル管理部50、及びスイッチ設定部40によって構成されている。MPLS処理部60内には、LSP設定受付部10、メッセージ送信部20、及びメッセージ受信部30が設けられている。
【0009】
通信回線70の先には、LSR100と同一構成を有するLSR200が接続されており、LSR100とLSR200との間にはLSPが設定されるものとする。
LSR100のMPLS処理部60では、外部からのLSP設定要求S1をLSP設定受付部10で受け付けると、LSP設定受付部10の指示S2により、メッセージ送信部20から通信回線70にラベル要求メッセージの送信S3を行う。
【0010】
メッセージ受信側のLSR200では、自分のメッセージ受信部30が、通信回線70からラベル要求メッセージの受信S4を行う。そこで、MPLS処理部60は、ラベル管理部50に対しラベル要求S5を行い、ラベル管理部50から割り当てるべきラベルの通知S5を受ける。このラベルは、メッセージ送信部20でラベル・マッピング・メッセージによりラベル要求メッセージの送信元であるLSR100に対して通知される。
【0011】
ラベル・マッピング・メッセージによりラベルの通知を受けた送信元のLSR100では、MPLS処理部60が、スイッチ設定部40にラベル設定S6を行う。
ここで、MPLSは、既存のルーティングプロトコルと連携することにより自動的にベストエフォート型のLSPを確立するものである。LSPは片方向パスであり、双方向通信を行うためには独立した2本のLSPを必要とする。
【0012】
しかしながら、従来のMPLSでは、1回の操作で片方向LSPを1本しか設定しないため、装置間で双方向通信を行うには、管理者が各LSPの入口となる2台のLSRにおいてそれぞれのLSP設定を行うか、或いは、ネットワーク全体を把握している外部のデータベースサーバが各LSPの入口となる2台のLSRにLSP設定を要求する必要があり、以下のような問題が生じている。
【0013】
(1)入口となる2つのLSRにおいてLSP設定操作を行う場合、上り方向LSP設定と下り方向LSP設定をそれぞれ行う必要があり、双方向にLSPが確立するまでに時間を要するため、即時性がない。
(2)外部のデータベースサーバを使用する場合、ネットワーク規模に応じてデータベース量が膨大し、それに伴い、メモリ量の増大、サーバの負荷が増大する。また、各LSRから必要な情報をサーバに通知する必要があるため、ネットワーク負荷も増大することになる。さらに、ネットワーク規模が大きくなるほど、データベース作成に時間を要し、双方向通信を開始するまでのリアルタイム性が損なわれる。
【0014】
このような問題に対する解決策として、本出願人による平成11年第150634号の特許出願「パケット中継装置」(以下、先願装置と称する。)において双方向LSP設定方式が提案されている。
これは、隣接パケット中継装置とのネゴシエーションにより、ラベルの使用範囲及びディレクショナリティ(方向)を決定し、フォワーディング等価クラスにラベルを割り当てるラベル分配プロトコル処理部が、片方向のフォワーディング等価クラス及びこのフォワーディング等価クラスと逆方向のフォワーディング等価クラスを単一の双方向フォワーディング等価クラスとして扱い、該双方向フォワーディング等価クラスにラベルを割り当てることを特徴としている。
【0015】
図32は、このような先願装置において隣接するLSRであるATM-LSR_AとATM-LSR_Bとの間の同一ラベルの同時割当例を示したものである(一部省略)。
まず、ATM-LSR_Aは、ATM-LSR_Bに送信するラベル要求メッセージS31の中に対称FECが同時割当可である旨の情報を含めておく。そして、ATM-LSR_Bは、ATM-LSR_Aに送信するラベル・マッピング・メッセージS32に、ATM-LSR_Aに割り当てるラベルと共に対称FECの同時割当を行った旨の情報を含めておく。
【0016】
これにより、ATM-LSR_Aによる1回の操作で双方向LSPを設定することが可能となっている。
しかしながら、この先願装置は、隣接パケット中継装置同士のラベル割当方法に特徴を持たせたものであるため、LSP経路に存在する全LSRがこのようなラベル割当機能を備える必要がある。
【0017】
一方、上記の問題(1)及び(2)とは別に、最近では、VOIP(Voice Over IP)やRTP(Real-time Transport Protocol)の登場により、IP通信網におけるサービス品質保証(以下、QoS保証と称することがある。)の必要性が急速に高まっている。 MPLSにおいてQoS保証を提供する技術としては、制約付きルートを扱うラベル分配プロトコルであるCRLDP(Constraint-based Routing Label Distribution Protocol)が知られている。CRLDPでは、QoS保証及びLSP経路を指定して静的にLSPを設定することが可能である。
【0018】
このCRLDPにおけるQoS保証及びLSP経路(明示的ルート)の指定は、それぞれLSPの一端に位置するラベル・スイッチング・ルータが、他端のラベル・スイッチング・ルータに対してLSP設定を要求する際に送信するラベル要求メッセージ内に、トラフィック・パラメータTLV及び明示的ルート・パラメータTLVを設定することにより実現される。
【0019】
インターネットの発展と社会的なインフラ整備により、MPLSにおいて、QoS保証を有する双方向通信の必要性はさらに高まっているが、そのQoS保証の問題については、CRLDPを用いることによって解決が図られている。
【0020】
【発明が解決しようとする課題】
現在のIP通信網では、VOIP通信、ファイル転送、Webブラウジングなどのようなサーバ−クライアント間通信がIPトラフィックの大部分を占めており、そのような通信では必ず双方向通信が必要とされる。
【0021】
しかしながら、双方向通信の問題に対して先願装置を適用するためには、ネットワーク内の中継装置を全て先願装置の機能を有するものに変更する必要があるため、特に大規模なネットワークの場合には導入コストが高騰する。
従って本発明は、CRLDPを用いて設定されるLSPの一端に位置するラベル・スイッチング・ルータにおいて、既存のネットワークを活用することにより双方向LSPを1回の操作で自動的に確立することを目的とする。
【0022】
【課題を解決するための手段】
上記の目的を達成するため、本発明に係るラベル・スイッチング・ルータは、外部からの双方向LSP設定要求を受け付ける双方向LSP設定受付部と、該双方向LSP設定要求に基づき該LSPの他端に位置するラベル・スイッチング・ルータへの上り方向で送信される双方向設定用ラベル要求メッセージに含める双方向LSP設定用TLVを作成する双方向LSP設定TLV作成部と、該メッセージを該LSPの他端に位置するラベル・スイッチング・ルータから受信したとき、該メッセージ中の双方向LSP設定用TLVを分析する双方向LSP設定TLV分析部と、該双方向LSP設定TLV分析部による分析結果に基づき、該上り方向に対する下り方向のLSP設定要求を行う双方向LSP処理部と、該双方向LSP処理部からの該CRLDPに基づく明示的ルートの作成要求に基づき、該下り方向で中継すべきルータを規定した明示的ルートを作成し該双方向LSP処理部に通知する明示的ルート作成部と、を備え、該双方向LSP設定TLV分析部がラベル要求メッセージの応答として受信するラベル・マッピング・メッセージを分析した結果、該ラベル・マッピング・メッセージ内に双方向LSP設定要求が該他端に位置するラベル・スイッチング・ルータで受け付けられたことを示す双方向LSP要求受付情報が設定されていないとき、該双方向LSP処理部が、該他端のラベル・スイッチング・ルータが双方向LSP設定機能を持たないことを認識することを特徴としている(付記1+6)。
【0023】
図1は、請求項1に係る本発明の原理構成例としてLSP(図示せず)の一端に位置するラベル・スイッチング・ルータ100を示したものである。本発明では、図31に示した従来のラベル・スイッチング・ルータ100の構成に加え、MPLS処理部60内に、双方向LSP設定受付部11、双方向LSP設定TLV(Type Length Value)作成部21、双方向LSP設定TLV分析部31、双方向LSP処理部61、及び明示的ルート(Explicit Route)作成部62が二重ブロックで示す如く設けられている。
【0024】
すなわち、請求項1に係る本発明では、LSR100における双方向LSP設定受付部11が、外部からの双方向LSP設定要求S1を受け付け、双方向LSP設定TLV作成部21が該双方向LSP設定要求に基づき該LSPの他端に位置するLSR200への上り方向で送信される双方向設定用ラベル要求メッセージに含めるための双方向LSP設定用TLVを作成する。
【0025】
また、LSR200における双方向LSP設定TLV分析部31は、他端のLSR100が送信した双方向LSP設定用ラベル要求メッセージを受信したとき、該メッセージ中の双方向LSP設定用TLVを分析し、双方向LSP設定TLV分析部31による分析結果に基づいて双方向LSP処理部61が該上り方向に対する下り方向のLSP設定要求を行う。
【0026】
なお、CRLDPにおいては、ラベル要求メッセージが中継すべきルータを「明示的ルート」として規定する必要があり、通常、上り方向の明示的ルートは、外部からの双方向LSP設定要求S1によって与えられている。また、下り方向の明示的ルートは、下り方向のLSP設定要求時に規定する必要がある。
【0027】
そこで、双方向LSP処理部61は、下り方向のラベル要求メッセージが中継すべきルータを規定した明示的ルートの作成を明示的ルート作成部62に要求し、明示的ルート作成部62は、この作成要求に基づき作成した明示的ルートを双方向LSP処理部61に通知する。
【0028】
これにより、双方向LSP処理部61は下り方向の明示的ルートを下り方向LSP設定要求時に規定することができる。
LSR100では、LSR200から従来と同様にラベル・マッピング・メッセージを受信することにより、上り方向のLSPを確立する。また、LSR200から受信する下り方向ラベル要求メッセージに対して、LSR100が従来と同様にしてラベル・マッピング・メッセージを送信することによって、これを受信したLSR200が下り方向のLSPを確立する。
【0029】
これにより、LSPの一端に位置するLSR100による1回の操作によって、LSR100→LSR200及びLSR200→LSR100の双方向LSPを自動的に確立することが可能となる。このように、上り方向のLSPはラベル要求メッセージ及びラベル・マッピング・メッセージによる従来のLSP設定と同様の処理で設定される。また、下り方向のLSPは、上り方向LSPの他端に位置するLSR200が双方向LSP設定TLV分析部31により双方向LSP設定が必要であることを判断して自動的にラベル要求メッセージを下り方向に送信することによって、やはり従来のLSP設定と同様の処理で設定される。
【0030】
CRLDPを用いて設定されるLSPにおいては、LSPの両端を含む全てのラベル・スイッチング・ルータがCRLDPを使用するが、上述のラベル要求メッセージ及びラベル・マッピング・メッセージによるLSP設定処理は、CRLDPにおける基本的な処理である。
【0031】
従って、LSP経路の途中に存在する他のラベル・スイッチング・ルータは、CRLDPを用いること以外に特別な機能を有する必要がない。
さらに、LSR100は、ラベル要求メッセージの応答としてラベル・マッピング・メッセージを受信したとき、双方向LSP設定TLV分析部31でこれを分析し、該ラベル・マッピング・メッセージ内に双方向LSP設定要求が該他端に位置するラベル・スイッチング・ルータで受け付けられたことを示す双方向LSP要求受付情報が設定されていないとき、双方向LSP処理部61が、該他端のLSR200が双方向LSP設定機能を持たないことを認識する。
これにより、双方向LSP設定機能を持たないLSR200に向けて再度双方向LSP設定要求を行うことを防ぐことができるため、無駄な処理を削減することが可能となる。
また、本発明に係るラベル・スイッチング・ルータは、該双方向LSP設定TLV作成部が、該双方向LSP設定TLVに下り方向サービス品質情報を含めてもよい(付記2)。
【0032】
すなわち、図1における双方向LSP設定TLV作成部11は、下り方向サービス品質情報を含んだ双方向LSP設定TLVを作成する。
これにより、上り方向のLSP設定を要求する側のLSR100から下り方向のLSPのサービス品質を指定することができる。例えば、ファイル転送や画像配信の場合のように、上り方向と下り方向の通信トラフィック量が異なるとき、上り方向LSP及び下り方向LSPにそれぞれ適したサービス品質を指定することが可能となる。
【0033】
また、本発明に係るラベル・スイッチング・ルータは、該双方向LSP設定TLV作成部が、該双方向LSP設定TLVに下り方向の明示的ルート情報を含めもよい(付記3)。
すなわち、図1における双方向LSP設定TLV作成部11は、下り方向の明示的ルート情報を含んだ双方向LSP設定TLVを作成する。
【0034】
これにより、上り方向のLSP設定を要求する側のLSR100から下り方向のLSPが経由すべき明示的ルートを指定することが可能となる。
また、本発明に係るラベル・スイッチング・ルータは、該双方向LSP設定TLV作成部が、該上り方向のLSP情報変更要求時に送信するラベル要求メッセージに双方向LSP設定情報を設定してもよい(付記4)。
【0035】
すなわち、図1における双方向LSP設定TLV作成部11は、既存のLSPの設定を変更する場合、該上り方向のLSP情報変更要求時に送信するラベル要求メッセージに双方向LSP設定情報を設定する。
これにより、上り方向のLSP設定変更と同時に下り方向のLSPの設定変更を、LSPの一端に位置するLSR100による1回の操作で自動的に行うことができる。
【0036】
また、本発明に係るラベル・スイッチング・ルータは、該双方向LSP設定TLV作成部が、該上り方向のLSP削除要求時に送信するラベル解放メッセージに双方向LSP削除情報を設定してもよい(付記5)。
すなわち、図1における双方向LSP設定TLV作成部11は、既存のLSPを解放するとき、上り方向のLSP削除要求時に送信するラベル解放メッセージに双方向LSP削除情報を設定する。
【0037】
これにより、上り方向のLSP解放と同時に下り方向のLSPの解放をLSPの一端に位置するLSR100による1回の操作で行うことができる
【0039】
た、上記双方向LSP設定用TLVはベンダー・プライベートTLVであればよい(付記7)。
【0040】
【発明の実施の形態】
本発明に係るラベル・スイッチング・ルータの実施例(1)〜(6)について、図2〜図27を参照して以下に説明する。なお、各実施例に共通の事項として、設定されるLSPの両端に位置するLSRが、図1に示すLSR100と同様の構成を有することを前提とし、同図の符号を参照するものとする。
【0041】
また、実施例(1)〜(6)においてはCRLDPが用いられるため、特に言及しない限り、各LSRは通常の処理を行うものとする。
すなわち、以下の説明における共通の事項として、上り方向ラベル要求メッセージには、通常通り、外部からの要求に従ってQoS保証及び明示的ルートの情報がそれぞれトラフィック・パラメータTLV及び明示的ルート・パラメータTLVに設定されているものとする。
【0042】
これにより、上り方向LSPは、従来から行われているように、外部からの要求に応じたQoS保証及びLSP経路を有するようになる。
実施例 (1)
実施例(1)は、LSPの一端に位置するラベル・スイッチング・ルータによる1回のLSP設定要求にて双方向LSPを確立する実施例である。
【0043】
図2は、実施例(1)を説明するためのネットワーク構成例(1)を示したものであり、端末A及び端末BがそれぞれLSR1及びLSR3に接続されており、各LSR1〜4は図示の如く接続されてネットワークを構成しているものとする。
また、LSR1及びLSR3は、図1のLSR100及びLSR200にそれぞれ相当し、双方向LSP設定機能を有しているものとする。
【0044】
LSR1対し、外部から、端末A−端末B間に対する双方向LSP設定要求S1が発生すると、LSR1のLSP設定受付部10内の双方向LSP設定受付部11がこの要求S1を受け付ける。
図3は、このときの双方向LSP設定受付部11の処理フローを示したものである。
まず、双方向LSP設定受付部11は、双方向LSP処理部61へLSR3の双方向LSP設定機能の有無識別を問い合せる(ステップS100)。
【0045】
双方向LSP処理部61では、LSR3を図4に示す双方向LSP設定機能無しLSR一覧テーブルより検索し、LSR3がこのテーブルに含まれていないことから、双方向LSP設定機能を有することを、双方向LSP設定受付部11へ通知する。
なお、双方向LSP設定機能無しLSR一覧テーブルの登録動作については、実施例(6)で説明する。
【0046】
次に、双方向LSP設定受付部11は、双方向LSP処理部61からの通知に基づきLSR3が双方向LSP設定機能を有していることを認識し(同S110)、メッセージ送信部20に対して、上り方向のラベル要求メッセージの送信を要求する(同S120)。
なお、LSR3が双方向LSP設定機能を有していない場合、双方向LSP設定受付部11は外部に対し双方向LSP設定不可通知を送信することになる(同S130)。
【0047】
次に、図5を参照して、双方向LSP設定受付部11から上り方向のラベル要求メッセージ送信要求を受けたメッセージ送信部20の処理動作について説明する。
メッセージ送信部20は、内蔵する双方向LSP設定TLV作成部21に対して、双方向LSP設定を行うためにラベル要求メッセージ内に含めるべきベンダー・プライベート(Vendor Private)TLVの作成を要求し(同S200)、作成されたベンダー・プライベートTLVを含めた上り方向ラベル要求メッセージを送信する(同S210)。
【0048】
図6は、双方向設定の情報を含めたベンダー・プライベートTLVのフォーマットを示したものである。このベンダー・プライベートTLVは、Uビット、Fビット、タイプ、長さ、ベンダーID、及びデータによって構成されている。本発明で使用するベンダー・プライベートTLVでは、中継LSRがベンダー・プライベートTLVを破棄せずに出口LSRまで中継できるよう、Uビット及びFビットの値は1に固定する。
【0049】
また、ベンダー・プライベートTLVとして使用可能なタイプの値は0x3E00-0x3EFFであるが、実施例(1)では、双方向設定であることを示す値として"0x3E00"を設定する。
また、長さはベンダーIDとデータフィールドの合計をオクテット表示したものであり、データフィールドには、送信元IPアドレス、送信先IPアドレス、プロトコル、送信元ポート番号、及び、送信先ポート番号から成るフロー情報や、後述するトラフィック・パラメータTLV又は明示的ルート・パラメータTLVが必要に応じて設定される。
【0050】
なお、実施例(1)では、下り方向のサービス品質や明示的ルートの指定を行わないこととし、同図のデータフィールドにはトラフィック・パラメータTLV及び明示的ルート・パラメータTLVを含めない。
LSR1から送信されたラベル要求メッセージは、LSR2を経由してLSR3によって受信される。
【0051】
図7は、LSR3における、ラベル要求メッセージ受信時のメッセージ受信部30の処理フローを示したものである。
まず、メッセージ受信部30は内蔵する双方向LSP設定TLV分析部31に対し、受信したラベル要求メッセージ内のベンダー・プライベートTLVに下り方向LSP設定情報が有るか否かの分析を要求する(同S300)。
【0052】
次に、メッセージ受信部30は、双方向LSP設定TLV分析部31による分析結果を受け、下り方向LSP設定情報の有無を判断する(同S310)。
下り方向LSP設定情報が無い場合(双方向LSP設定要求ではない場合)、メッセージ受信部30は、MPLS処理部60に対してラベル・マッピング・メッセージの送信を要求する(同S330)。MPLS処理部60では、従来と同様の処理により、ラベル管理部50へラベルの割当を要求し、完了通知を受けると、ラベル設定をスイッチ設定部40に依頼した後、LSR1へラベル・マッピング・メッセージを送信する。
【0053】
下り方向LSP設定情報が有る場合、メッセージ受信部30は、双方向LSP処理部61に対して双方向LSP処理要求を行う(同S320)。
図7は、双方向LSP処理部61の処理フローを示したものである。まず、双方向LSP処理部61は、ラベル・マッピング・メッセージが送信済みであるか否かを判定する(同S400)。
【0054】
ラベル・マッピング・メッセージ未送信の場合、双方向LSP処理部61は、LSR1へ送信するラベル・マッピング・メッセージ内に含めるべきベンダー・プライベートTLV内に双方向LSP設定要求を受け付けたことを示す設定受付情報を設定(同S410)した後、MPLS処理部60に対してラベル・マッピング・メッセージの送信を要求する(同S420)。この要求を受けたMPLS処理部60では、従来処理と同様に、LSR1へラベル・マッピング・メッセージを送信する。
【0055】
なお、図9には、設定受付を示すタイプ"0x3E02"が設定されたベンダー・プライベートTLVのフォーマットが示されている。なお、このベンダー・プライベートTLVには、データフィールドは設定されていない。
ラベル・マッピング・メッセージ送信済の場合、双方向LSP処理部61は、上り方向ラベル要求メッセージ内のベンダー・プライベートTLVに明示的ルート情報が存在するか否かを判定する(同S430)。
【0056】
実施例(1)の場合は明示的ルートが存在しないため、双方向LSP処理部61は、明示的ルート作成部62に対し明示的ルートの作成を要求する(同S480)。この場合、明示的ルート作成部62では、上り方向ラベル要求メッセージ内のパス・ベクトルTLVの情報に基づき明示的ルートを作成し、作成完了通知を双方向LSP処理部61へ通知する。
【0057】
これにより、双方向LSP処理部61は、下り方向の明示的ルートを下り方向ラベル要求メッセージ内の明示的ルートTLVに設定する(同S440)。
なお、図10は、パス・ベクトルTLVのフォーマットを示したものであり、図示の如くパス・ベクトルであることを示すタイプ"0x0104"、及び値として上り方向で中継したLSRのIDが設定されている。
【0058】
その後、双方向LSP処理部61では、上り方向ラベル要求メッセージ内のLSPを識別するためのLSP・ID(例えば"1")と、下り方向へ送信するラベル要求メッセージ内のLSP・ID(例えば"2")との対応関係を記憶し、図11に示す如くLSP・ID対応テーブルに追加する(同S450)。
【0059】
さらに、双方向LSP処理部61では、受信したラベル要求メッセージ内のベンダー・プライベートTLVに含まれる送信元IPアドレス、送信先IPアドレス、プロトコル番号、送信元ポート番号、及び送信先ポート番号をフロー情報として読み出し保持する(同S460)。
【0060】
その後、双方向LSP処理部61では、LSP設定受付部10に対しLSPの設定を要求する(同S470)。
その後は、LSP設定受付部10からのメッセージ送信要求により、メッセージ送信部20は、下り方向ラベル要求メッセージを送信する。そして、LSR1よりラベル・マッピング・メッセージを受信すると、LSR3はLSR1の指定による下り方向LSPを確立する。その後、LSR3では確立した下り方向LSPに対して、保持していたフロー情報を設定する。
【0061】
フロー情報を設定する理由は、LSPを確立しただけでは、ただのトンネルが出来ているに過ぎず、確立したLSPに対して、どのようなフローを割り当てるかを設定する必要があるためである。
このように、LSR1による1回のLSP設定要求にて双方向LSPを確立することが可能となる。
【0062】
実施例 (2)
実施例(2)は、入口LSRにおいて下り方向のQoSを指定する実施例である。
図12は、実施例(2)を説明するためのネットワーク構成例(2)であり、LSR1及びLSR3は、本発明の双方向LSP設定機能を有するものとする。
【0063】
LSR1について、外部から端末A-B間に対するQoS指定の双方向LSP設定要求が発生した場合、LSR1のLSP設定受付部10内の双方向LSP設定受付部11及びメッセージ送信部20における処理は、図3及び5に示した実施例(1)における処理と同様に実行される。
【0064】
但し、メッセージ送信部20内の双方向LSP設定TLV作成部21にて作成されるベンダー・プライベートTLVは、実施例(1)を示す図6とは異なり、図13に示す如くQoS情報としてのトラフィック・パラメータTLVがデータフィールドに追加されたものとなる。
【0065】
LSR3におけるラベル要求メッセージ受信時のメッセージ受信部30の処理は、図7に示した実施例(1)の場合と同様である。
図14は、QoS指定の双方向LSP処理要求時の、双方向LSP処理部61の処理フローを示したものであり、同図は、図8に示した実施例(1)におけるステップS460とステップS470との間にステップS465が追加されたものとなっている。
【0066】
すなわち、ステップS470において、LSP設定受付部10へLSP設定要求を行う前に、受信したラベル要求メッセージ内のベンダー・プライベートTLVに含まれるQoS情報であるトラフィック・パラメータTLVを読み出し、下り方向に送信するラベル要求メッセージ内のトラフィック・パラメータTLVへ設定する(同S465)。
【0067】
このようにして、LSR1において、下り方向のQoS指定が可能となる。
なお、図15は実施例(2)の場合の双方向LSP設定メッセージのシーケンスを示したものであり、LSR1に対し端末A-B間に1MbpsのLSPを設定する外部要求S20があった場合、LSR1がベンダー・プライベートTLVに双方向設定及び下り方向(端末B→A)の帯域指定を1Mbpsとしたラベル要求メッセージS21をLSR2宛に送信する。
【0068】
これを受けたLSR2では、メッセージS21と同様なラベル要求メッセージS22をLSR3宛に送信する。
LSR3では、ラベル要求メッセージS22内のベンダー・プライベートTLVに基づき、双方向LSP設定のための処理を行う。このとき、LSR3は、双方向のLSP・IDの対応関係を記憶すると共に指定帯域(1Mbps)で下り方向LSPを設定S13することになる。
【0069】
LSR3は、従来と同様に、ラベル要求メッセージS22に対する応答となるラベル・マッピング・メッセージS24をLSR2宛に送信するが、メッセージS24内のベンダー・プライベートTLVには設定受付情報が含まれる。
また、LSR3は、下り方向のLSP設定に必要となるラベル要求メッセージS26をLSR2宛に送信する。
【0070】
LSR2は、ラベル・マッピング・メッセージS24及びラベル要求メッセージS26を受信すると、ラベル・マッピング・メッセージS25及びラベル要求メッセージS27をそれぞれLSR1宛に送信する。
LSR1は、メッセージS25を受信することにより、上り方向のLSPを確立する。
【0071】
また、LSR1は、ラベル要求メッセージS27に対する応答として、ラベル・マッピング・メッセージS28をLSR2宛に返送し、LSR2はこれを受けてラベル・マッピング・メッセージS29をLSR3宛に送信する。
LSR3は、メッセージS29を受信することにより、下り方向のLSPを確立する。
【0072】
なお、1Mbpsの帯域指定を除くことにより、同図はそのまま実施例(1)におけるメッセージシーケンスを示すものであり、実施例(1)及び(2)から明らかなように、LSR2は双方向LSP設定機能を必要としない。
実施例 (3)
実施例(3)は、入口LSRにおいて下り方向の明示的ルートを指定する実施例である。
【0073】
図16は、実施例(3)を説明するためのネットワーク構成例(3)である。同図中のLSR1及びLSR3は、本発明の双方向LSP設定機能を有するものとする。
LSR1に対し、外部から、端末A-B間に対する下り方向明示的ルート指定(LSR3→LSR4→LSR1)の双方向LSP設定要求が発生した場合、LSP設定受付部10内の双方向LSP設定受付部11の処理は、図3に示した実施例(1)と同様である。
【0074】
また、メッセージ送信部20の処理も図5に示した実施例(1)の場合と同様である。但し、双方向LSP設定TLV作成部21が作成するベンダー・プライベートTLVは、図6に示す実施例(1)の場合と異なり、図17に示す如くデータとして明示的ルート・パラメータTLVが追加されたものとなる。
【0075】
また、LSR3におけるメッセージ受信部30及び双方向処理部61の処理フローは、それぞれ図7及び8に示す如く実施例(1)の場合と同様である。但し、図8のステップS430において、明示的ルート有りと判定されるため、ステップS480は実行せずにステップS440が実行される。
【0076】
この場合、受信したラベル要求メッセージ内のベンダー・プライベートTLVに含まれた下り方向の明示的ルート(LSR3→LSR4→LSR1)が下り方向のラベル要求メッセージ内のベンダー・プライベートTLV内に設定される。
なお、実施例(1)の場合と同様にして、LSR3からのラベル・マッピング・メッセージがLSR1に送信され、LSR1→LSR2→LSR3の上り方向LSPが確立された場合を想定すると、実施例(3)の場合は、下り方向の明示的ルートの指定があるため、下り方向のLSPは上り方向とは異なり、LSR4を経由する。
【0077】
従って、LSR3はLSR4経由で下り方向ラベル要求メッセージを送信する。そして、LSR1よりラベル・マッピング・メッセージを受信すると、下り方向の明示的ルート指定(LSR3→LSR4→LSR1)のLSPが確立する。
その後、LSR3では確立した下り方向LSPに対して、保持していたフロー情報を設定する。
【0078】
このように、LSR2及びLSR4は共に双方向LSR設定機能を有していないが、LSR1にて下り方向の明示的ルートを指定することが可能となる。
実施例 (4)
実施例(4)は、入口LSRが下り方向LSPの設定内容を変更する実施例である。
【0079】
この実施例(4)は、上述の実施例(2)を前提としており、端末A-B間には既に1Mbps帯域保証のLSPが双方向に確立しているものとする。
今、LSR1に対して、外部から下り方向LSPに3Mbpsの帯域保証への変更要求が発生した場合を想定する。
【0080】
LSR1のLSP設定受付部10内の双方向LSP設定受付部11において、双方向LSP設定変更要求を受け付け、メッセージ送信部20に対して、上り方向のラベル要求メッセージの送信を要求する(図18のステップS120)。
メッセージ送信部20では、図5に示した処理が行われるが、このとき双方向LSP設定TLV作成部21がラベル要求メッセージ内のActフラグをセットし、ラベル要求メッセージ内のベンダー・プライベートTLVを作成し、上り方向のラベル要求メッセージを送信する。
【0081】
なお、Actフラグは、LSPに対する動作を指示するものであり、"0"はLSP設定指示、"1"はLSP情報変更指示を意味する。
図19は、双方向設定変更の場合のベンダー・プライベートTLVのフォーマットを示したものであり、タイプとして双方向設定変更を示す"0x3E01"が設定されており、データとして変更情報が設定されている。
【0082】
LSR3におけるラベル要求メッセージ受信時のメッセージ受信部30の処理も図7に示した実施例(1)の場合と同様である。
図20は、変更指定の双方向LSP処理要求時の、双方向LSP処理部61の処理フローを示したものである。この場合、既に下り方向のLSPが確立しているため、ステップS500〜S520はそれぞれ図8に示したステップS400〜S420と同様の処理であるが、ステップS500でラベル・マッピング・メッセージが送信済みと判断された場合の処理が図8の場合と異なっている。
【0083】
すなわち、双方向LSP処理部61は、上り方向ラベル要求メッセージ内のLSP・IDより、図11に示すLSP・ID対応テーブルを検索し、下り方向のLSP・IDを導き(ステップS530)、これを下り方向のラベル要求メッセージ内に設定する(同S540)。
この時、ラベル要求メッセージにActフラグをセットする。
【0084】
さらに、受信したラベル要求メッセージ内のベンダー・プライベートTLVに含まれる変更情報(ここでは、3Mbpsの帯域保証)を読み出し、下り方向ラベル要求メッセージ内のトラフィック・パラメータTLVに設定する(同S550)。その後、LSP設定受付部10に対し、LSPの設定変更を要求する(同S560)。
【0085】
LSP設定受付部10では、従来と同様の処理によって下り方向ラベル要求メッセージを送信し、LSR1からのラベル・マッピング・メッセージを受信することにより、下り方向LSPの設定情報が3Mbpsの帯域保証に変更される。
このように、入口LSRが下り方向LSPの設定内容を変更することが可能となる。
【0086】
図21は、設定変更の場合のメッセージシーケンスを示したものであり、端末A-B間のLSPを3Mbpsに変更する外部要求S30があると、LSR1は、下り方向の帯域保証を3Mbpsに変更する情報をベンダー・プライベートTLVに設定したラベル要求メッセージS31をLSR2宛に送信する。
【0087】
以降、図15と同様のメッセージシーケンスによって双方向の帯域保証が3Mbpsに変更されることとなる。
但し、LSR3がラベル要求メッセージS32を受信したとき、図15の場合と異なり、既に双方向のLSPが確立しているため、LSR3はLSP・ID対応テーブルを検索することにより下り方向LSPを導き、指定された帯域への設定変更要求S33を下り方向LSPに与えることになる。
【0088】
実施例 (5)
実施例(5)は、実施例(1)、(2)、又は (4)によって図2又は図12に示す端末A-B間のLSR1−LSR2−LSR3に既に双方向LSPが確立していることを前提として、入口LSR1において下り方向のLSP削除を指定する実施例である。
【0089】
図22は、LSR1において、外部から双方向LSP削除要求が発生した場合のLSP設定受付部10内の双方向LSP設定受付部11における処理フローを示したものである。双方向LSP設定受付部11は、双方向LSP設定要求を受け付けると、メッセージ送信部20に対して、上り方向のラベル解放メッセージの送信を要求する(ステップS140)。
【0090】
図23は、メッセージ送信部20の処理フローを示したものである。メッセージ送信部20は、まず、双方向LSP設定TLV作成部21に対して、ラベル解放メッセージ内に含めるベンダー・プライベートTLVの作成を要求する(同S200)。
次に、メッセージ送信部20は、作成されたベンダー・プライベートTLVを含めた上り方向ラベル解放メッセージを送信する(同S220)。
【0091】
なお、ステップS200において、双方向LSP設定TLV作成部21が作成する双方向削除のためのベンダー・プライベートTLVは、図24に示す通り双方向削除であることを示すタイプ"0x3E03"が設定されている。また、このベンダー・プライベートTLVにはデータは設定されない。
【0092】
LSR3では、ラベル解放メッセージを受信すると、MPLS処理部60における従来処理と同様に上り方向LSPを削除すると共に、メッセージ受信部30が図25に示す処理を行う。
まず、メッセージ受信部30は、内部の双方向LSP設定TLV分析部31に対し、ラベル解放メッセージ内のベンダー・プライベートTLVの分析を要求する(同S300)。この分析結果に基づき、下り方向LSP削除情報の有無を判断する(同S310)。下り方向LSP削除情報が無い場合は処理を終了し、下り方向LSP削除情報が有る場合は、双方向LSP処理部61に対して、双方向LSP処理を要求する(同S320)。
【0093】
図26は、ラベル解放メッセージ受信時における双方向LSP処理部61の処理フローを示したものである。双方向LSP処理部61では、ラベル解放メッセージ内に設定されているLSP・IDにより、LSP・ID対応テーブルから下り方向のLSP・IDを検索し(同S600)、これを、下り方向のラベル解放メッセージ内に設定する(同S610)。
【0094】
その後、双方向LSP処理部61は、LSP設定受付部10に対し、LSPの削除を要求する(同S620)。
これにより、LSP設定受付部10及びメッセージ送信部20による従来と同様の処理によって、下り方向ラベル解放メッセージが送信され、下り方向LSPが削除される。
【0095】
このように、入口LSRが出口LSRに対して、下り方向LSPの削除を要求することが可能となる。
図27は、双方向LSP削除のメッセージシーケンスを示したものである。LSR1が端末A-B間の双方向LSP削除の外部要求S40を受けると、双方向削除を設定したベンダー・プライベートTLVを含むラベル解放メッセージS41をLSR2宛に送信する。
【0096】
LSR2では、同様に双方向削除を設定したベンダー・プライベートTLVを含むラベル解放メッセージS42をLSR3宛に転送する。LSR3がメッセージS42を受信することによって上り方向のLSPが削除される。
LSR3では、LSP・ID対応テーブルを検索し、下り方向のLSPを導き、削除要求を行う。この場合、LSR3はLSR2宛にラベル解放メッセージS44を送信する。また、メッセージS44を受信したLSR2は、ラベル解放メッセージS45をLSR1宛に送信する。
【0097】
LSR1がメッセージS45を受信することによって下り方向のLSPが削除され、双方向LSPの削除が完了する。
実施例 (6)
実施例(6)は、入口LSRにて、出口LSRの双方向LSP設定機能の有無を記憶することにより、双方向LSP設定の失敗の繰り返しを回避する実施例である。
【0098】
例えば、図12に示すネットワーク構成例(2)において、LSR1のみが本発明の双方向LSP設定機能を有する場合を想定する。
実施例(1)の場合と同様にして、LSR1から上り方向のラベル要求メッセージを受信すると、LSR3では、従来処理と同様に、ラベル・マッピング・メッセージを送信し、これにより上り方向のLSPが確立する。
【0099】
しかしながら、LSR3は双方向LSP設定機能を備えていないため、実施例(1)の場合と異なり、LSR3が送信するラベル・マッピング・メッセージ内には、図9のような設定受付のベンダー・プライベートTLVは含まれない。
そこで、LSR1では、LSR3からのラベル・マッピング・メッセージを受信すると、メッセージ受信部30内の双方向LSP設定TLV分析部31にて、ラベル・マッピング・メッセージ内のベンダー・プライベートTLVに設定受付情報が設定されていないことを認識する。
【0100】
また、メッセージ受信部30は、双方向LSP処理部61に対しLSR3が双方向LSP設定機能を持たないLSRであることを通知する。双方向LSP処理部61では、LSR3を図4に示す双方向LSP設定機能無しLSRテーブルに登録する。
この後、再びLSR1に対し外部から端末A-B間のLSR1−LSR2−LSR3に双方向LSPを設定する要求があった場合、図3におけるステップS100において、双方向LSP設定受付部11が、双方向LSP設定要求を受け付け、双方向LSP処理部61へ、LSR3の双方向LSP設定機能の有無を問い合わせる。
【0101】
このとき、双方向LSP処理部61では、LSR3が双方向LSP設定機能無しLSR一覧テーブルに登録されていることを認識し、LSR3が双方向LSP設定機能無しLSRであることを双方向LSP設定受付部11へ通知する。
通知を受けた双方向LSP設定受付部11は、外部に対して、双方向LSP設定不可であることを通知する(同S130)。
【0102】
このように、あるLSRが双方向LSP設定機能を持たないことを認識することにより、再度同LSRに対し双方向LSP設定要求が発生した場合に、その要求を棄却することが可能となる。
(付記1)
CRLDPを用いて設定されるLSPの一端に位置するラベル・スイッチング・ルータにおいて、
外部からの双方向LSP設定要求を受け付ける双方向LSP設定受付部と、
該双方向LSP設定要求に基づき該LSPの他端に位置するラベル・スイッチング・ルータへの上り方向で送信される双方向設定用ラベル要求メッセージに含める双方向LSP設定用TLVを作成する双方向LSP設定TLV作成部と、
該メッセージを該他端のラベル・スイッチング・ルータから受信したとき、該メッセージ中の双方向LSP設定用TLVを分析する双方向LSP設定TLV分析部と、
該双方向LSP設定TLV分析部による分析結果に基づき、該上り方向に対する下り方向のLSP設定要求を行う双方向LSP処理部と、
該双方向LSP処理部からの該CRLDPに基づく明示的ルートの作成要求に基づき、該下り方向で中継すべきルータを規定した明示的ルートを作成し該双方向LSP処理部に通知する明示的ルート作成部、
を備えたことを特徴とするラベル・スイッチング・ルータ。
【0103】
(付記2)付記1において、
該双方向LSP設定TLV作成部が、該双方向LSP設定TLVに下り方向サービス品質情報を含めることを特徴とするラベル・スイッチング・ルータ。
(付記3)付記1において、
該双方向LSP設定TLV作成部が、該双方向LSP設定TLVに下り方向の明示的ルート情報を含めることを特徴とするラベル・スイッチング・ルータ。
【0104】
(付記4)付記1において、
該双方向LSP設定TLV作成部が、該上り方向のLSP情報変更要求時に送信するラベル要求メッセージに双方向LSP設定情報を設定することを特徴とするラベル・スイッチング・ルータ。
【0105】
(付記5)付記1において、
該双方向LSP設定TLV作成部が、該上り方向のLSP削除要求時に送信するラベル解放メッセージに双方向LSP削除情報を設定することを特徴とするラベル・スイッチング・ルータ。
【0106】
(付記6)付記1において、
該双方向LSP設定TLV分析部がラベル要求メッセージの応答として受信するラベル・マッピング・メッセージを分析した結果、該ラベル・マッピング・メッセージ内に双方向LSP設定要求が該他端に位置するラベル・スイッチング・ルータで受け付けられたことを示す双方向LSP要求受付情報が設定されていないとき、該双方向LSP処理部が、該他端のラベル・スイッチング・ルータが双方向LSP設定機能を持たないことを認識することを特徴とするラベル・スイッチング・ルータ。
【0107】
(付記7)付記1において、
該双方向LSP設定用TLVがベンダー・プライベートTLVであることを特徴とするラベル・スイッチング・ルータ。
【0108】
【発明の効果】
以上説明したように、本発明に係るラベル・スイッチング・ルータは、LSP経路の途中に存在する他のラベル・スイッチング・ルータの機能に拘らず双方向LSPを1回の操作で確立することができる。
【図面の簡単な説明】
【図1】本発明に係るラベル・スイッチング・ルータの原理構成例を示したブロック図である。
【図2】本発明に係るラベル・スイッチング・ルータの実施例(1)を説明するためのネットワーク構成図である。
【図3】本発明に係るラベル・スイッチング・ルータの実施例(1)における双方向LSP設定受付部11の処理フロー(外部から双方向LSP設定要求時)を示したフローチャートである。
【図4】本発明に係るラベル・スイッチング・ルータの実施例(1)における双方向LSP設定機能無しLSR一覧のテーブル例を示した図である。
【図5】本発明に係るラベル・スイッチング・ルータの実施例(1)におけるメッセージ送信部20の処理フロー(上り方向ラベル要求メッセージ送信要求時)を示したフローチャートである。
【図6】本発明に係るラベル・スイッチング・ルータの実施例(1)におけるベンダー・プライベートTLVのフォーマット(双方向設定)を示した図である。
【図7】本発明に係るラベル・スイッチング・ルータの実施例(1)におけるメッセージ受信部30の処理フロー(上り方向ラベル要求メッセージ受信時)を示したフローチャートである。
【図8】本発明に係るラベル・スイッチング・ルータの実施例(1)における双方向LSP処理部61の処理フロー(双方向LSP処理要求時)を示したフローチャートである。
【図9】本発明に係るラベル・スイッチング・ルータの実施例(1)におけるベンダー・プライベートTLVのフォーマット(設定受付)を示した図である。
【図10】本発明に係るラベル・スイッチング・ルータの実施例(1)におけるパスベクトルTLVのフォーマットを示した図である。
【図11】本発明に係るラベル・スイッチング・ルータの実施例(1)におけるLSP・ID対応テーブル例を示した図である。
【図12】本発明に係るラベル・スイッチング・ルータの実施例(2)を説明するためのネットワーク構成図である。
【図13】本発明に係るラベル・スイッチング・ルータの実施例(2)におけるベンダー・プライベートTLVのフォーマット(QoS指定の双方向設定)を示した図である。
【図14】本発明に係るラベル・スイッチング・ルータの実施例(2)における双方向LSP処理部61の処理フロー(QoS指定の双方向LSP処理要求時)を示したフローチャートである。
【図15】本発明に係るラベル・スイッチング・ルータの実施例(2)における双方向LSP設定メッセージシーケンスを示した図である。
【図16】本発明に係るラベル・スイッチング・ルータの実施例(3)を説明するためのネットワーク構成図である。
【図17】本発明に係るラベル・スイッチング・ルータの実施例(3)におけるベンダー・プライベートTLVのフォーマット(明示的ルート指定の双方向設定)を示した図である。
【図18】本発明に係るラベル・スイッチング・ルータの実施例(4)における双方向LSP設定受付部11の処理フロー(外部から双方向LSP設定変更要求時)を示したフローチャートである。
【図19】本発明に係るラベル・スイッチング・ルータの実施例(4)におけるベンダー・プライベートTLVのフォーマット(双方向設定変更)を示した図である。
【図20】本発明に係るラベル・スイッチング・ルータの実施例(4)における双方向LSP処理部61の処理フロー(変更指定の双方向LSP処理要求時)を示したフローチャートである。
【図21】本発明に係るラベル・スイッチング・ルータの実施例(4)における双方向LSP設定メッセージシーケンスを示した図である。
【図22】本発明に係るラベル・スイッチング・ルータの実施例(5)における双方向LSP設定受付部11の処理フロー(外部から双方向LSP削除要求時)を示したフローチャートである。
【図23】本発明に係るラベル・スイッチング・ルータの実施例(5)におけるメッセージ送信部20の処理フロー(上り方向ラベル解放メッセージ送信要求時)を示したフローチャートである。
【図24】本発明に係るラベル・スイッチング・ルータの実施例(5)におけるベンダー・プライベートTLVのフォーマット(双方向削除)を示した図である。
【図25】本発明に係るラベル・スイッチング・ルータの実施例(5)におけるメッセージ受信部30の処理フロー(上り方向ラベル解放メッセージ受信時)を示したフローチャートである。
【図26】本発明に係るラベル・スイッチング・ルータの実施例(5)における双方向LSP処理部61の処理フロー(ラベル解放メッセージ受信時)を示したフローチャートである。
【図27】本発明に係るラベル・スイッチング・ルータの実施例(5)における双方向LSP削除メッセージシーケンスを示した図である。
【図28】従来のルータによるパケット中継を説明するための図である。
【図29】一般的なMPLS対応ルータによるパケット中継を説明するための図である。
【図30】一般的なLSRの構成を示したブロック図である。
【図31】従来のLSRによるLSP設定処理を示すためのブロック図である。
【図32】先願装置における同一ラベルの同時割当例を説明するためのシーケンス図である。
【符号の説明】
1〜4, 100, 200 ルータ又はLSR
10 LSP設定受付部
11 双方向LSP設定受付部
20 メッセージ送信部
21 双方向LSP設定TLV作成部
30 メッセージ受信部
31 双方向LSP設定TLV分析部
40 スイッチ設定部
50 ラベル管理部
60 MPLS処理部
61 双方向LSP処理部
62 明示的ルート作成部
70 通信回線
101, 106 回線インタフェース
102 CPU
103 スイッチ
104 検索用LSI
105 メモリ
107 検索テーブル用メモリ
図中、同一符号は同一又は相当部分を示す。

Claims (5)

  1. CRLDPを用いて設定されるLSPの一端に位置するラベル・スイッチング・ルータにおいて、
    外部からの双方向LSP設定要求を受け付ける双方向LSP設定受付部と、
    該双方向LSP設定要求に基づき該LSPの他端に位置するラベル・スイッチング・ルータへの上り方向で送信される双方向設定用ラベル要求メッセージに含める双方向LSP設定用TLVを作成する双方向LSP設定TLV作成部と、
    該メッセージを該LSPの他端に位置するラベル・スイッチング・ルータから受信したとき、該メッセージ中の双方向LSP設定用TLVを分析する双方向LSP設定TLV分析部と、
    該双方向LSP設定TLV分析部による分析結果に基づき、該上り方向に対する下り方向のLSP設定要求を行う双方向LSP処理部と、
    該双方向LSP処理部からの該CRLDPに基づく明示的ルートの作成要求に基づき、該下り方向で中継すべきルータを規定した明示的ルートを作成し該双方向LSP処理部に通知する明示的ルート作成部、
    を備え、該双方向LSP設定TLV分析部がラベル要求メッセージの応答として受信するラベル・マッピング・メッセージを分析した結果、該ラベル・マッピング・メッセージ内に双方向LSP設定要求が該他端に位置するラベル・スイッチング・ルータで受け付けられたことを示す双方向LSP要求受付情報が設定されていないとき、該双方向LSP処理部が、該他端のラベル・スイッチング・ルータが双方向LSP設定機能を持たないことを認識することを特徴とするラベル・スイッチング・ルータ。
  2. 請求項1において、
    該双方向LSP設定TLV作成部が、該双方向LSP設定TLVに下り方向サービス品質情報を含めることを特徴とするラベル・スイッチング・ルータ。
  3. 請求項1において、
    該双方向LSP設定TLV作成部が、該双方向LSP設定TLVに下り方向の明示的ルート情報を含めることを特徴とするラベル・スイッチング・ルータ。
  4. 請求項1において、
    該双方向LSP設定TLV作成部が、該上り方向のLSP情報変更要求時に送信するラベル要求メッセージに双方向LSP設定情報を設定することを特徴とするラベル・スイッチング・ルータ。
  5. 請求項1において、
    該双方向LSP設定TLV作成部が、該上り方向のLSP削除要求時に送信するラベル解放メッセージに双方向LSP削除情報を設定することを特徴とするラベル・スイッチング・ルータ。
JP2000348004A 2000-11-15 2000-11-15 ラベル・スイッチング・ルータ Expired - Fee Related JP4548930B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2000348004A JP4548930B2 (ja) 2000-11-15 2000-11-15 ラベル・スイッチング・ルータ
US09/818,352 US6895008B2 (en) 2000-11-15 2001-03-27 Label switching router

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000348004A JP4548930B2 (ja) 2000-11-15 2000-11-15 ラベル・スイッチング・ルータ

Publications (2)

Publication Number Publication Date
JP2002152263A JP2002152263A (ja) 2002-05-24
JP4548930B2 true JP4548930B2 (ja) 2010-09-22

Family

ID=18821653

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000348004A Expired - Fee Related JP4548930B2 (ja) 2000-11-15 2000-11-15 ラベル・スイッチング・ルータ

Country Status (2)

Country Link
US (1) US6895008B2 (ja)
JP (1) JP4548930B2 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7061921B1 (en) * 2001-03-19 2006-06-13 Juniper Networks, Inc. Methods and apparatus for implementing bi-directional signal interfaces using label switch paths
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
US7652983B1 (en) 2001-06-25 2010-01-26 At&T Intellectual Property Ii, L.P. Method for restoration and normalization in a mesh network
TW588524B (en) * 2002-01-23 2004-05-21 Ind Tech Res Inst System and method to apply multi-protocol label switching network in GPRS
US8014380B2 (en) * 2002-07-03 2011-09-06 Alcatel Lucent Method and system for automatically establishing a return label switched path
US20040028064A1 (en) * 2002-08-09 2004-02-12 Alcatel Stitching-extending MPLS tunnels to the customer interface
US7508755B2 (en) * 2003-07-07 2009-03-24 Alcatel-Lucent Usa Inc. Methods and devices for creating an alternate path for a bi-directional LSP
US7596140B2 (en) * 2003-07-07 2009-09-29 Alcatel-Lucent Usa Inc. Methods and devices for creating bi-directional LSPs
TWI240518B (en) * 2003-11-24 2005-09-21 Ind Tech Res Inst System using label switching techniques to support QoS for mobile ad-hoc networks and its label distributing and switching method
US7860115B1 (en) * 2003-12-18 2010-12-28 Cisco Technology, Inc. Withdrawing multiple advertised routes based on a single tag which may be of particular use in border gateway protocol
US20050265234A1 (en) * 2004-05-13 2005-12-01 Marconi Communications, Inc. Diffserv path object for network management
WO2005122493A1 (fr) * 2004-06-07 2005-12-22 Huawei Technologies Co., Ltd. Procede de realisation d'une transmission d'acheminement dans un reseau
US7496105B2 (en) * 2004-11-05 2009-02-24 Cisco Technology, Inc. System and method for retrieving computed paths from a path computation element using encrypted objects
CN100479459C (zh) * 2005-01-27 2009-04-15 华为技术有限公司 多协议标签交换系统中建立返回标签交换路径的方法
US8488616B2 (en) * 2005-04-05 2013-07-16 Cisco Technology, Inc. Building multipoint-to-multipoint label switch paths
US20070091875A1 (en) * 2005-10-22 2007-04-26 Revnx, Inc. Method and System For Device Mobility Using Application Label Switching In A Mobile Communication Network
JP2008193395A (ja) 2007-02-05 2008-08-21 Fujitsu Ltd 双方向パスの設定方法とそれを実現する通信システムとノード装置
US20080225723A1 (en) * 2007-03-16 2008-09-18 Futurewei Technologies, Inc. Optical Impairment Aware Path Computation Architecture in PCE Based Network
FR2919139A1 (fr) * 2007-07-19 2009-01-23 France Telecom Mecanisme de mise a jour des parametres d'un pseudo-lien
JP4957660B2 (ja) * 2008-06-20 2012-06-20 富士通株式会社 ラベルスイッチングネットワークにおける通信装置
CN101860523B (zh) 2009-04-08 2015-04-15 华为技术有限公司 一种更新联合双向标签交换路径绑定关系的方法和装置
CN102447611B (zh) * 2010-09-30 2015-06-10 中兴通讯股份有限公司 一种建立和拆除双向点到多点标签转发路径的方法及系统
US8570871B2 (en) * 2011-03-09 2013-10-29 Futurewei Technologies, Inc. Signaling extension for a label switched path over a composite link
US10021017B2 (en) 2015-03-18 2018-07-10 Futurewei Technologies, Inc. X channel to zone in zone routing
US9998368B2 (en) * 2015-06-11 2018-06-12 Futurewei Technologies, Inc. Zone routing system
CN113660028B (zh) * 2021-08-16 2022-05-20 北京邮电大学 双向lsp处理方法、电子设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001285348A (ja) * 2000-03-29 2001-10-12 Toshiba Corp データ通信システム、データ中継装置、データ通信装置、データ通信方法、および記憶媒体

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0344140A (ja) 1989-07-11 1991-02-26 Nec Corp セルフルーテイングスイツチの制御方式
JPH11150634A (ja) 1997-11-17 1999-06-02 Konica Corp 原稿サイズ検知方法
USRE42204E1 (en) * 1998-05-13 2011-03-08 Sony Corporation Information receiving device and method, information release device, and information communication system
JP3751473B2 (ja) * 1999-05-28 2006-03-01 富士通株式会社 パケット中継装置
JP2001094567A (ja) * 1999-09-20 2001-04-06 Oki Electric Ind Co Ltd 通信装置及びネットワーク
US6680943B1 (en) * 1999-10-01 2004-01-20 Nortel Networks Limited Establishing bi-directional communication sessions across a communications network
EP1126742A1 (de) * 2000-02-15 2001-08-22 Siemens Aktiengesellschaft Verfahren zum Ersatzschalten von Übertragungseinrichtungen in MPLS-Netzen
JP3790655B2 (ja) * 2000-03-06 2006-06-28 富士通株式会社 ラベルスイッチネットワークシステム
US20020156914A1 (en) * 2000-05-31 2002-10-24 Lo Waichi C. Controller for managing bandwidth in a communications network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001285348A (ja) * 2000-03-29 2001-10-12 Toshiba Corp データ通信システム、データ中継装置、データ通信装置、データ通信方法、および記憶媒体

Also Published As

Publication number Publication date
US20020057691A1 (en) 2002-05-16
JP2002152263A (ja) 2002-05-24
US6895008B2 (en) 2005-05-17

Similar Documents

Publication Publication Date Title
JP4548930B2 (ja) ラベル・スイッチング・ルータ
JP4476292B2 (ja) リアルタイムサービスデータ伝送路の選択方法
EP1722523B1 (en) Apparatus and method for reserving session resource in IPv4/IPv6 combination network
US7535829B2 (en) Tunnel reroute
US7184434B2 (en) Label distribution protocol supporting multiple classes of service in a multi protocol label switching (MPLS) network, methods and MPLS network using thereof
EP2005313B1 (en) Facilitating application synchronization with a reservation protocol at a sender without application receiver participation
TW588524B (en) System and method to apply multi-protocol label switching network in GPRS
JP4682068B2 (ja) 品質保証サービス情報通知方法、通信装置及びドメイン間情報伝達装置
JP4109692B2 (ja) ラベルスイッチネットワークにおけるセッション確立方法及びラベルスイッチノード
JP2004146973A (ja) ポリシ設定可能なピアツーピアセッション中継装置
JP2004236332A (ja) 多重化のためのパケット・データ・フローの識別
CN101645849B (zh) 一种在过渡环境中的QoS实现方法和PE路由器
JP4789864B2 (ja) ルータ装置
WO2008154848A1 (fr) Procédé d'acquisition des informations de capacité d'un nœud de réseau entre des domaines, nœud de réseau et système de communication
Semeria RSVP signaling extensions for MPLS traffic engineering
US20090016277A1 (en) Mobile communication system, packet transfer device, and path re-establishing method
JP4199575B2 (ja) ネットワークシステム,同システムにおけるパス設定方法並びに同システムに用いられるネットワーク管理装置及びネットワーク装置
EP1033848A1 (en) Proxy server supporting IP quality of service
WO2009071022A1 (fr) Procédé et dispositif pour établir un tunnel d'ingénierie de flux
Vijayarangam et al. QoS implementation for MPLS based wireless networks
KR100641051B1 (ko) 서비스품질 보장을 위한 레이블 맵핑 메시지가 기록된 매체및 서비스품질 보장을 위한 레이블 맵핑 메시지의 처리방법
JP4634979B2 (ja) Mplsネットワークシステム、mplsルータおよび経路設定方法
JP2003258856A (ja) 中継装置
JP2004289414A (ja) パケット通信システム、装置およびパケット通信方法
Strandberg Nokia Research Center ove. strandberg@ research. nokia. com

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20071025

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20091203

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091208

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100208

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: 20100706

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100706

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: 20130716

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees