JP5967601B2 - Id/ロケータ分離に基づくネットワークのマルチホーミング環境におけるリンク障害検出および正常動作中のリンクへのセッション切り替えの方法 - Google Patents

Id/ロケータ分離に基づくネットワークのマルチホーミング環境におけるリンク障害検出および正常動作中のリンクへのセッション切り替えの方法 Download PDF

Info

Publication number
JP5967601B2
JP5967601B2 JP2015558610A JP2015558610A JP5967601B2 JP 5967601 B2 JP5967601 B2 JP 5967601B2 JP 2015558610 A JP2015558610 A JP 2015558610A JP 2015558610 A JP2015558610 A JP 2015558610A JP 5967601 B2 JP5967601 B2 JP 5967601B2
Authority
JP
Japan
Prior art keywords
host
hgw
link
network
gloc
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
JP2015558610A
Other languages
English (en)
Other versions
JP2016513420A (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.)
National Institute of Information and Communications Technology
Original Assignee
National Institute of Information and Communications Technology
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 National Institute of Information and Communications Technology filed Critical National Institute of Information and Communications Technology
Publication of JP2016513420A publication Critical patent/JP2016513420A/ja
Application granted granted Critical
Publication of JP5967601B2 publication Critical patent/JP5967601B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W24/00Supervisory, monitoring or testing arrangements
    • H04W24/04Arrangements for maintaining operational condition
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W60/00Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/005Multiple registrations, e.g. multihoming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/15Setup of multiple wireless link connections
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/19Connection re-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • H04W88/06Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Description

本発明は、ネットワークにおける障害検出および障害回復の方法に関し、よって、本発明は、情報通信技術の技術分野のものである。
通信サービスを、耐故障性、負荷分散、高帯域幅、および費用効果的接続性で強化するために、ネットワークにおいてマルチホーミング構成が好んで選択されている。ホストマルチホーミングとサイト(またはエッジネットワーク)マルチホーミングの2種類のマルチホーミング構成が可能である。ホストマルチホーミングでは、ホスト、すなわちエンドノードが2つ以上のインターフェースを保有し、各インターフェースはアクセスリンクと接続されている。ホストは、負荷分散および費用効果性を目的として、通信用のリンクのうちのいずれも使用することができる。同様に、サイトマルチホーミングでも、サイトまたはエッジネットワークが、2つ以上の上流側リンクを介して1または複数の上位レベルの中継ネットワークに接続される。マルチホームサイトから/マルチホームサイトへのトラフィックは、復元力、負荷分散、および帯域幅の増加を目的として、任意の上流側リンクを通過することができる。
インターネットにおけるホストマルチホーミングの手法およびサイトマルチホーミングの手法は、どちらも、いくつかの限界を有する。ホストマルチホーミングは耐故障性をサポートすることができない。というのは、ホストは、進行中のセッションによって使用されているリンクがダウンした場合(またはリンクが切断され、もしくはリンクに障害が発生した場合)に、セッションが切断されないよう保護することができないからである。この問題は、リンクと関連付けられたIPアドレスが、アプリケーション層およびトランスポート層におけるセッション識別子(すなわち、ソケット識別子)としてと、ホストの位置を指示し、ホストへ向けてパケットを転送するためのネットワーク層におけるロケータとしての2つの役割において使用されているという理由によるものである(非特許文献1)。ホストが、セッションに現在使用されているリンクにおける故障のために、現在使用されているリンクを別のリンクに変更すると、セッションIDとロケータの両方が同時に無効になり、セッションは切断される。同様に、サイトマルチホーミングも、デフォルトフリーゾーン(default−free zone(DFZ))BGPルータの経路表サイズを増大させることにより、インターネットの拡張にマイナスに寄与している。というのは、サイトマルチホーミングは、(DFZ)BGPルータに、同じサイトのための複数の経路を記憶させるからである(非特許文献2)。ホストマルチホーミングおよびサイトマルチホーミングのこれらの限界を克服するために、近年、ID/ロケータ分離概念に基づくいくつかのソリューションが提案されている(非特許文献3、4および5)。
ID/ロケータ分離に基づくソリューションは、IDとロケータとに別個の番号を使用し、その場合、IDはトポロジに依存しない値であり、ロケータはトポロジに依存する値である。IDは、アプリケーション層およびトランスポート層において、ソケット、セッション、またはエンドホストを識別するのに使用され、ロケータは、ネットワーク層において、ネットワークトポロジにおけるホストの位置を指示し、経路制御システムにおいてパケットを転送するのに使用される。ロケータは、リンクと関連付けられ、ホストがそのリンクを切り換え、またはネットワークにおけるリンクの接続点を変更するときに変化するはずである。
関連文献において、Shim6(非特許文献3)は、マルチホームホストが、IPアドレスのうちの1つをアプリケーション層およびトランスポート層における上位層ID(upper−layer ID(ULID))として使用することを可能にし、このULIDは、たとえネットワーク層で経路制御に使用されるロケータが変化したとしても、不変のままである。通信セッションは、たとえ現在使用されているリンクにおける故障のためにホストがそのリンク(またはロケータ)を切り替えた場合でさえも、維持される。IP経路制御副層の上に挿入されるshim層が、リンクでの故障が発生した場合に、固定ULIDを様々なロケータに動的にマップすることによってロケータ変更を隠す。同様に、ロケータ/ID分離プロトコル(Locator/ID Separation Protocol(LISP))(非特許文献4)もID/ロケータ分離の概念を使用するが、LISPは、マルチホーミングにおける障害検出および障害回復に関して記述していない。LISPは、むしろ、デフォルトフリーゾーン(DFZ)経路表のサイズおよび更新頻度を低減することに着目したものである。Shim6およびLISPは、マルチホーミングおよび経路制御拡張性の問題への対処に着目したものであるが、HIMALIS(非特許文献5)は、エッジネットワークにおいて異なるネットワーク層プロトコルを使用することのできる、異種ネットワークにおけるマルチホーミングおよびモビリティのより優れたサポートのための共通のアーキテクチャフレームワークを提示している。
以前の特許(特許文献2)は、ID/ロケータ分離に基づくネットワークのモビリティ機構を規定するものであったが、本発明は、ネットワークのマルチホーミング環境においてリンク障害を検出し、通信セッションを別の正常動作中のリンクへ切り替える障害検出および回復機構を規定するものである。この機構は、ホストと呼ばれるユーザ機器において単独で実装することもでき、ホストとゲートウェイの両方で実装することもでき、ホスト、ゲートウェイおよびエッジルータにおいて一緒に実装することもできる。すなわち、この機構は、ホスト、ゲートウェイ、およびエッジルータが、リンク層トリガを用いて、ホスト、ゲートウェイ、およびエッジルータに直接接続されたリンク内の障害を検出することを可能にする。ゲートウェイまたはエッジルータは、セッションが受けることになる悪影響が可能な限り少なくなるようなやり方でホストが他の利用可能なリンクを介してパケットを迅速に経路指定することができるように、ゲートウェイおよびエッジルータの周囲環境におけるリンク障害に関する情報を提供することによってホストを支援する。ホスト、ゲートウェイおよびエッジルータに直接接続されていないリンクの障害、またはゲートウェイもしくはネットワーク輻輳の問題によって生じた障害を検出するために、本発明は、2つのタイマ(プローブタイマおよびキープアライブタイマ)を用いた、ホストにおけるパケット送信インスタンスおよびパケット受信インスタンスの連続したモニタリングに基づく機構を規定する。パケットが指定のタイムアウト以内に送信されず、または受信されない場合には、この機構は、プローブプロセスを開始して、障害の位置を指示し、代替の到達可能な経路を探索し、セッションを最適な到達可能な経路へ切り替える。
特開2008−312191号公報は、日本国特許出願第2007−131030号に基づく優先権を主張するものであり、ノード名またはホスト名およびIDを形成する方法、ID/ロケータ分離ネットワークアーキテクチャのプロトコルスタック、ID/ロケータ分離に基づく通信初期設定プロセス、ならびにID/ロケータ分離をサポートする階層ネットワーク構造を記述している。
特開2008−312191号公報 特開2012−248966号公報
J.Saltzer,「On the naming and binding of network destinations」,RFC 1498,Aug.1993 D.Meyer,L.Zhang,and K.Fall,「Report from the IAB workshop on routing and addressing」,RFC 4984,Sep.2007 E.Nordmark and M.Bagnulo,「Shim6: Level 3 multihoming shim protocol for IPv6」,RFC 5533,June 2009 D.Farinacci,V.Fuller,D.Meyer,and D.Lewis,「Locator/ID separation protocol(LISP)」,Internet−Draft,http://www.ietf.org/id/draft−ietf−lisp−23.txt,May 2012 V.P.Kafle and M.Inoue,「HIMALIS: Heterogeneity inclusion and mobility adaptation through locator ID separation in new generation network」,IEICE Trans.Commun.,vol.E93−B,no.3,March 2010
本発明は、通信機器(ホストおよびゲートウェイ)に直接接続された、またはこれらの機器間の経路に存在するリンクの障害を検出するための機構を規定するものである。また本発明は、障害が発生した場合に通信セッションを回復するための機構も規定するものである。
Shim6プロトコルは、利用可能なIPv6アドレスのうちの1つを上位層IDとして使用するためのマルチホーミング・サポート・プロトコルを規定し、この上位層IDは、たとえネットワーク層で使用されるIPアドレスが障害のために変化する場合でさえも不変のままである。しかし、Shim6プロトコルは、リンク障害がどのようにして検出されるかを規定していない。
さらに、Shim6プロトコルは、IPv6ネットワークについてのみ有効であり、IPv4ネットワークについては有効ではない。LISPは、ID/ロケータ分離の概念に基づくものであるが、リンク障害を迅速に検出し、セッションを別のリンクへ切り替えることに関して規定していない。LISPは、むしろ、デフォルトフリーゾーン(DFZ)経路表のサイズおよびBGP経路の更新頻度を低減することに着目したものである。同様に、これまでに特許取得されたHIMALISネットワーク技術も、リンク障害を検出し、セッションを別の正常動作中のリンクへ切り替えることによってセッションを回復するための方法を欠いている。
よって、本発明の1つの目的は、そうした障害を検出し、そうした障害から回復するための方法を提供することである。
上記の問題は、特許請求される発明によって解決される。
本発明の第1の態様は、「ホストのリンク障害の検出および回復」に関するものである。本発明は、ネットワークのための障害検出および障害回復の方法を含む。ネットワークにおいては、ユーザ機器、すなわちホストと、ネットワーク機器、すなわちゲートウェイの両方が、複数のインターフェースまたはリンクを介してネットワークに接続される。ホストは異なるリンクを介して異なるゲートウェイに接続される。第1のホスト、ホストAは、HGW1、すなわちホストAのゲートウェイのうちの1つを介して、ピアホストである第2のホスト、ホストBと通信している。ホストBは、HGW4、すなわちホストBのゲートウェイのうちの1つを介してホストAと通信している。ホストAおよびホストBは、それぞれ、1または複数の他のゲートウェイ、例えば、HGW2やHGW3も有する。HGW2およびHGW3は、ホストAとホストBとの間の通信には未だ使用されていないが、HGW1(もしくはHGW4)に接続されたホストAの(もしくはホストBの)リンクの障害が検出され、または、HGW1(もしくはHGW4)をエッジルータに接続するHGW1の(もしくはHWG4の)上流側リンクの障害が検出され、または障害のあるHGW1もしくはHGW4が検出された場合には、使用されることになる。
各HGWはグローバルネットワークに接続される。すなわち、各HGWは、グローバルネットワークを介して通信する。
ホストAは、ホストAがホストBと通信していた際に経由したホストAのリンクの障害を検出する。従来の技術に基づいてそうしたリンク障害を検出することが可能である。例えば、ホストAが当該リンクを介してホストBへデータを送信しまたはホストBからデータを受信することができない場合には、ホストAは、現在接続されているネットワークへのリンクにリンク障害があると理解し得る。例えば、ホストAが第1のリンクを介してホストAのゲートウェイ、HGW1と接続されている場合に、ホストAがリンク障害を検出し、第1のリンクが故障を有することに気づく。ホストAは、障害のあるリンク、すなわち第1のリンクを介してのみならず、少なくとももう1つのリンクを介してもネットワークに接続されている。ホストAは、複数のリンクと接続され得る。
ホストAは、ホストAの別の正常動作中のリンクを選択する。ホストAの別のゲートウェイ、HGW2は、正常動作中のリンク、すなわち第2のリンクを介してホストAと接続されている。ホストAの正常動作中のリンクは第2のリンクと呼ばれる。
次いで、ホストAは、正常動作中のリンク、すなわち第2のリンクに属するホストAのグローバルロケータ(Global Locator(GLoc))、GLoc2を、ホストAの新しいGLocとして選択する。グローバルロケータ(GLoc)は、ネットワークトポロジにおけるホストの位置を表し、ネットワークは、パケットヘッダに存在する宛先GLocを中継ネットワークの経路制御インフラストラクチャにおけるラベルとして使用することにより、あるエッジネットワークから別のエッジネットワークへパケットを転送する。
ホストAは、ホストAの他のゲートウェイであるHGW2において、ホストAのピアホストであるホストBのIDおよびGLoc4を登録する。HGW2は、第2のリンクと接続されたゲートウェイであり、またはホストAの新しい正常動作中のリンクに属する。ID対GLocマッピングと呼ばれるIDおよびGLocの登録を行うために、ホストAは、ホストBのID対GLoc4マッピングを含む登録メッセージをHGW2へ送信する。HGW2は、ホストBのID対GLoc4マッピングをID表に記憶する。HGW2は、1または複数のメモリを有し、よって、HGW2は、そうした情報を該ID表に記憶することができる。
ホストAは、ホストAのID対GLoc2マッピングを含むロケータ更新メッセージをホストBへ送信する。ホストBはホストBのID表をホストAのID対GLoc2マッピングで更新する。ここで、ホストAのID対GLoc2マッピングは、ホストAのIDおよび現在のGLocであるGLoc2の情報を含む。
ホストBは、ホストAのID対GLoc2マッピングを含むピアホスト登録メッセージを、ホストBのゲートウェイであるHGW4へ送信する。次いで、HGW4は、HGW4のID表を、ホストAの新しいGLocであるGLoc2で更新する。
ホストAは、ホストAのID対GLocマッピングを記憶しているホスト名レジストリ(Host Name Registry(HNR))へ、HNRレコード更新メッセージを送信する。ホストAのID対GLocマッピングレコードにおいて、HNRは、リンク障害に属するGLoc1を、正常動作中のリンクに属するGLoc2で置換する。
本発明の第1の態様の一例は、ユーザ機器、すなわちホストと、ネットワーク機器、すなわちゲートウェイの両方が、複数のインターフェースまたはリンクを介してネットワークに接続されるネットワークのための障害検出および障害回復の方法であって、ホストは異なるリンクを介して異なるゲートウェイに接続され、第1のホストであるホストAは、ホストAのゲートウェイのうちの1つであるHGW1を介して、第2のホストであるホストBと通信しており、ホストBは、ホストBのゲートウェイのうちの1つであるHGW4を介してホストAと通信しており、ホストAおよびホストBは、それぞれ、他のゲートウェイ、HGW2およびHGW3も有し、HGW2およびHGW3は、ホストAとホストBとの間の通信にはまだ使用されていないが、HGW1(もしくはHGW4)に接続されたホストAの(もしくはホストBの)リンクの障害が検出され、または、HGW1(もしくはHGW4)をエッジルータに接続するHGW1の(もしくはHWG4の)上流側リンクの障害が検出され、または障害のあるHGW1もしくはHGW4が検出された場合には、使用されることになり、この障害検出および障害回復の方法は、
ホストAがリンク障害を検出するステップと、
ホストAが、ホストAの別の正常動作中のリンクおよび正常動作中のリンクを介して接続されたゲートウェイ、HGW2を選択するステップと、
ホストAが、正常動作中のリンクに属するグローバルロケータ(GLoc)を、ホストAの新しいGLoc、GLoc2として選択するステップと、
ホストAからピアホスト登録メッセージを送信することによってホストBのIDおよびGLoc、すなわちID対GLoc4マッピングをHGW2において登録し、ホストBのID対GLoc4マッピングがHGW2の表に記憶されるステップと、
ホストAからロケータ更新メッセージを送信することによって、ホストBを、正常動作中のリンクに属するホストAのID対GLoc2マッピングで更新するステップと、
ホストBからピアホスト登録メッセージを送信することによって、ホストBに接続されたHGW4を、ホストAのID対GLoc2マッピングで更新するステップと、
ホストAからHNRレコード更新メッセージを送信することによってHNRレコードを更新し、リンク障害に属するGLoc1を、HNRレコードに記憶されたホストAのID対GLocマッピング内の正常動作中のリンクに属するGLoc2で置換するステップと
を含む。
第1の態様の好ましい実施形態は、「HGWの上流側リンク障害の検出および回復」に関するものである。この実施形態は、ホストAのHGWであるHGW1が上流側リンク障害を検出するステップと、HGW1からホストAへ、GLoc到達不能メッセージを送信するステップと、をさらに含む。すなわち、HGW1は上流側リンク障害を検出する。グローバルネットワークにはエッジルータ(Edge Router(ER))があり、上流側リンクはHGW1をERと接続する。HGW1は、上流側リンク障害を発見すると、ホストAへGLoc到達不能メッセージを送信する。
第1の態様の好ましい実施形態は、
HGW1が上流側リンク障害を検出するステップと、
HGW1からホストAへ、GLoc到達不能メッセージを送信するステップと
をさらに含む。
本発明の第2の態様は、「HGWまたはHGW間の経路の障害の検出および回復」に関するものである。
ホストAおよびホストBは、2つのタイマ、プローブタイマおよびキープアライブタイマを維持することを通じて、ホストAおよびホストBにおけるパケット送信インスタンスおよびパケット受信インスタンスを連続してモニタすることによって、HGW1、HGW4、またはHGW1とHGW4との間の経路における障害を検出する。ホストAがホストBへパケットを送信した後で、プローブタイマは開始され、キープアライブタイマは停止される。ホストAがパケットを受信した後で、キープアライブタイマは開始され、プローブタイマは停止される。キープアライブタイマが指定のキープアライブタイムアウト値に達した場合、パケットが送信され、プローブタイマが指定のプローブタイムアウト値に達した場合、一連のプローブパケットが、各々、前のプローブタイムアウト値の半分の間隔において送信される。ホストAがホストAから送信されたプローブパケットに対するいかなる応答も受信しない場合、ホストAは、以下のステップによる障害検出およびセッション回復を開始する。
ホストAは、ホストBの一方のID対GLocマッピングであるID対GLoc4マッピングを含む第1のピアホスト登録メッセージを、HGW2へ送信する。HGW2は、ホストAの第2のHGWである。GLoc4は、ホストBと通信するためにホストAによって宛先GLocとして現在使用されているホストBのGLocである。
ホストAは、ホストBの他方のID対GLocマッピングであるID対GLoc3マッピングを含む第2のピアホスト登録メッセージを、HGW1へ送信する。HGW1はホストAの第1のHGWである。GLoc3は、ホストBのGLocであるが、ホストAによるホストBとの通信のための宛先GLocとしてまだ使用されていない。
ピアホスト登録応答がHGW2からのみ受信された場合に、ホストAは、HGW1がダウンしていると判定する。
ホストAがHGW1とHGW2の両方からピアホスト登録応答を受信した場合に、ホストAは、HGW4またはHGW1からHGW4へ通じる経路が故障を有すると判定する。
本発明の第2の態様の一例は、
2つのタイマ、プローブタイマおよびキープアライブタイマを使用して、ホストAおよびホストBにおけるパケット送信インスタンスおよびパケット受信インスタンスを連続してモニタするための機能を有することによって、HGW1、HGW4、またはHGW1とHGW4との間の経路における障害を検出するステップを含み、パケット送信後にプローブタイマは開始され、キープアライブタイマは停止され、パケット受信後にキープアライブタイマは開始され、プローブタイマは停止され、キープアライブタイマが指定のキープアライブタイムアウト値に達した場合、一連のキープアライブパケットが、前のキープアライブタイムアウト値の半分の間隔で送信され、プローブタイマが指定のプローブタイムアウト値に達した場合、一連のプローブパケットが、各々、前のプローブタイムアウト値の半分の間隔において送信され、ホストAがホストAから送信されたプローブパケットに対するいかなる応答も受信しない場合、ホストAは、障害検出およびセッション回復を開始して、
ホストBの現在使用されているリンクID対GLocマッピングであるID対GLoc4マッピングを含む第1のピアホスト登録メッセージをHGW2へ送信し、
ホストBの他方のID対GLocマッピングであるID対GLoc3マッピングを含む第2のピアホスト登録メッセージをHGW1へ送信し、
ピアホスト登録応答がHGW2からのみ受信された場合に、ホストAはHGW1がダウンしていると判定し、
ホストAがHGW1とHGW2の両方からピアホスト登録応答を受信した場合に、ホストAは、HGW4、またはHGW1からHGW4へ通じる経路が故障を有すると判定する。
HIMALISネットワークアーキテクチャは、ホストマルチホーミングとエッジ・ネットワーク・マルチホーミングの両方をサポートするための汎用的フレームワークを提供する。本発明は、ホストのリンク、またはエッジネットワークを中継ネットワークへ接続するゲートウェイのリンクにおいて障害が発生した場合の障害検出およびセッション回復の機構を規定するものである。ホストに、またはゲートウェイに接続されたリンクにおける障害は、それぞれのノードによりリンク層トリガを用いて検出され、ゲートウェイ障害またはリモートリンクにおける障害は、2つの制御タイマであるプローブタイマおよびキープアライブタイマに基づき、ホストによって開始されるシグナリング機構によって検出される。また、エッジルータおよびゲートウェイは、ホストが障害を検出し、回復プロセスを迅速に開始するのを支援する。エッジルータおよびゲートウェイは、正常動作中のリンクを介したホストへのパケット宛先変更を行い、よって、パケット損失を低減し、または完全に回避し、ホストは、回復機構を実行して、障害が発生したリンクから正常動作中のリンクへセッションを切り替える。
図1は、HIMALISネットワーク構成要素を示す図である。 図2は、HIMALISネットワークのプロトコルスタックを示す図である。 図3は、パケットフォーマットおよびIDヘッダフォーマットを示す図である。 図4は、ホストマルチホーミングのシナリオを示す図である。 図5は、パケットが各HGWを通過する際にネットワークヘッダにおいてロケータがどのように変化するかを示すパケットフローを示す図である。 図6は、ホストのリンク障害検出および他方のリンクへのセッション切り替えを示す図である。 図7は、HGWの上流側リンク障害検出およびセッション切り替えを示す図である。 図8Aは、PTおよびKTが、PTおよびKTの実行中に減分し続け、PTおよびKTの値がゼロに到達すると停止することを示す、障害検出機構の状態機械図である。 図8Bは、PTおよびKTが、PTおよびKTの実行中に減分し続け、PTおよびKTの値がゼロに到達すると停止することを示す、障害検出機構の状態機械図である。 図9は、複数のHGWを有するエッジ・ネットワーク・マルチホーミングを示す図である。 図10は、複数のHGWを有するエッジネットワークにおけるホストリンク障害からの回復を示す図である。 図11は、HGWの上流側リンク障害からの回復を示す図である。 図12は、エッジルータによりサポートされる障害回復を示す図である。
マルチホーミングのためのアーキテクチャ構成要素
図1に、エッジネットワーク、グローバル中継ネットワーク、および論理制御ネットワークからなる、HIMALISアーキテクチャのネットワーク構成要素を示す。HIMALISはアーキテクチャの一例であり、特許請求される発明は、HIMALISアーキテクチャにだけ使用されるよう限定されるものではない。
グローバル中継ネットワークは、高速コアルータおよびエッジルータを含み、エッジネットワークを相互接続する。グローバル中継ネットワークは、グローバルネットワーク層プロトコルにおけるグローバルロケータ(GLoc)空間を使用して、ネットワークトポロジにおけるホストの位置を表し、パケットヘッダ内に存在する宛先GLocを中継ネットワーク経路制御インフラストラクチャにおけるラベルとして使用することによって、あるエッジネットワークから別のエッジネットワークへパケットを転送する。
エッジネットワークは、以下のエンティティ、すなわち、HIMALISゲートウェイ(HIMALIS gateway(HGW))およびホストからなる。エッジネットワークは、セキュリティ強化のための他の構成要素も含んでいてよい。エッジネットワークは、ローカルネットワーク層プロトコルにおいてローカルロケータ(local locator(LLoc))空間を使用する。LLoc空間は、中継ネットワークのGLoc空間と異なってもよい。例えば、IPv6アドレスは、中継ネットワークにおけるGLocに使用されることができ、IPv4アドレスブロックは、エッジネットワークにおけるLLocに使用されることができる。さらに、2つの異なるエッジネットワークが、異なるローカル・ネットワーク・プロトコルおよびLLoc空間を使用することもできる。異なるネットワークプロトコルを使用するエッジネットワークに位置するホストは、HGWを介して相互に通信することができる。例えば、IPv4ネットワークに位置するホストは、IPv6ネットワークに位置する別のホストと通信することができる。エッジネットワークを中継ネットワーク内のエッジルータに接続するHGWは、パケットヘッダにおいてロケータ変換を行う。ホストは、2つのエッジネットワークに同時に接続され、または単一のインターフェースから2つ以上のLLocおよびGLocを取得する場合に、マルチホーム接続され得る。ホストはモバイル機器とすることもでき、モバイル機器は、アプリケーションセッションを続行しながら、あるエッジネットワークから別のエッジネットワークへ自由に移動し得る。
論理制御ネットワークは、ホスト名とID、ロケータと他のパラメータ(セキュリティキーなど)との間のマッピングを記憶し、提供するための、ドメイン名レジストリ(domain name registry(DNR))およびホスト名レジストリ(host name registry(HNR))を含むホスト名解決システムを含む(V.P.Kafle,R.Li,D.Inoue,and H.Harai,「An integrated security scheme for ID/locator split architecture of future network」,Proc.FutureNet Workshop(held with IEEE ICC’12),June 2012)。DNRは、ドメイン名(例えば、idldomain1.com)とHNRのID(例えば、6e69−6274−6964−6c33−3−0−0−3)とロケータ(例えば、10.10.1.2)との間のマッピングを記憶し、HNRは、ホスト名(例えば、hosta#idldomain1.com)とホストのID (例えば、6e69−6274−6964−6c11−1−0−0−1)とロケータ(例えば、2001:db8:1:200::2)との間のマッピングを記憶する。DNRレコードは、HNRが移動式ではないため、ほとんど不変であり、DNRレコードは、それらのIDおよびロケータを長時間にわたって保持する。他方、HNRレコードは、ホストが、例えば、リンク障害や移動性のためにホストのロケータを変更するときに更新される必要があるため、動的である。DNRは、HNRに関する静的レコードのより高速の、拡張可能な取得のために、DNSに類似した階層構造で編成され、HNRは、ホストに関する動的レコードのより高速な更新を容易にするために単層構造を有する。
DNRおよびHNRは、ホスト名解決に際してその役割を有し、ホスト名解決は、ホストがターゲットホストとの通信を開始するときに行われる。ターゲットホストがマルチホーム接続される場合には、ターゲットホスト名に対応する複数のGLocが、HNRに記憶されたレコードの中から問合せ側ホストによって取得される。リンク障害が発生すると、当該リンクと関連付けられたGLocは到達不能または利用不能になる。この場合、ターゲットホストは、HNRレコード更新要求を送信することによって、HNRレコードから当該GLocを削除させる。よって、HNRレコード更新は、以下の各項で記述されるマルチホーミング障害検出およびセッション切り替え機構の最後に行われ得る。
HIMALISネットワークアーキテクチャのプロトコルスタックは図2に示されている。ホストおよびHGWにおけるスタックは、ネットワーク層の上に新しく導入される識別(ID)層を含む。ホストにおける識別層は以下の機能を実行する。すなわち、ID表から送信元IDおよび宛先IDおよびロケータを取得し、識別ヘッダを構成し、ロケータをネットワーク層へ提供し、マルチホーミングシグナリングを実行する。HGWにおいても同様に、識別層は、パケットを転送するために以下の機能を果たす。ID表から送信元のID対ロケータマッピングと宛先のID対ロケータマッピングの両方を取得し、ロケータをネットワーク層へ提供し、HGWを横切るパケットにおいて新しいネットワークヘッダを作成する。よって、HGWにおけるID層は、ID対ロケータマッピングを提供することによって、ネットワーク層がパケットにおいてネットワークヘッダを変換するのを支援する。中継ネットワークは識別層を持たず、従来のインターネット経路制御インフラストラクチャの場合と同様に、パケットヘッダに存在する宛先ロケータを用いてネットワーク層からパケットを経路制御する。
図3に、アプリケーションデータ、ならびにトランスポートヘッダ、IDヘッダおよびネットワークヘッダを含むパケットフォーマットを示す。(パケットはリンク層ヘッダも含むが、リンク層ヘッダは本発明の障害検出および回復機構の説明で使用されないため、ここでは図示されていない。)これらのヘッダの中で、IDヘッダおよびネットワークヘッダは、マルチホーミングサポートの観点から重要である。IDヘッダは(パラメータの中でも特に)IDを含み、ネットワークヘッダはロケータを含む。IDヘッダは、データ送信元ホストおよび宛先ホストのIDを含み、ネットワークヘッダは、HGWといった中間ノードのロケータを含む。IDヘッダに存在するIDはパケットがネットワークを横切る間に変化しないため、それらのIDは、ネットワークヘッダ内のロケータを変更するための参照値として使用される。この機能は、マルチホーミングでの障害回復の設計において利用される。IDヘッダは任意選択の部分も含み、この任意選択の部分は、リンク障害から回復するためのロケータ更新に関する情報を搬送するのに使用され得る。
ホストマルチホーミング
図4は、ホストが2つの異なるリンクとマルチホーム接続されるホストマルチホーミングのシナリオを示す。この項では、説明を簡略にするために、各エッジネットワークはシングルホームである、すなわち、単一の上流側リンクを有する単一のHGWを介して中継ネットワークに接続されるものと仮定する。ホストは、エッジネットワークと接続する(またはエッジネットワークにアクセスする)ときに、ホストのLLocおよびGLocを割り当てられる。ネットワークアクセス中に、HGWも、HGWのID表に、HGWのエッジネットワークに位置するホストのID、LLoc、およびGLocを記憶する。図では、各ホストが2つのLLocを有し、それらのLLocは2つの異なるネットワーク層プロトコルに属し得る。例えば、ホストAのLLoc1はIPv4アドレス(例えば、10.10.1.2)であり、LLoc2はIPv6アドレス(例えば、2001:db8:1:200::2)であり得る。同様に、各ホストは2つのGLocを有し、それらのGLocは、実際には、中継ネットワークのGLoc空間(IPv4グローバルアドレスまたはIPv6グローバルアドレスであり得る)から各HGWの上流側インターフェースへ割り当てられたロケータである。そのため、それぞれのグローバルとして、ホストAはGLoc1およびGLoc2を有し、ホストBはGLoc3およびGLoc4を有する。
ロケータ。ホストはホストのHNRにすべてのGLocを登録する。これらのGLocのいずれかが、例えばリンク障害が原因で変更される場合には、ホストは、HNRが常に最新のID・ロケータマッピングレコードを記憶し、他の問合せ側ホストに提供することができるように、HNRレコードをGLocの新しい値で更新するために、HNRレコード更新メッセージを送信する必要がある。
図4において、ホストAがホストBと通信しようとする場合、ホストAはホストBのホスト名(例えば、hostb#idldomain2.com)を知らなければならない。ホストAは、その場合、DNRおよびHNRへ名前解決問合せを送信することによって、ホストBのホスト名を解決してホストBのIDおよびGLocにする(DNRおよびHNRは図示されていない)。IDおよびGLoc以外に、ホストAは、公開鍵やホストBの証明書といったセキュリティ関連情報も取得し得る。ホストAは、名前解決によって、ホストBのIDおよび2つのGLoc(GLoc3およびGLoc4)を取得する。ホストAは、本発明では規定されないロケータ選択アルゴリズムを用いて、ホストA自体のGLocとホストBのGLocの適切な対を選択する。図4では、ホストAのGLoc1およびホストBのGLoc4が通信のために選択されているものと仮定している。ホストBへパケットを送信する前に、ホストAは、HGW1のID表においてホストBのID対GLocマッピングを登録する必要があり、HGW1は、この通信セッションのためのホストAのGLocとしてホストAによって選択されたGLoc1のためのデフォルトHGWである。この登録は、ピアホスト、すなわちホストBのIDおよびGLocを含むシグナリングメッセージを、ホストBのための最初のパケットをディスパッチする前に送信することによって明示的に行うこともでき、ホストBのために送信される最初のパケットのID任意選択ヘッダにピアホストのIDおよびGLocを含めることによって暗黙的に行うこともできる。以後、これらの登録選択肢を、それぞれ、明示的ピアホスト登録および暗黙的ピアホスト登録と呼ぶ。ホストBのID対GLocマッピングを登録する間に、ホストAは、ホストBのGLocが優位の順にHGW1のID表においてソートされ得るように、ホストBのGLocの各々に優位値を割り当てる。ここでは、ホストAは、GLoc4へGLoc3よりも高い優位を割り当てる。明示的登録では、HGW1は、ホストBのID対GLocマッピングをID表に加え、ホストAに応答を返す。暗黙的登録では、HGW1は、ホストBのID対GLocマッピングをID表に加え、パケットを中継ネットワークへ転送する前に、ホストBのID対GLocマッピングを使用してパケットのネットワークヘッダを変換する。
図5は、パケットがネットワークの異なるセグメントを流れるときのパケットヘッダ内のIDおよびロケータを示す。ホストBへパケットを送信するために、ホストAは、ネットワーク層ヘッダにおいて、ホストAのLLoc1を送信元ロケータとして、HGW1のLLocを宛先ロケータとして使用し、ホストAのIDおよびホストBのIDを、識別層ヘッダにおける送信元IDおよび宛先IDとして使用する。GLocはエッジネットワークにおいて経路制御可能ではない(または経路制御システムによって認識されない)ため、パケットのネットワーク層ヘッダにおいては、GLocではなくLLocが使用されることに留意されたい。ホストAは、ホストBへ送信される最初のパケット(通信初期設定パケットとして知られる)に、すべてのホストAのGLoc(各々優位値を有する)も含める。パケットが到着すると、HGW1は、パケットヘッダから、送信元IDおよび宛先IDを読み取り、次いで、HGW1のID表を探索して、宛先ID対GLocマッピングを見つける。ID表から取得される最も優先的な宛先ID対ロケータマッピングを使用して、ホストAは、送信元および宛先のLLocをGLocへ変換する。すなわち、ホストAは、GLoc1およびGLoc4を、パケットのネットワーク層ヘッダにおける送信元ロケータおよび宛先ロケータとして使用し、パケットを中継ネットワーク上で転送することになる。パケットは、パケットの宛先ロケータ値、すなわち、GLoc4に基づいて中継ネットワークにおいて経路制御される。パケットがHGW4に到達すると、HGW4は、ID表を探索して、宛先ID対LLocマッピングを見つける。HGW4は、次いで、ネットワークヘッダのGLoc1およびGLoc4を、それぞれ、HGW4自体のLLocおよび(ID表から取得される)ホストBのLLoc4へ変換し、パケットをホストBへ転送する。
ホストBは、ホストAから受信された最初のパケットからの(優位の順にソートされた)ホストAのID対GLocマッピングについて知っている。ホストBは、明示的ピアホスト登録または暗黙的ピアホスト登録によってホストAのID対GLocマッピングをHGW4のID表に登録する。ホストBは、ネットワーク層ヘッダにおいて、ホストBのLLoc1を送信元ロケータとして、HGW4のLLocを宛先ロケータとして使用し、ホストBのIDおよびホストAのIDを、識別層ヘッダにおける送信元IDおよび宛先IDとして使用する。パケットが到着すると、HGW4は、パケットヘッダから、送信元IDおよび宛先IDを読み取り、次いで、HGW4のID表を探索して、宛先ID対GLocマッピングを見つける。ID表から取得される宛先ID対ロケータマッピングを使用して、HGW4は、送信元および宛先のLLocをGLocへ変換する。すなわち、HGW4は、GLoc4およびGLoc1を、パケットのネットワーク層ヘッダにおける送信元ロケータおよび宛先ロケータとして使用し、パケットを中継ネットワーク上で転送することになる。パケットは、パケットの宛先ロケータ値、すなわち、GLoc1に基づいて中継ネットワークにおいて経路制御される。パケットがHGW1に到達すると、HGW1は、ID表を探索して、宛先ID対LLocマッピングを見つける。HGW1は、次いで、GLoc4およびGLoc1を、それぞれ、HGW1自体のLLocおよび(ID表から取得される)ホストAのLLoc1へ変換し、パケットをホストAへ転送する。このようにして、これら2つのホスト間で交換される後続のパケットは、各HGWにおいて、LLocからGLocへの変換、またはその逆を施される。
通信セッションは、通信経路にある各ホストのリンクまたは各HGWのリンクのうちの1つがダウンし、続いて、当該リンクに割り当てられたGLocまたはLLocが到達不能になると、支障を来たす。この場合、マルチホームホストは、セッションが切断されるのを防ぐために、短時間内に、故障したリンクから別の正常動作中のリンクへのリンク間セッション切り替えまたはハンドオーバを実行する必要がある。ダウンするリンクに応じて、ホストは、以下の各項で述べるように、ホスト自体によって、またはHGWおよびエッジルータの助けを借りて、リンク障害の検出後にセッションハンドオーバを実行する。
ホストのリンク障害
ホストのリンクがダウンしている場合、ホストは、ホストのHGWからも、ピアホストからも到達不能になる。例えば、図4において、セッションによって使用されるホストAのリンクがダウンしている場合、LLoc1は、HGW1から到達不能になり、したがって、ホストAは、ホストBからGLoc1に到達不能になる。この場合、セッションに及ぼすリンク障害の影響を低減するために、障害が発生したリンクから他方の正常動作中のリンクへ可能な限り早くセッションを切り替えるように(図6に示す)以下の機能が実行される。(1)リンク障害を検出し、(2)別の正常動作中のリンクを選択し、ピアホストのID対GLocマッピングを新しいHGW(すなわちHGW2)に登録し、(3)ホストBを、ホストAのGLocの新しい優位順で更新し、(4)HGW2を介してデータパケットを取得し、(5)障害が発生したリンクと関連付けられたGLocを削除することによってHNRレコードを更新する。これらの機能を短時間に実行することにより、ホストは、セッションが切断されるのを防ぐことができる。
(1)ホストは、ホストのインターフェースに直接接続されたリンクが機能しているか機能していないかを、リンク層トリガを用いて容易に検出することができる。
(2)リンク障害検出後に、(ホストが多くのリンクを有する場合には)その他の利用可能なリンクの中から、ホストは、まず、(RFC3484[8]または[9]で規定されているアルゴリズムといった、ロケータ選択アルゴリズムを用いて)セッションのための適切なリンクを選択する必要がある。図6では、ホストAには2つのリンクしかないため、ホストAは、他方の利用可能なリンクを選択するはずであり、他方の利用可能なリンクはローカルロケータとしてLLoc2を有し、HGW2に接続されている。LLoc2およびGLoc2を、それぞれ、セッションのためのローカルロケータおよびグローバルロケータとして使用するのを開始するために、ホストAは、明示的ピアホスト登録または暗黙的ピアホスト登録を実行することにより、ホストBのID対GLoc(GLoc3およびGLoc4、GLoc4がより高い優位を有する)マッピングをHGW2へ登録する。HGW2は、ホストBのID対GLocマッピングをHGW2のID表に追加する。
(3)ホストAは、次いで、明示的ロケータ更新シグナリングメッセージを送信することによって、あるいは、ホストAの新しいID対GLocマッピング優位をパケットのID任意選択ヘッダに含めることによって、ホストBを、ホストAのGLocの新しい優位順(すなわち、GLoc2はより高い優位にあり、GLoc1はより低い優位、またはゼロ優位にある)で更新する。以後、明示的シグナリングメッセージを送信することによるロケータ更新を明示的ロケータ更新、暗黙的に、ID対GLocマッピング優位をパケットのID任意選択ヘッダに含めることによるロケータ更新を暗黙的ロケータ更新と呼ぶ。ホストBは、ホストBのID表を、ホストAのID対GLoc2マッピング優位変更で更新する。ホストは、次いで、明示的ピアホスト登録または暗黙的ピアホスト登録を実行することによって、HGW4のID表を更新する。
(4)次いで、HGW4は、新しいマッピングを使用して、ホストAのIDに宛先指定されたパケットをGLoc2へ転送する。パケットはHGW2に到達し、HGW2は、ID表からホストAのID/LLoc2マッピングを探索することにより、ネットワーク層ヘッダにおいてGLocをLLocへ変換することによって、パケットをホストAのLLoc2へ転送する。
(5)ホストAは、HNRレコードからGLoc1を削除するために、ホストAのHNRへHNRレコード更新要求を送信する。この機能は、リンク障害検出およびセッション切り替え機構の最後に常に行われる。しかし、簡潔にするために、以下の各図および各段落のテキストからHNRレコード更新シグナリングを省く。
HGWの上流側リンク障害
HGWの上流側リンク(すなわち、中継ネットワークに接続されたリンク)がダウンしている場合、ホストは、ピアホストからホストのGLocに到達不能になるはずである。しかし、HGWは、依然として、ローカルホストからはHGWのLLocに到達可能のままのはずである。例えば、図4において、ホストAのセッションによって使用されるHGW1の上流側リンクがダウンしている場合、GLoc1は到達不能になり、したがって、ホストAは、ホストBからGLoc1に到達不能になるはずである。しかし、ホストAは、HGW1から、または同じエッジネットワークに位置する他のローカルホストからは、LLoc1において到達することができる。
この場合、HGW1が、ホストAがGLocの到達不能性を検出することを支援しない限り、ホストAはGLocの到達不能性を知るのに長時間を要するかもしれず、それまでにホストAのセッションが切断されてしまう可能性がある。したがって、この問題を回避するために、発明者らは、HGW通知機構を開発した。この機構では、HGW1が、HGW1の上流側リンクがダウンしていることを検出すると、HGW1は、GLoc1を到達不能GLocとして含む「GLoc到達不能通知」メッセージを構成し、図7において矢印(1)で示すように、このメッセージをホストAへ送信する。この通知を受信すると、ホストAは、前述のように機能(2)、機能(3)、および機能(4)を実行することによって、GLoc1からGLoc2へのセッション切り替えを実行する。
HGW障害
HGWが故障すると、HGWのGLocとLLocの両方が到達不能になり、HGWは、GLocの到達不能性に関してローカルホストに知らせるためにローカルホストへいかなる通知も送信することができなくなるはずである。この場合、ホストが障害を検出し、短時間に障害から回復することができない場合には、セッションは切断され得る。したがって、発明者らは、後述するように、HGW障害の検出および回復の機構を開発した。
1)障害検出
HGW障害検出機構は、ホスト・プロトコル・スタックの識別層において2つのタイマ(キープアライブタイマおよびプローブタイマ)を維持することによってパケット受信イベントおよびパケット送信イベントをモニタすることに基づいている。これら2つのタイマは、相互排他的であり、すなわち、一度に一方だけが実行されている。図8に、障害検出の動作の状態機械図を示す。初期状態では、両方のタイマがオフに設定されている。ホストがパケットを送信すると、ホストは(キープアライブタイマが実行中であった場合には)キープアライブタイマを停止し、プローブタイマを開始する。プローブタイマがすでに開始されていた場合には、ホストは、タイマのいかなる変更も行わない。ホストがパケットを受信すると、ホストは、(プローブタイマが実行中であった場合には)プローブタイマを停止し、キープアライブタイマを開始する。キープアライブタイマがすでに開始されていた場合には、ホストは、タイマのいかなる変更も行わない。
キープアライブタイマがキープアライブタイムアウト秒(その値は、通信初期設定段階において折衝される)に達すると、ホストは、ピアホストへキープアライブパケットを送信し、そのキープアライブタイマを低減されたキープアライブタイムアウト値(前のキープアライブタイムアウトの約1/2になるはずである)に再設定する。キープアライブパケットを受信すると、ピアホストは、(送信すべきアプリケーションデータを有する場合には)ペイロードパケットで、または(送信すべきデータがない場合、もしくはID層セッションを終了したい場合には)キープアライブパケットで即座にホストに応答することになっている。ホストが、キープアライブパケットの送信後に、データパケットまたはキープアライブパケットを受信した場合、ホストは、そのキープアライブタイマを通常のキープアライブタイムアウトへ戻し、別のキープアライブパケットを送信するためのタイマ満了まで待機する。どちらのホストもアプリケーションデータを有さず、キープアライブパケットだけを交換している場合、どちらかが、障害検出機構を終了するための特殊な種類のキープアライブ(すなわちキープアライブ終了)パケットを発行し得る。次いで、両方のタイマが両方のホストにおいて停止されることになる。ホストが低減されたキープアライブタイムアウト以内にホストのキープアライブパケットに対する応答を受信しない場合には、ホストは、別のキープアライブパケットを送信し、キープアライブタイマを、前のキープアライブタイムアウトの1/2に再設定する。ホストが再度いかなる応答も受信しない場合には、ホストは、キープアライブパケットの数が「満了キープアライブカウント最大値」に到達するまで、繰り返しキープアライブパケットを送信し、キープアライブタイムアウト値を低減することになる。ホストは、次いで、キープアライブタイマを停止し、後述するように障害回復段階に入る。
プローブタイマがプローブタイムアウト秒(その値は、通信初期設定段階において折衝される)に達すると、ホストは、プローブパケットを送信し、そのプローブタイマを低減されたプローブタイムアウト値(前のプローブタイムアウトの約1/2になるはずである)に再設定する。プローブパケットを受信すると、ピアホストは、プローブ応答パケットで即座にホストに応答することになっている。ホストがプローブ応答パケットを受信した場合、ホストは、通信経路が依然としてアクティブであることを知り、プローブタイマを停止する。ホストは、次いで、アプリケーション・データ・パケットの送信を再開し、プローブタイマを開始する。しかし、ホストがプローブタイムアウト以内にそのプローブパケットについての応答を受信しない場合には、ホストは、別のプローブパケットを送信し、プローブタイマを、前のプローブタイムアウトの1/2に再設定する。ホストが再度いかなる応答も受信しない場合には、ホストは、プローブパケットの数が「満了プローブカウント最大値」に到達するまで、繰り返しプローブパケットを送信し、プローブタイムアウト値を低減することになる。ピアホストから応答が受信されない場合、ホストは、プローブタイマを停止し、後述するように障害回復段階に入る。
障害回復
障害回復機構は、現在使用されている通信経路における故障したHGWの位置を指示するプロセスから開始する。説明を簡潔にするために、障害回復機構は、図7においてホストAによって開始されるものと仮定する。故障がホストAのローカルHGWに起因するものであったかどうか確認するために、ホストは、より高い優位を有するホストBのID対GLoc3マッピング(すなわち、まだセッションに使用されていないホストBの他のGLoc)を含む明示的ピアホスト登録メッセージをHGW1へ、より高い優位を有するホストBのID対GLoc4マッピング(すなわち、セッションに現在使用されているGLoc)を含む別のピア登録メッセージをHGW2へ送信する。ホストごとに利用できるGLocが3つ以上ある場合には、ホストは、ピアホストと通信するのに使用され得る候補GLocの数を制限する方法(ここでは規定しない)を適用し得る。これらのHGWが動作中である場合、各HGWは、ホストBのID対GLocマッピングを各HGWのID表に追加し、ホストAへ応答を送り返すはずである。以下の2つの事例が起こり得る。
事例I:ピアホスト登録応答がHGW2からのみ受信され、HGW1からは受信されない場合、ホストAは、ホストA自体のHGW1がダウンしており、GLoc1は到達不能になっているものと想定する。ホストAは、その場合、より高い優位値を有するID対GLoc2マッピングを含む明示的ロケータ更新メッセージまたは暗黙的ロケータ更新メッセージを、HGW2を介してホストBへ送信する。HGW1からHGW2へのセッション切り替えのための残りの機能は、前の各段落において機能(3)、機能(4)、および機能(5)で規定したように実行される。
事例II:応答がHGW1とHGW2の両方から受信される場合、ホストAは、ホストA自体のHGWは良好であり、ホストBのHGW4およびGLoc4が故障した可能性があるものと想定する。ホストAは、その場合、故障した可能性のあるGLoc4の値を含むプローブパケットを、HGW1およびHGW3を介してホストBへ送信する。このパケットを受信すると、ホストBは、ピアホスト登録を行うことによって、ホストAのID対GLocマッピングをHGW3へアップロードし、次いで、HGW3を介してホストAへ応答を送信する。応答を取得した後に、ホストAは、GLoc3を宛先GLocとして用いて通信を再開する。
このようにして、ローカルHGWおよびリモートHGWにおける故障が特定され、セッションが動作中のHGWを介して再開される。上述の障害検出および回復の方式は、中継ネットワークにおける輻輳または経路障害によって生じた通信セッションの分断を検出するのにも適用可能である。
エッジ・ネットワーク・マルチホーミング
先に各段落で言及したように、エッジマルチホーミングまたはサイトマルチホーミングは、エッジネットワークにおいて複数の上流側リンクを備える単一のHGWを有することによって、または(各々が1もしくは複数の上流側リンクを備える)複数のHGWを有することによって、行うことができる。前者の場合には、障害検出およびセッション回復手順は、前項においてホストマルチホーミングについて規定したように実行される。すなわち、HGWの1つの上流側リンクに障害がある場合に、HGWは「GLoc到達不能通知」をホストへ送信し、ホストは、次いで、他方のGLocを含むロケータ更新メッセージをピアホストへ送信する。したがって、以下の各段落では、後者のマルチホーミングの場合のみ、すなわち、複数のHGWを有するエッジネットワークと関連付けられる障害検出および回復機構について説明する。
複数のHGWを有するエッジ・ネットワーク・マルチホーミング
エッジネットワークが複数のHGWを介して中継ネットワークに接続される場合、ホストは、ホストの単一のインターフェースを介して論理的にマルチホーム接続されることができ、またはホスト自体の2つ以上のインターフェースを介して物理的にマルチホーム接続されることができる。論理的マルチホームホストは、ダイナミックホスト設定プロトコル(Dynamic Host Configuration Protocol(DHCP))といった、ロケータ構成プロトコルによって同じインターフェースに割り当てられた(各々異なるHGWと関連付けられた)複数のLLocおよびGLocを取得することができる。同様に、物理的マルチホームホストも、ロケータ構成プロトコルを用いて複数のLLoc(インターフェースごとに少なくとも1つ)およびGLoc(各HGWから少なくとも1つ)を取得することができる。論理的マルチホームホストの場合には、エッジネットワークの複数のHGWが相互に協働してリンク障害からセッションを回復するが、ホストのリンクがダウンしているときにすべてのLLocおよびGLocが到達不能になる。これと対照的に、物理的マルチホームホストの場合には、障害が発生したリンクと関連付けられたLLocだけが到達不能になり、その他のリンクと関連付けられたホストのGLocおよびLLocは、到達可能、または動作中のままになるはずである。したがって、エッジ・ネットワーク・マルチホーミングの一般事例として、ここでは、以下に、物理的マルチホームホストのみについての障害検出およびセッション回復機構を説明する。
図9は、各ホストが複数のリンクを介して接続され、エッジネットワークも複数のHGWを介して中継ネットワークに接続される、エッジ・ネットワーク・マルチホーミングのシナリオを示す。エッジネットワークの複数のHGWは、相互に、また各ホストと協働して、障害を検出し、障害から回復する。このシナリオにおいて発明者らは、以下のリンク障害事例を考察する。(i)ホストのリンクの障害、(ii)HGWの上流側リンクの障害、(iii)HGWの下流側リンクの障害、および(iv)HGW自体の障害。前項のホストマルチホーミングの説明において、HGWの下流側リンク障害について明示的に考察しなかったのだが、その理由は、この事例がHGW障害と同等であるからである。以下の説明では、図9において、ホストAは左側のリンクおよびHGW1を使用して、HGW4を介してホストBと通信しているものとする。通信のパケットフロー経路は、図10の上部で示されている。
(i)ホストのリンクの障害:前述のように、ホストはホストのリンク層トリガを使用してホストのリンクの障害を検出する。図9では、ホストAの左側のリンクがダウンしており、LLoc1は到達不能になるものと仮定する。切断されたHGWから送信されるパケットの損失を低減するために、ホストは、ホストの左側のリンクがダウンしていることを検出し次第、(図10に示すように)ホストの右側のリンクおよびLLoc2を使用して、ホストのアクティブなID/LLoc2マッピングを含むLLoc更新メッセージを、HGW2を介してHGW1へ送信する。この要求を受信すると、HGW1は、着信するパケットをLLoc2へ転送することができるように、HGW1のID表を、ホストAのローカルロケータとしてのLLoc2で更新する。ホストからの発信パケット(図には示されていない)は、同じ経路を逆方向にたどってHGW1に到達し、そこで、これらのパケットはロケータ変換を施され、中継ネットワークへ転送される。一方、ホストは、そのセッションについてホストのGLocをGLoc1からGLoc2へ変更し、HGW2において(明示的な、または暗黙的な)ピアホスト登録を実行し、ホストBにおいてロケータ更新を実行する。その後、ホストBからの着信パケットは、HGW2に直接(すなわち、HGW1を介さずに)到着することになり、HGW2は、宛先ロケータフィールドにLLoc2を挿入することによってネットワークヘッダを変換し、これらのパケットをホストAへ転送することになる。
代替の手法では、HGW1がLLoc更新メッセージを受信すると、HGW1は、ID対GLoc4マッピングをHGW2へ転送し得る。HGW1は、LLoc更新メッセージに対する返答を送信することによって、ホストBへこの切り替えについて知らせることができる。この情報を受信すると、ホストは、HGW2におけるピアホスト登録を行わなくなり、ロケータ更新をホストBへ直接送信することができる。
(ii)HGWの上流側リンクの障害:この場合には、障害が発生したHGW、すなわちHGW1が、(図11に示すように)GLoc到達不能通知を送信することによって、ローカルホストに、他方のHGWを使用するよう知らせる。HGW1は、2つのHGW間のリンクが動作している場合には、HGW1のID表に記憶されたすべてのID/GLocマッピングを他方のHGWに切り替えることができる。HGW1は、ホストがHGW2においてピアホスト登録を実行しなくて済むようにフラグを設定することによって、ホストへ送信されるGLoc到達不能メッセージにおいてその切り替えに関して指示する(そうでなければ、ホストAは、明示的ピアホスト登録または暗黙的ピアホスト登録を実行することによって、ホストBのID対GLocマッピングをHGW2にアップロードする必要がある)。ホストは、ピアホストへ、より高い優位値を有するGLoc2を含むロケータ更新メッセージを迅速に送信することができる。ピアホストは、HGW4が発信パケットの宛先ロケータフィールドにおいてGLoc2を使用することになるように、ピアホストのHGW4へのピアホスト登録を実行して、ID表をGLoc2で更新する。パケットは、HGW2に到着し、次いで、ネットワーク層ヘッダにおいてGLocからLLocへの変換をした後にホストAへ転送される。ホストAからの発信パケットは、同じ経路を逆方向にたどる。このようにして、セッションは、上流側リンク障害の場合には、HGW1からHGW2へうまく切り替えられる。
(iii)HGWの下流側リンクの障害:このリンク障害のシナリオは、先に考察したホストリンク障害のシナリオに幾分か類似したものである。ここでの違いは、HGWがまず障害に気づき、ホストはしばらくの間障害に気づかない場合があることだけである。ホストは、ホストのパケットを、障害が発生したリンクのところで終わる経路を介して送信し得る。そのため、パケット損失を低減するために、HGWは、ホストに、可能な限り早く障害について知らせる必要がある。このために、HGWは、ローカルホストのすべてのLLocを記憶する。というのは、あるLLocについてはHGWはデフォルトのHGWであり、あるLLocについては、HGWはデフォルトのHGWではないはずだからである。HGWは、宛先ロケータにおいて、HGWがそのデフォルトHGWではないホストの他方のLLocを使用して、HGWのLLoc到達不能性に関して指示するロケータ到達不能メッセージを送信し、他方のHGWを介してそのメッセージ転送する。このメッセージは、エッジネットワークの経路制御システムによってホストまで経路制御される。ホストは、ホストのID表を更新し、HGW1へパケットを転送するための送信元ロケータとしての故障したLLoc、すなわちLLoc1の使用を停止する。ホストは、その代わりに、送信元ロケータにおいてLLoc2を使用し、データパケットを発信するための宛先ロケータとしてHGW1のLLocを使用する。着信パケットは、同じ経路を逆方向にたどることになる。このようにして、セッションは、セッションに使用される送信元GLocと宛先GLocの対を変更せずに続行し、ピアホストは、障害と無関係のままとされる。
代替として、ホストは、HGW1とHGW2を接続するリンクを介したパケット転送を回避することによって通信経路をより短くするために、HGW2へのピアホスト登録およびピアホストでのロケータ更新を実行して、セッションをHGW1からHGW2へ完全に切り替えてもよい。しかし、これは、HGW2にかかるID/ロケータマッピングの負担を重くする可能性があり、他方、HGW1は完全にアイドル状態になる。そのため、負荷を分担するために、通信経路はわずかに長くなるが、HGW1を使用し続けた方がよい場合もある。この場合には、HGW2は単に、ID/ロケータマッピングおよびネットワークヘッダ変換のためのID層処理を全く行わないルータとして動作するにすぎないことになる。
(iv)HGWの障害:HGWに障害が発生すると、HGWの下流側リンクと上流側リンクの両方が到達不能になる。したがって、HGWと関連付けられたホストのGLocは到達不能になり、このGLocへ送信されるエッジネットワークの外部からのパケットはホストに到達することができない。障害は、前項で規定したパケット受信イベントおよびパケット送信イベントモニタリング法を使用して、ホストによって検出されることができ、または、マルチホーム・エッジ・ネットワークの近隣のHGWによって検出されることができる。近隣のHGWは、2つのHGWを接続するリンクを介した双方向転送検出(Bidirectional Forwarding Detection)[13]といったプロトコルを用いることによって、ホストより早く障害を検出することができる。障害を検出すると、近隣のHGWは、ホストがセッション切り替え手順を迅速に実行することができるように、他方のHGWの障害およびホストへのGLoc到達不能性についてホストに知らせる。ホストは、他方の動作中のHGWにおいてピアホスト登録を、ピアホストにおいてロケータ更新を実行し、動作中のHGWを介して通信を再開する。
エッジルータによりサポートされるエッジ・ネットワーク・マルチホーミング
エッジルータは、エッジネットワークを支援して、エッジルータとHGWとの間のリンクの障害を迅速に検出させ、下流側パケットがエッジルータから棄却されるのを回避させることができる。このために、エッジルータは、障害が発生した場合に、エッジルータが下流側パケットを、残りの動作中のGLocのうちの1つへ(カプセル化によって)宛先変更することができるように、マルチホーム・エッジ・ネットワークの(異なるHGWに属する)すべてのGLocを記憶する。エッジルータは、HGWによってこれらのGLocを提供される。すなわち、HGWがエッジルータに接続し、エッジルータによって提供されるグローバル・ロケータ・プレフィックスからGLocを取得するときに、HGWもエッジルータに、HGWに到達するのに使用され得るHGWの代替のGLocに関する情報を提供する。例えば、図9では、HGW1は、GLoc1に加えてGLoc2においてもHGW1に到達できることがER1に分かるように、HGW1の代替のGLocとして、ER1にGLoc2を提供する。
図12は、ER1が、ER1とHGW1との間のリンクがダウンしていることを検出した場合に、下流側パケットを宛先変更するための手順を示す。ER1は、GLoc1へ向けられた下流側パケットを、GRE[14]といったプロトコルを使用してカプセル化し、GLoc1およびGLoc2を、カプセル化ネットワークヘッダにおいて、それぞれ、送信元ロケータフィールドおよび宛先ロケータフィールドに含めることによって、GLoc1へ向けられた下流側パケットのER2を介したHGW2への転送を開始する。これらのパケットを受信すると、HGW2は、これらのパケットのカプセル化を解除し、HGW2のID表に記憶されたID/LLocマッピングを用いてパケットヘッダにおいてGLocをLLocへ変換する。HGW2は、次いで、パケットをLLoc2においてホストAへ転送する。このパケットの受信後に、ホストAは、ホストBのID/GLoc4マッピングをHGW2のID表に記憶するために、HGW2においてピアホスト登録を実行する。ホストAは、次いで、ホストAのGLocをGLoc1からGLoc2に更新するために、ホストBにおいてロケータ更新を実行する。次いでホストBは、ホストAのIDへ向けられたデータパケットがGLoc2へ転送されることになるように、ホストAのID/GLoc2マッピングでID表を更新するために、HGW4へのピアホスト登録を実行する。
このようにして、セッションは、GLoc1からGLoc2へスムーズに切り替えられる。
本発明は、ユーザ機器が、様々なネットワーク(例えば、有線LAN、WiFi、セルラー、WiMAX(商標))に接続される2つ以上のネットワークインターフェースを有し得るモバイルネットワークおよび異種ネットワークに適用可能である。ユーザは、その通信に、IPv4やIPv6といった異なるネットワーク層プロトコルを使用し得る任意のネットワークを使用することができる。よってユーザは、最適なネットワークを選択するための選択肢を持つことができる。通信中に、(例えば、無線接続またはモビリティにおける混乱が原因で)現在通信に使用されているリンクに問題が生じた場合、機器は、リンク障害を迅速に検出し、通信セッションを別の正常動作中のリンクへ切り替える。このようにして、ユーザは、リンク障害にもかかわらず常に最適な通信サービスを受けることができる。例えば、スマート・モバイル・フォンまたはラップトップコンピュータを持つユーザは、たとえユーザが現在通信に使用されているリンクにおいて問題を有する場合でさえも、ネットワークに接続されたままでいられる。ユーザは、無線LAN(WiFi)ネットワークからWiMAXネットワークまたはセルラーネットワークへスムーズに移動することができる。

Claims (3)

  1. ユーザ機器であるホストと、ネットワーク機器であるゲートウェイの両方が、複数のインターフェースまたはリンクを介してネットワークに接続される前記ネットワークのための障害検出および障害回復の方法であって、
    前記ホストは異なるリンクを介して異なるゲートウェイに接続され、第1のホストであるホストAは、ホストAのゲートウェイのうちの1つであるHGW1を介して、第2のホストであるホストBと通信しており、ホストBは、ホストBのゲートウェイのうちの1つであるHGW4を介してホストAと通信しており、ホストAおよびホストBは、他のゲートウェイであるHGW2およびHGW3をそれぞれ有し、HGW2およびHGW3は、ホストAとホストBとの間の前記通信には未だ使用されていないが、HGW1(もしくはHGW4)に接続されたホストAの(もしくはホストBの)リンクの障害が検出され、または、HGW1(もしくはHGW4)をエッジルータに接続するHGW1の(もしくはHWG4の)上流側リンクの障害が検出され、または障害のあるHGW1もしくはHGW4が検出された場合には、使用されることになり、前記ネットワークのための障害検出および障害回復の方法は、
    ホストAがリンク障害を検出するステップと、
    ホストAが、ホストAの別の正常動作中のリンクおよび前記正常動作中のリンクを介して接続されたゲートウェイであるHGW2を選択するステップと、
    ホストAが、前記正常動作中のリンクに属するグローバルロケータ(Global Locator(GLoc))を、ホストAの新しいGLocであるGLoc2として選択するステップと、
    ホストAからピアホスト登録メッセージを送信することによって、ホストBのIDおよびGLocであるID対GLoc4マッピングをHGW2において登録し、ホストBの前記ID対GLoc4マッピングがHGW2の表に記憶されるステップと、
    ホストAからロケータ更新メッセージを送信することによって、ホストBを、前記正常動作中のリンクに属するホストAのID対GLoc2マッピングで更新するステップと、
    ホストBからピアホスト登録メッセージを送信することによって、ホストBに接続されたHGW4を、ホストAのID対GLoc2マッピングで更新するステップと、
    ホストAからHNRレコード更新メッセージを送信することによって前記HNRレコードを更新し、前記リンク障害に属するGLoc1を、HNRレコードに記憶されたホストAのID対GLocマッピング内の前記正常動作中のリンクに属するGLoc2で置換するステップとを含む、
    ネットワークのための障害検出および障害回復の方法。
  2. HGW1が上流側リンク障害を検出するステップと、
    HGW1からホストAへ、GLoc到達不能メッセージを送信するステップとをさらに含む、
    請求項1に記載のネットワークのための障害検出および障害回復の方法。
  3. プローブタイマおよびキープアライブタイマの2つのタイマを使用してホストAおよびホストBにおけるパケット送信インスタンスおよびパケット受信インスタンスを連続してモニタするための機能を有することによって、HGW1、HGW4、またはHGW1とHGW4との間の経路における障害を検出するステップをさらに含み、
    パケット送信後に前記プローブタイマは開始され、前記キープアライブタイマは停止され、パケット受信後にキープアライブタイマは開始され、プローブタイマは停止され、前記キープアライブタイマが指定のキープアライブタイムアウト値に達した場合、一連のキープアライブパケットが、前記先のキープアライブタイムアウト値の半分の間隔で送信され、前記プローブタイマが指定のプローブタイムアウト値に達した場合、一連のプローブパケットが、各々、前記先のプローブタイムアウト値の半分の間隔において送信され、ホストAがホストAから送信された前記プローブパケットに対するいかなる応答も受信しない場合、ホストAは、障害検出およびセッション回復を開始し、
    ホストBの現在使用されているID対GLocマッピングであるID対GLoc4マッピングを含む第1のピアホスト登録メッセージをHGW2へ送信し、
    ホストBの他方のID対GLocマッピングであるID対GLoc3マッピングを含む第2のピアホスト登録メッセージをHGW1へ送信し、
    ピアホスト登録応答がHGW2からのみ受信された場合に、ホストAはHGW1がダウンしていると判定し、
    ホストAがHGW1とHGW2の両方からピアホスト登録応答を受信した場合に、ホストAは、HGW4、またはHGW1からHGW4へ通じる前記経路が故障を有すると判定する、
    請求項1に記載のネットワークのための障害検出および障害回復の方法。
JP2015558610A 2013-02-27 2013-02-27 Id/ロケータ分離に基づくネットワークのマルチホーミング環境におけるリンク障害検出および正常動作中のリンクへのセッション切り替えの方法 Expired - Fee Related JP5967601B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/001155 WO2014132286A1 (en) 2013-02-27 2013-02-27 Method for link failure detection and session transfer to a lively link in the multihoming environment of id/locator split-based networks

Publications (2)

Publication Number Publication Date
JP2016513420A JP2016513420A (ja) 2016-05-12
JP5967601B2 true JP5967601B2 (ja) 2016-08-10

Family

ID=51427596

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015558610A Expired - Fee Related JP5967601B2 (ja) 2013-02-27 2013-02-27 Id/ロケータ分離に基づくネットワークのマルチホーミング環境におけるリンク障害検出および正常動作中のリンクへのセッション切り替えの方法

Country Status (3)

Country Link
US (1) US9628377B2 (ja)
JP (1) JP5967601B2 (ja)
WO (1) WO2014132286A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9515938B2 (en) * 2013-10-24 2016-12-06 Microsoft Technology Licensing, Llc Service policies for communication sessions
US20160315858A1 (en) * 2015-04-24 2016-10-27 Cisco Technology, Inc. Load balancing of ipv6 traffic in an ipv4 environment
TWI552617B (zh) * 2015-06-30 2016-10-01 弘光科技大學 無線網路之頻寬管理系統及其方法
KR101711908B1 (ko) * 2015-10-06 2017-03-14 한국철도기술연구원 무선 통신망에서의 고신뢰성 및 고품질을 위한 장치 간 통신 연결성 모니터링 및 재설정 방법
US10827001B2 (en) 2016-07-27 2020-11-03 International Business Machines Corporation Managing connections for data communications
US10321510B2 (en) * 2017-06-02 2019-06-11 Apple Inc. Keep alive interval fallback
US10805259B2 (en) * 2017-06-30 2020-10-13 Microsoft Technology Licensing, Llc Geolocation using reverse domain name server information
US10742747B2 (en) 2017-07-06 2020-08-11 International Business Machines Corporation Managing connections for data communications following socket failure
JP6985606B2 (ja) * 2018-02-28 2021-12-22 日本電信電話株式会社 障害検知装置、障害検知方法、および障害検知プログラム
US11082329B2 (en) * 2018-05-31 2021-08-03 At&T Intellectual Property I, L.P. Lossless data delivery at route changes in wireless radio networks
JP7047660B2 (ja) * 2018-08-08 2022-04-05 日本電信電話株式会社 通知装置および通知方法
WO2020067791A1 (en) * 2018-09-27 2020-04-02 Samsung Electronics Co., Ltd. Method for processing node failure in integrated access and backhaul system and method for transmitting redirection information therein
KR20200035813A (ko) * 2018-09-27 2020-04-06 삼성전자주식회사 백홀 액세스 통합 시스템에서 노드 실패 처리 방법 및 redirection 정보 전송 방법
CN114079584A (zh) * 2020-08-18 2022-02-22 华为技术有限公司 用户端保活的方法及装置
CN113395319B (zh) * 2021-04-26 2022-09-16 国网江西省电力有限公司经济技术研究院 网络故障感知的方法、系统、电子设备及存储介质
US11811638B2 (en) * 2021-07-15 2023-11-07 Juniper Networks, Inc. Adaptable software defined wide area network application-specific probing

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8843657B2 (en) * 2006-04-21 2014-09-23 Cisco Technology, Inc. Using multiple tunnels by in-site nodes for securely accessing a wide area network from within a multihomed site
JP5327832B2 (ja) 2007-05-16 2013-10-30 独立行政法人情報通信研究機構 ノード識別子と位置指示子とを用いたパケットの通信方法
EP2208334B1 (en) * 2007-10-26 2012-12-05 Telefonaktiebolaget LM Ericsson (publ) Multihome support method and apparatus
CN102138362A (zh) * 2008-08-29 2011-07-27 交互数字专利控股公司 使用多无线电的装置的ip移动性
CN101951589B (zh) * 2009-10-17 2015-07-22 中兴通讯股份有限公司 信息获取/通知、数据报文转发和切换的方法及接入节点
JP5761709B2 (ja) 2011-05-25 2015-08-12 国立研究開発法人情報通信研究機構 移動端末間の無線通信方法

Also Published As

Publication number Publication date
WO2014132286A1 (en) 2014-09-04
US20160014020A1 (en) 2016-01-14
JP2016513420A (ja) 2016-05-12
US9628377B2 (en) 2017-04-18

Similar Documents

Publication Publication Date Title
JP5967601B2 (ja) Id/ロケータ分離に基づくネットワークのマルチホーミング環境におけるリンク障害検出および正常動作中のリンクへのセッション切り替えの方法
US7804806B2 (en) Techniques for peer wireless switch discovery within a mobility domain
US7916682B2 (en) Wireless switch network architecture implementing layer 3 mobility domains
US7613150B2 (en) Hitless restart mechanism for non-stop data-forwarding in the event of L3-mobility control-plane failure in a wireless switch
US7885233B2 (en) Forwarding broadcast/multicast data when wireless clients layer 3 roam across IP subnets in a WLAN
US7639648B2 (en) Techniques for home wireless switch redundancy and stateful switchover in a network of wireless switches supporting layer 3 mobility within a mobility domain
EP3878214B1 (en) Local identifier locator network protocol (ilnp) breakout
US20080002607A1 (en) Technique for handling layer 2 roaming in a network of wireless switches supporting layer 3 mobility within a mobility domain
US20110004913A1 (en) Architecture for seamless enforcement of security policies when roaming across ip subnets in ieee 802.11 wireless networks
US7961690B2 (en) Wireless switch network architecture implementing mobility areas within a mobility domain
US20080020758A1 (en) Query-response techniques for reduction of wireless client database size to provide scalability in large wireless switch networks supporting layer 3 mobility
WO2007033238A2 (en) System and method for providing packet connectivity between heterogeneous networks, and component and packet therefor
US7826869B2 (en) Mobility relay techniques for reducing layer 3 mobility control traffic and peering sessions to provide scalability in large wireless switch networks
US20080008128A1 (en) Techniques for resolving wireless client device layer 3 mobility state conflicts between wireless switches within a mobility domain
Dreibholz et al. A new scheme for IP-based Internet-mobility
JP5655018B2 (ja) ハンドオーバ処理システム、及びゲートウェイルータ
EP2482585B1 (en) Method and system for realizing terminal handover
WO2008011533A2 (en) Techniques for use in networks of wireless switches
WO2008005794A2 (en) Techniques for peer wireless switch discovery within a mobility domain
Kafle et al. Path failure detection and session recovery mechanism in multihomed HIMALIS network
EP2668795B1 (en) Hip proxy and method for mobility management in a wireless communications system
WO2008005878A2 (en) Wireless switch network architecture implementing mobility areas within a mobility domain, mobility relay techniques for reducing layer 3 mobility control traffic and peering sessions
Kiani et al. A Novel Mechanism to Support Session Survivability in Heterogeneous MIPv6 Survivability in Heterogeneous MIPv6

Legal Events

Date Code Title Description
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: 20160607

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160627

R150 Certificate of patent or registration of utility model

Ref document number: 5967601

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees