特許7581499 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ 華為技術有限公司の特許一覧

特許7581499サービスパス検出を実施する方法、デバイス、及びシステム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3a
3b
3c
3d
4a
4b
4c
4d
5a
5b
6a
6b
6c
6d
7
8
9
10
11

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-01

(45)【発行日】2024-11-12

(54)【発明の名称】サービスパス検出を実施する方法、デバイス、及びシステム

(51)【国際特許分類】

H04L 45/247 20220101AFI20241105BHJP

H04L 45/64 20220101ALI20241105BHJP

【ＦＩ】

H04L45/247

H04L45/64

【請求項の数】 13

(21)【出願番号】P 2023518238

(86)(22)【出願日】2021-09-14

(65)【公表番号】

(43)【公表日】2023-10-03

(86)【国際出願番号】 CN2021118135

(87)【国際公開番号】W WO2022057779

(87)【国際公開日】2022-03-24

【審査請求日】2023-04-21

(31)【優先権主張番号】202010992436.9

(32)【優先日】2020-09-21

(33)【優先権主張国・地域又は機関】CN

(31)【優先権主張番号】202011375770.6

(32)【優先日】2020-11-30

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩＴＥＣＨＮＯＬＯＧＩＥＳＣＯ．，ＬＴＤ．

【住所又は居所原語表記】ＨｕａｗｅｉＡｄｍｉｎｉｓｔｒａｔｉｏｎＢｕｉｌｄｉｎｇ，Ｂａｎｔｉａｎ，ＬｏｎｇｇａｎｇＤｉｓｔｒｉｃｔ，Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ５１８１２９，Ｐ．Ｒ．Ｃｈｉｎａ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎修

(72)【発明者】

【氏名】リー，ズゥチーン

(72)【発明者】

【氏名】ファン，ピーンウエイ

(72)【発明者】

【氏名】ホゥ，シン

(72)【発明者】

【氏名】ヤーン，ピンガン

【審査官】速水雄太

(56)【参考文献】

【文献】米国特許出願公開第２０１５／０２６３９４０（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１１／０２２２４１２（ＵＳ，Ａ１）

【文献】特表２０１６－５２２６４６（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ１２／００－１２／６６

４１／００－１０１／６９５

(57)【特許請求の範囲】

【請求項1】

第１のネットワークデバイスと第２のネットワークデバイスとアクセス側ネットワークデバイスを含むネットワークシステムにおいて、サービスパス検出を実施する方法であって、当該方法は、セグメントルーティング・オーバー・インターネットプロトコルバージョン６（ＳＲｖ６）ネットワークに適用され、前記第２のネットワークデバイスはトンネルを通じて前記第１のネットワークデバイスに接続され、前記アクセス側ネットワークデバイスは前記第２のネットワークデバイスに接続され、
前記第１のネットワークデバイスにより、インターネットプロトコルバージョン６（ＩＰｖ６）に基づいて第１のパケットを生成するステップであり、前記第１のパケットは、第１の指示とサービスの識別情報を含み、前記第１の指示は、前記第１のパケットが検出パケットであることを示す、ステップと、
前記第１のネットワークデバイスにより、前記第１のパケットを前記第２のネットワークデバイスに送信して、前記第１のパケットを受信する前記第２のネットワークデバイスに、前記第１の指示と前記サービスの前記識別情報とに基づいて、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間にあり、かつ前記サービスを運ぶために使用されるパスと、前記第２のネットワークデバイスと前記アクセス側ネットワークデバイスとの間にあり、かつ前記サービスを運ぶために使用されるパスとのうちの少なくとも１つのパス障害又はパス品質を検出するように指示するステップと、
を含み、
前記第１のパケットは第１のＩＰｖ６拡張ヘッダを含み、前記第１の指示は、前記第１のパケットの前記第１のＩＰｖ６拡張ヘッダで運ばれ、前記第１のパケットの前記第１のＩＰｖ６拡張ヘッダは、アラートラベルと制御ワードをさらに含み、前記アラートラベルと前記制御ワードは、前記第１のパケットのペイロード内の検出情報を示し、前記検出情報は、前記第２のネットワークデバイスに、前記検出情報に基づいて、前記サービスを運ぶための前記パスを検出するように指示する、方法。

【請求項2】

前記第１の指示は、前記第１のＩＰｖ６拡張ヘッダの第１のセグメントルーティングヘッダ（ＳＲＨ）内のネクストヘッダフィールドで運ばれる、
請求項１に記載の方法。

【請求項3】

前記第１の指示は、前記第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内の第１のＤＡフィールド内のａｒｇｓフィールドで運ばれる、請求項１に記載の方法。

【請求項4】

前記第１の指示は、前記第１のＩＰｖ６拡張ヘッダのＳＲＨ内のフラグ（ｆｌａｇｓ）フィールドで運ばれる、請求項１に記載の方法。

【請求項5】

前記第１の指示は、前記第１のＩＰｖ６拡張ヘッダのホップバイホップ（ＨＢＨ）オプションヘッダ内のタイプ・レングス・値（ＴＬＶ）フィールドで運ばれ、あるいは前記第１のＩＰｖ６拡張ヘッダの宛先オプションヘッダ（ＤＯＨ）内のＴＬＶフィールドで運ばれる、請求項１に記載の方法。

【請求項6】

当該方法は、
前記第１のネットワークデバイスが、予め設定された期間内に前記第１のパケットに対する前記第２のネットワークデバイスの応答パケットを受信しない場合、前記第１のネットワークデバイスにより、前記第１のネットワークデバイスと前記アクセス側ネットワークデバイスとの間にあり、かつ前記サービスを運ぶために使用されるパスは障害があると判断するステップをさらに含む、請求項１乃至５のうちいずれか１項に記載の方法。

【請求項7】

当該方法は、
前記第１のネットワークデバイスにより、前記第１のパケットに対する前記第２のネットワークデバイスの応答パケットを受信するステップと、
前記第１のネットワークデバイスにより、前記応答パケットに基づいて、前記第２のネットワークデバイスと前記アクセス側ネットワークデバイスとの間にあり、かつ前記サービスを運ぶために使用される前記パスのパス状態を判断するステップと、
をさらに含む、請求項６に記載の方法。

【請求項8】

当該方法は、
前記第１のネットワークデバイスが、前記第１のネットワークデバイスが前記予め設定された期間内に前記第１のパケットに対する前記第２のネットワークデバイスの前記応答パケットを受信しないことに基づいて、前記サービスを運ぶために使用される前記パスは障害があると判断し、あるいは前記パス状態に基づいて、前記サービスを運ぶために使用される前記パスは障害があるか又はパス品質要件を満たしていないと判断したとき、前記サービスを運ぶために使用される前記パスを前記第１のネットワークデバイスから第３のネットワークデバイスへのパスに切り替えるステップであり、前記第３のネットワークデバイスは前記切り替えの後に前記サービスを運ぶ、ステップ
をさらに含む、請求項７に記載の方法。

【請求項9】

第１のネットワークデバイスと第２のネットワークデバイスとアクセス側ネットワークデバイスを含むネットワークシステムにおいて、サービスパス検出を実施する方法であって、当該方法は、セグメントルーティング・オーバー・インターネットプロトコルバージョン６（ＳＲｖ６）ネットワークに適用され、前記第２のネットワークデバイスはトンネルを通じて前記第１のネットワークデバイスに接続され、前記アクセス側ネットワークデバイスは前記第２のネットワークデバイスに接続され、
前記第２のネットワークデバイスにより、前記第１のネットワークデバイスにより送信された第１のパケットを受信するステップであり、前記第１のパケットは、第１の指示とサービスの識別情報を含み、前記第１の指示は、前記第１のパケットが検出パケットであることを示す、ステップと、
前記第２のネットワークデバイスにより、前記第１の指示と前記サービスの前記識別情報とに基づいて、前記第１のネットワークデバイスと前記第２のネットワークデバイスとの間にあり、かつ前記サービスを運ぶために使用されるパスと、前記第２のネットワークデバイスと前記アクセス側ネットワークデバイスとの間にあり、かつ前記サービスを運ぶために使用されるパスとのうちの少なくとも１つのパス障害又はパス品質を検出するステップと、
を含み、
前記第１のパケットは第１のＩＰｖ６拡張ヘッダを含み、前記第１の指示は、前記第１のパケットの前記第１のＩＰｖ６拡張ヘッダで運ばれ、前記第１のパケットの前記第１のＩＰｖ６拡張ヘッダは、アラートラベルと制御ワードをさらに含み、前記アラートラベルと前記制御ワードは、前記第１のパケットのペイロード内の検出情報を示し、前記検出情報は、前記第２のネットワークデバイスに、前記検出情報に基づいて、前記サービスを運ぶための前記パスを検出するように指示する、方法。

【請求項10】

前記第１のパケットは双方向転送検出（ＢＦＤ）パケットであり、あるいは、前記第１のパケットは運用管理及び保守（ＯＡＭパケット）である、請求項１乃至９のうちいずれか１項に記載の方法。

【請求項11】

ネットワークシステムであって、当該ネットワークシステムは、セグメントルーティング・オーバー・インターネットプロトコルバージョン６（ＳＲｖ６）ネットワークに適用され、当該ネットワークシステムは、第１のネットワークデバイスと第２のネットワークデバイスを含み、
前記第１のネットワークデバイスは、請求項１乃至８、１０のうちいずれか１項に記載の方法を実施するように構成され、前記第２のネットワークデバイスは、請求項９乃至１０のうちいずれか１項に記載の方法を実施するように構成される、
ネットワークシステム。

【請求項12】

ネットワークデバイスであって、
メモリであり、前記メモリはコンピュータ読取可能命令を含む、メモリと、
前記メモリと通信するプロセッサであり、前記プロセッサは、前記コンピュータ読取可能命令を実行して、当該ネットワークデバイスが請求項１乃至１０のうちいずれか１項に記載の方法を実行することを可能にするように構成される、プロセッサと、
を含むネットワークデバイス。

【請求項13】

プロセッサに請求項１乃至１０のうちいずれか１項に記載の方法を実行させるコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、2020年9月21日に中国国家知識産権局に出願され「METHOD AND DEVICE FOR IMPLEMENTING FAULT DETECTION IN SRV6 SCENARIO」と題された中国特許出願第202010992436.9号に対する優先権を主張しており、本出願は、2020年11月30日に中国国家知識産権局に出願され「METHOD, DEVICE, AND SYSTEM FOR IMPLEMENTING SERVICE PATH DETECTION」と題された中国特許出願第202011375770.6号に対する優先権を主張しており、これらはその全体を参照により本明細書に組み込まれている。
［技術分野］
本出願は、通信技術の分野に関し、特に、サービスパス検出を実施する方法、デバイス、及びシステムに関する。

【背景技術】

【0002】

セグメントルーティング・オーバー・インターネットプロトコルバージョン６（segment routing over internet protocol version 6、ＳＲｖ６）ネットワークでは、現在、トンネルレベルの障害検出を実施することができる。例えば、カスタマプロバイダエッジ（provider edge、ＰＥ）デバイスが、カスタマＰＥデバイスとネットワーク側ＰＥデバイスとの間のトンネルが障害があることを検出した場合、カスタマＰＥデバイスは、本来このトンネルで運ばれるサービスの正常な実行を保証するために、トンネルレベルの切り替えを実施する。しかしながら、トンネルレベルの障害検出の粒度は粗い。ひとたび障害がサービスにより引き起こされ、トンネルで運ばれる別のサービスが正常に実行可能であると、この障害検出方法はサービスレベルの障害を正確に検出することができない。結果として、カスタマＰＥデバイスはトンネルで運ばれる全てのサービスを切り替え、換言すれば、トンネルで正常に実行されているサービスも誤って切り替えられる。結果的に、ネットワークリソースが浪費される。

【0003】

これに基づき、このシナリオにおけるサービスレベルのパス検出方法を提供して、より細かい粒度及びより正確なパス検出を実施し、正確なサービス切り替えをさらに保証することは急を要する。

【発明の概要】

【0004】

本出願の実施形態は、サービスパス検出を実施する方法、デバイス、及びシステムを提供する。あるネットワークデバイスが、指示を運ぶ検出パケットを送信し、それにより、パケットを受信するネットワークデバイスは、指示を使用することにより検出パケットをサービスパケットから正確に区別することができる。これは、ネットワークにおけるサービスの正常な実行を保証するために、受信者ネットワークデバイスがサービスレベルの障害検出を効果的に実施できることを保証する。

【0005】

本出願で提供される以下の方法、装置、デバイス、及びシステムは、ＳＲｖ６ネットワークに適用することができる。

【0006】

第１の態様によれば、本出願の一実施形態は、サービスパス検出を実施する方法を提供する。この方法は、第１のネットワークデバイスに適用される。例えば、この方法は、第１のネットワークデバイスがインターネットプロトコルバージョン６（internet protocol version 6、ＩＰｖ６）に基づいて第１のパケットを生成し、第１のパケットを第２のネットワークデバイスに送信し、第１のパケットは第１の指示とサービスの識別情報を含み、第１の指示は、第１のパケットが検出パケットであることを示すことと、第１のネットワークデバイスが第１のパケットを第２のネットワークデバイスに送信して、第１のパケットを受信する第２のネットワークデバイスに、第１の指示とサービスの識別情報とに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶ（carry）ために使用されるパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスとのうちの少なくとも１つを検出するように指示することを含むことができる。サービスを運ぶためのパス上で第２のネットワークデバイスにより実行される検出は、パス状態検出、例えば、パス障害検出又はパス品質検出でもよい。この方法によれば、送信者ネットワークデバイスが、送信される検出パケットに第１の指示とサービスの識別情報を追加し、それにより、受信者ネットワークデバイスが、受信したパケットが検出パケットであることを正確に判断し、対応するサービス情報を認識して、検出パケットに基づいて、サービスを運ぶための検出すべき（to-be-detected）パス上で接続性検出、品質検出などを実行することができることを習得できる。これは、要件を満たすことができず、ネットワークリソースが浪費されるという問題を解決する。これらの問題は、現在、ネットワークデバイス間の粗い粒度のトンネルレベルの検出のみが完了可能であるため、引き起こされている。このようにして、より細かい粒度及びより正確なサービスレベルの検出が実施され、サービスレベルのパス切り替えに対して正確な基盤が提供され、ネットワークにおけるサービスの正常及び効率的な実行が保証される。

【0007】

検出すべきパスは、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスとのうちの少なくとも１つであってよい。検出される特定のパスと検出の特定の内容は、検出パケットに含まれる検出情報に基づいて決定されてもよい。検出すべきパスが、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスとの双方を含むとき、代替的に、検出すべきパスが、第１のネットワークデバイスとアクセス側ネットワークデバイスとの間のパス範囲であると考えられてもよい。検出すべきパスに対する検出内容は、パス上のインターフェース、リンク、又はデバイスなどのオブジェクトの状態、例えば、障害状態を含んでもよく、あるいは、パス上で伝送されるデータの品質状態、例えば、パケット損失、遅延、ビット誤り、又はジッタなどの側面から実行される統計又は分析を含んでもよい。第２のネットワークデバイスは、検出内容を第１のネットワークデバイスに送信することができ、それにより、第１のネットワークデバイスは、検出結果を判断し、あるいは検出内容に基づいて検出結果をローカルで得ることができる。

【0008】

サービスの識別情報は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。サービスの識別情報は、例えば、第２のネットワークデバイスに対応する仮想プライベートネットワークセグメント識別子（virtual private network segment identifier、ＶＰＮＳＩＤ）でもよい。

【0009】

第１の指示は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。以下では、例を用いることにより、第１のパケットが第１の指示を運ぶ様々な可能な実装について説明する。

【0010】

可能な一実装において、第１のパケットは第１のＩＰｖ６ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６ヘッダ内のネクストヘッダ（next header）フィールドで運ばれる。この実装は、ＳＲｖ６ベストエフォート（best effort、ＢＥ）シナリオに適用可能である。代替的に、第１のパケットは第１のＩＰｖ６拡張ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のセグメントルーティングヘッダ（segment routing header、ＳＲＨ）内のネクストヘッダフィールドで運ばれる。この実装は、ＳＲｖ６ポリシー（policy）シナリオに適用可能である。例えば、第１のパケットにおいて第１の指示を運ぶためのネクストヘッダフィールドの値が１３７である場合、それは、第１のパケットが検出パケットであることを示す。

【0011】

この実装において、第１のパケットの第１のＩＰｖ６拡張ヘッダは、アラートラベル（alert label）と制御ワード（control word）をさらに含んでもよく、アラートラベルと制御ワードは、第１のパケットのペイロード（payload）内の検出情報を示し、検出情報は、第２のネットワークデバイスに、検出情報に基づいて、サービスを運ぶためのパスを検出するように指示する。アラートラベルと制御ワードが検出情報を示すことは、アラートラベルと制御ワードとの値に基づいて、その後に運ばれる内容が検出情報であると判断すること、又は、アラートラベルと制御ワードとの値に基づいて、その後に運ばれる内容が検出情報であると判断すること、及び検出情報のタイプを判断することでもよい。例えば、アラートラベル１３と制御ワードに基づいて、その後に運ばれる内容が検出情報であり、検出情報のタイプが双方向転送検出（bidirectional forwarding detection、ＢＦＤ）情報であると判断されてもよい。

【0012】

別の可能な実装において、第１のパケットは第１のＩＰｖ６ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６ヘッダ内の第１の宛先アドレス（destination address、ＤＡ）フィールド内の引数（arguments、ａｒｇｓ）フィールドで運ばれる。この実装は、ＳＲｖ６ＢＥシナリオに適用可能である。代替的に、第１のパケットは第１のＩＰｖ６拡張ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内の第１のＤＡフィールド内のａｒｇｓフィールドで運ばれる。この実装は、ＳＲｖ６ポリシーシナリオに適用可能である。例えば、第１のパケットにおいて第１の指示を運ぶためのＤＡフィールド内のａｒｇｓフィールドの値が０に等しくない（例えば、ａｒｇｓの値が３に等しい）場合、それは、第１のパケットが検出パケットであることを示す。

【0013】

さらに別の可能な実装において、第１のパケットは第１のＩＰｖ６拡張ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６拡張ヘッダのＳＲＨ内のフラグ（ｆｌａｇｓ）フィールドで運ばれてもよい。例えば、第１のパケットにおいて第１の指示を運ぶためのｆｌａｇｓフィールドの値が０に等しくない（例えば、値が１に等しい）場合、それは、第１のパケットが検出パケットであることを示す。

【0014】

さらに別の可能な実装において、第１のパケットは第１のＩＰｖ６拡張ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６拡張ヘッダのホップバイホップ（hop-by-hop、ＨＢＨ）オプションヘッダ内のタイプ・レングス・値（type-length-value、ＴＬＶ）フィールドで運ばれ、あるいは第１のＩＰｖ６拡張ヘッダの宛先オプションヘッダ（destination option header、ＤＯＨ）内のＴＬＶフィールドで運ばれてもよい。例えば、第１のパケットにおけるＨＢＨオプションヘッダフィールドが、第１の指示を運ぶためのＴＬＶフィールドを含む場合、それは、第１のパケットが検出パケットであることを示す。別の例として、第１のパケットにおけるＤＯＨフィールドが、第１の指示を運ぶためのＴＬＶフィールドを含む場合、それは、第１のパケットが検出パケットであることを示す。

【0015】

いくつかの可能な実装において、この方法は、第１のネットワークデバイスが第２のパケットを第２のネットワークデバイスに送信し、第２のパケットは、サービスを運ぶために使用されるサービスパケットであり、第２のパケットは第１の指示を含まないことをさらに含んでもよい。このようにして、第１のパケットと第２のパケットを受信した後、第２のネットワークデバイスは、パケットで運ばれる指示に基づいて、パケットが検出パケットであるか又はサービスパケットであるかを判断して、特定のパケットタイプに基づいて対応する処理を実行することができる。

【0016】

一例において、第２のパケットが第１の指示を含まないことは、第２のパケットが第１の指示を運ぶために使用されるフィールドを含まないことを意味する場合がある。例えば、第１のパケットにおけるＨＢＨオプションヘッダフィールドが、第１の指示を運ぶためのＴＬＶフィールドを含むと仮定すると、第２のパケットにおけるＨＢＨオプションヘッダは、第１の指示を運ぶために使用されるＴＬＶフィールドを含まない。別の例として、第１のパケットにおけるＤＯＨフィールドが、第１の指示を運ぶためのＴＬＶフィールドを含むと仮定すると、第２のパケットにおけるＤＯＨフィールドは、第１の指示を運ぶために使用されるＴＬＶフィールドを含まない。

【0017】

別の例において、第２のパケットが第１の指示を含まないことは、代替的に、第２のパケットが第１の指示を運ぶためのフィールドを含むが、第１のパケット内のフィールドの値が第２のパケット内のフィールドの値と異なり、これら値は異なる指示を運ぶために使用されていることを意味する場合がある。第１のパケット内のフィールドの値は、第１の指示を運ぶために使用され、第１の指示は、第１のパケットが検出パケットであることを示す。第２のパケット内のフィールドの値は、第２の指示を運ぶために使用され、第２の指示は、第２のパケットがサービスパケットであることを示す。一ケースにおいて、第２のパケットが第２のＩＰｖ６ヘッダを含み、第２の指示が、第２のＩＰｖ６ヘッダ内のネクストヘッダフィールドで運ばれ、第１の指示が、第１のＩＰｖ６ヘッダ内のネクストヘッダフィールドの第１の値であると仮定すると、第２の指示は、第２のＩＰｖ６ヘッダ内のネクストヘッダフィールドの第２の値（これにおいて、第１の値は第２の値と等しくない）であってよい。代替的に、第２のパケットが第２のＩＰｖ６拡張ヘッダを含み、第２の指示が、第２のＩＰｖ６拡張ヘッダの第２のＳＲＨ内のネクストヘッダフィールドで運ばれ、第１の指示が、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内のネクストヘッダフィールドの第１の値であると仮定すると、第２の指示は、第２のＳＲＨ内のネクストヘッダフィールドの第２の値であってよい。例えば、第１のパケットにおいて第１の指示を運ぶためのネクストヘッダフィールドの値が１３７である場合、それは、第１のパケットが検出パケットであることを示す。第２のパケットにおいて第２の指示を運ぶためのネクストヘッダフィールドの値が１４３である場合、それは、第２のパケットがサービスパケットであることを示す。別のケースにおいて、第２のパケットが第２のＩＰｖ６ヘッダを含み、第２の指示が、第２のＩＰｖ６ヘッダ内の第２のＤＡフィールド内のａｒｇｓフィールドで運ばれ、第１の指示が、第１のＩＰｖ６ヘッダ内の第１のＤＡフィールド内のａｒｇｓフィールドの第３の値であると仮定すると、第２の指示は、第２のＤＡフィールド内のａｒｇｓフィールドの第４の値（これにおいて、第３の値は第４の値と等しくない）であってよい。代替的に、第２のパケットが第２のＩＰｖ６拡張ヘッダを含み、第２の指示が、第２のＩＰｖ６拡張ヘッダの第２のＳＲＨ内の第２のＤＡフィールド内のａｒｇｓフィールドで運ばれ、第１の指示が、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内の第１のＤＡフィールド内のａｒｇｓフィールドの第３の値であると仮定すると、第２の指示は、第２のＳＲＨ内の第２のＤＡフィールド内のａｒｇｓフィールドの第４の値であってよい。例えば、第１のパケットにおいて第１の指示を運ぶためのＤＡフィールド内のａｒｇｓフィールドの値が３である場合、それは、第１のパケットが検出パケットであることを示す。第２のパケットにおいて第２の指示を運ぶためのＤＡフィールド内のａｒｇｓフィールドの値が０である場合、それは、第２のパケットがサービスパケットであることを示す。さらに別のケースにおいて、第２のパケットが第２のＩＰｖ６拡張ヘッダを含み、第２の指示が、第２のＩＰｖ６拡張ヘッダのＳＲＨ内のｆｌａｇｓフィールドで運ばれ、第１の指示が、第１のＩＰｖ６拡張ヘッダのＳＲＨ内のフラグｆｌａｇｓフィールドの第５の値であると仮定すると、第２の指示は、第２のＩＰｖ６拡張ヘッダのＳＲＨ内のフラグｆｌａｇｓフィールドの第６の値（これにおいて、第５の値は第６の値と等しくない）であってよい。

【0018】

第１のネットワークデバイスにより第２のネットワークデバイスに送信される第１のパケットは、第１の指示とサービスの識別情報を運び、第１のパケットの送信フェーズの目的は、第２のネットワークデバイスが、第１の指示とサービスの識別情報とに基づいて、サービスを運ぶためのパスを検出することを可能にすることである。ただし、第２のネットワークデバイスが第１のパケットを本当に受信するかどうかは限定されない。

【0019】

一例において、第１のネットワークデバイスと第２のネットワークデバイスとの間のリンク又はデバイスが障害があり、第２のネットワークデバイスが障害があるとき、第２のネットワークデバイスは、第１のパケットを受信するのに失敗する場合がある。したがって、第１のネットワークデバイスは、第２のネットワークデバイスにより送信された応答パケットを予め設定された期間内に受信せず、サービスを運ぶためのパスは障害があると判断することができる。この例では、第１のネットワークデバイスと第２のネットワークデバイスとの間の転送パスの状態が第１のパケットの送信フェーズにおいて予測できないため、第２のネットワークデバイスは実際には、この例で列挙された障害シナリオを含むいくつかのあり得るケースにおいて第１のパケットを正常に受信できない。ただし、これは、第１のパケットの送信フェーズにおける第１のネットワークデバイスの目的に影響せず、これにおいてその目的は、第２のネットワークデバイスが、第１の指示とサービスの識別情報とに基づいて、サービスを運ぶためのパスを検出することを可能にすることである。

【0020】

別の例において、第２のネットワークデバイスが第１のパケットを受信すると仮定すると、第２のネットワークデバイスにより認識及び検出できる内容は、パス上のアクセス側ネットワークデバイスに接続するために第２のネットワークデバイスにより使用されるリンク又はインターフェースが障害があるかどうかを含むことができる。別のあり得るケースでは、第２のネットワークデバイスは、いくつかの方法で、第２のネットワークデバイスに接続されたアクセス側ネットワークが障害があるかどうか、例えば、第２のネットワークデバイスに直接又は間接的に接続されたアクセス側ネットワークデバイス、又はアクセス側ネットワーク内のリンク又はポートは障害があるかどうかをさらに判断することができる。本明細書で言及されるアクセス側は、いくつかの場合にカスタマと呼ばれることもある。この例では、一ケースにおいて、第２のネットワークデバイスは、アクセス側ネットワークデバイスに接続するために第２のネットワークデバイスにより使用されるインターフェース又はリンクが障害があると判断したとき、第１のパケットに応答しないことを選択してもよい。この場合、第１のネットワークデバイスは、第２のネットワークデバイスにより送信された応答パケットを予め設定された期間内に受信せず、第１のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶためのパスは障害があると判断することができる。別のケースにおいて、第２のネットワークデバイスは、第１のパケットに対応する応答を生成し、応答を第１のネットワークデバイスに送信することを選択することができる。この場合、第２のネットワークデバイスにより送信された応答パケットを受信したとき、第１のネットワークデバイスは、応答パケットで運ばれるリンク状態情報又はインターフェース状態情報に基づいて、サービスを運ぶパスは障害があるかどうかを判断し、例えば、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスは障害があると判断することができる。

【0021】

さらに別の例において、第２のネットワークデバイスが第１のパケットを受信すると仮定すると、第２のネットワークデバイスはさらに、サービスを運ぶために使用されるパスのパス品質を検出し、例えば、第１のネットワークデバイスと第２のネットワークデバイスとの間のパス上のパケット損失及び遅延などの品質データを検出することができる。一ケースにおいて、対応する品質フィードバックデータが、第２のネットワークデバイスにより第１のネットワークデバイスに送信される応答パケットで運ばれる。品質フィードバックデータは、第２のネットワークデバイスによりフィードバックされた品質データ、及び／又は、第２のネットワークデバイスが第１のネットワークデバイスに応答パケットを送信するパス上で応答パケットに複数の中間デバイスにより追加された品質フィードバックデータを含んでもよく、それにより、第１のネットワークデバイスは、一方向又は双方向のパス品質検出結果を判断する。別のケースでは、第２のネットワークデバイスは、代替的に、検出を通じて得られた品質データに基づいて一方向パス品質検出結果を直接判断してもよい。

【0022】

いくつかの可能な実装において、第１のネットワークデバイスが、サービスを運ぶためのパスが障害があり又はパス品質が要件を満たしていないと判断した場合、この方法は、第１のネットワークデバイスが、サービスを運ぶために使用されるパスを第１のネットワークデバイスから第３のネットワークデバイスへのパスに切り替え、第３のネットワークデバイスは切り替えの後にサービスを運ぶことをさらに含んでもよい。このようにして、サービスレベルの障害検出を通じて、どれかのサービスを運ぶための障害のあるパスを正確に検出することができ、それにより、サービスを運ぶためのパスが切り替えられ、トンネルレベルの切り替えにより実行されるトンネルで運ばれる全てのサービスの転送パスの切り替えは実行される必要がなくなる。このようにして、ネットワークリソースが特定の程度まで節約される。

【0023】

第２の態様によれば、本出願の一実施形態は、サービスパス検出を実施する方法をさらに提供する。この方法は、第２のネットワークデバイスに適用される。例えば、この方法は、第２のネットワークデバイスが第１のネットワークデバイスにより送信された第１のパケットを受信し、第１のパケットは第１の指示とサービスの識別情報を含み、第１の指示は、第１のパケットが検出パケットであることを示すことと、第２のネットワークデバイスが、第１の指示とサービスの識別情報とに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスとのうちの少なくとも１つを検出できることを含むことができる。この方法によれば、送信者ネットワークデバイスが、送信される検出パケットに第１の指示とサービスの識別情報を追加し、それにより、受信者ネットワークデバイスが、受信したパケットが検出パケットであることを正確に判断し、対応するサービスを認識して、検出パケットに基づいて、サービスを運ぶためのパス上で接続性検出、品質検出などを実行することができることを習得できる。これは、粗い粒度が要件を満たすことができず、ネットワークリソースが浪費されるという問題を解決する。これらの問題は、現在の関連技術において、ネットワークデバイス間のトンネルレベルの検出のみがサポートされているため、引き起こされている。このようにして、より細かい粒度及びより正確なサービスレベルの検出が実施され、サービスレベルの切り替えに対して正確な基盤が提供され、ネットワークにおけるサービスの正常な実行が保証される。

【0024】

サービスの識別情報は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。サービスの識別情報は、例えば、第２のネットワークデバイスに対応するＶＰＮＳＩＤでもよい。

【0025】

【0026】

可能な一実装において、第１のパケットは第１のＩＰｖ６ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６ヘッダ内のネクストヘッダフィールドで運ばれる。この実装は、ＳＲｖ６ＢＥシナリオに適用可能である。代替的に、第１のパケットは第１のＩＰｖ６拡張ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内のネクストヘッダフィールドで運ばれる。この実装は、ＳＲｖ６ポリシーシナリオに適用可能である。

【0027】

この実装において、第１のパケットの第１のＩＰｖ６拡張ヘッダは、アラートラベルと制御ワードをさらに含んでもよく、アラートラベルと制御ワードは、第１のパケットのペイロード内の検出情報を示し、検出情報は、第２のネットワークデバイスに、検出情報に基づいて、サービスを運ぶためのパスを検出するように指示する。アラートラベルと制御ワードが検出情報を示すことは、アラートラベルと制御ワードとの値に基づいて、その後に運ばれる内容が検出情報であると判断すること、又は、アラートラベルと制御ワードとの値に基づいて、その後に運ばれる内容が検出情報であると判断すること、及び検出情報のタイプを判断することでもよい。例えば、アラートラベル１３と制御ワードに基づいて、その後に運ばれる内容が検出情報であり、検出情報のタイプがＢＦＤ情報であると判断されてもよい。

【0028】

別の可能な実装において、第１のパケットは第１のＩＰｖ６ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６ヘッダ内の第１のＤＡフィールド内のａｒｇｓフィールドで運ばれる。この実装は、ＳＲｖ６ＢＥシナリオに適用可能である。代替的に、第１のパケットは第１のＩＰｖ６拡張ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内の第１のＤＡフィールド内のａｒｇｓフィールドで運ばれる。この実装は、ＳＲｖ６ポリシーシナリオに適用可能である。

【0029】

さらに別の可能な実装において、第１のパケットは第１のＩＰｖ６拡張ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６拡張ヘッダのＳＲＨ内のｆｌａｇｓフィールドで運ばれてもよい。

【0030】

さらに別の可能な実装において、第１のパケットは第１のＩＰｖ６拡張ヘッダを含むことができ、第１の指示は、第１のＩＰｖ６拡張ヘッダのＨＢＨオプションヘッダ内のＴＬＶフィールドで運ばれ、あるいは第１のＩＰｖ６拡張ヘッダのＤＯＨ内のＴＬＶフィールドで運ばれてもよい。

【0031】

いくつかの可能な実装において、この方法は、第２のネットワークデバイスが第１のネットワークデバイスにより送信された第２のパケットを受信し、第２のパケットはサービスを運ぶために使用されるサービスパケットであり、第２のパケットは第１の指示は含まないことをさらに含んでもよい。このようにして、第１のパケットと第２のパケットを受信した後、第２のネットワークデバイスは、パケットで運ばれる指示に基づいて、パケットが検出パケットであるか又はサービスパケットかを判断して、特定のパケットタイプに基づいて対応する処理を実行することができ、それにより、サービスレベルの検出が可能である。

【0032】

第２のパケットが第１の指示を含まないことは、第２のパケットが第１の指示を運ぶために使用されるフィールドを含まないことを意味する場合があり、あるいは、第２のパケットが第１の指示を運ぶために使用されるフィールドを含むが、第２のパケット内のフィールドの値が第１のパケット内のフィールドの値と異なり、これらの値は異なる指示を運ぶためにそれぞれ使用されることを意味する場合がある。第１のパケット内のフィールドの値は、第１の指示を運ぶために使用され、第１の指示は、第１のパケットが検出パケットであることを示す。第２のパケット内のフィールドの値は、第２の指示を運ぶために使用され、第２の指示は、第２のパケットがサービスパケットであることを示す。一ケースにおいて、第２のパケットが第２のＩＰｖ６ヘッダを含み、第２の指示が、第２のＩＰｖ６ヘッダ内のネクストヘッダフィールドで運ばれ、第１の指示が、第１のＩＰｖ６ヘッダ内のネクストヘッダフィールドの第１の値であると仮定すると、第２の指示は、第２のＩＰｖ６ヘッダ内のネクストヘッダフィールドの第２の値（これにおいて、第１の値は第２の値と等しくない）であってよい。代替的に、第２のパケットが第２のＩＰｖ６拡張ヘッダを含み、第２の指示が、第２のＩＰｖ６拡張ヘッダの第２のＳＲＨ内のネクストヘッダフィールドで運ばれ、第１の指示が、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内のネクストヘッダフィールドの第１の値であると仮定すると、第２の指示は、第２のＳＲＨ内のネクストヘッダフィールドの第２の値であってよい。別のケースにおいて、第２のパケットが第２のＩＰｖ６ヘッダを含み、第２の指示が、第２のＩＰｖ６ヘッダ内の第２のＤＡフィールド内のａｒｇｓフィールドで運ばれ、第１の指示が、第１のＩＰｖ６ヘッダ内の第１のＤＡフィールド内のａｒｇｓフィールドの第３の値であると仮定すると、第２の指示は、第２のＤＡフィールド内のａｒｇｓフィールドの第４の値（これにおいて、第３の値は第４の値と等しくない）であってよい。代替的に、第２のパケットが第２のＩＰｖ６拡張ヘッダを含み、第２の指示が、第２のＩＰｖ６拡張ヘッダの第２のＳＲＨ内の第２のＤＡフィールド内のａｒｇｓフィールドで運ばれ、第１の指示が、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内の第１のＤＡフィールド内のａｒｇｓフィールドの第３の値であると仮定すると、第２の指示は、第２のＳＲＨ内の第２のＤＡフィールド内のａｒｇｓフィールドの第４の値であってよい。さらに別のケースにおいて、第２のパケットが第２のＩＰｖ６拡張ヘッダを含み、第２の指示が、第２のＩＰｖ６拡張ヘッダのＳＲＨ内のｆｌａｇｓフィールドで運ばれ、第１の指示が、第１のＩＰｖ６拡張ヘッダのＳＲＨ内のフラグｆｌａｇｓフィールドの第５の値であると仮定すると、第２の指示は、第２のＩＰｖ６拡張ヘッダのＳＲＨ内のフラグｆｌａｇｓフィールドの第６の値（これにおいて、第５の値は第６の値と等しくない）であってよい。

【0033】

可能な一実装において、第２のネットワークデバイスは、受信した第１のパケットに基づいて、サービスを運ぶために使用されるパスのパス状態を検出することができ、パス状態は、例えば、パス障害状態又はパス品質状態であってよい。一例において、第２のネットワークデバイスが第１のパケットを受信すると仮定すると、第２のネットワークデバイスは、第１の指示とサービスの識別情報とに基づいて、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスを検出し、あるいは、ある方法でアクセス側ネットワーク内のパスを検出し、例えば、アクセス側ネットワーク内のネットワークデバイスに接続されたリンク又は含まれるインターフェースを検出することができる。この例では、一ケースにおいて、第２のネットワークデバイスは、第１のパケットに応答しないことを選択する場合がある。この場合、第１のネットワークデバイスは、第２のネットワークデバイスにより送信された応答パケットを予め設定された期間内に受信せず、サービスを運ぶためのパスは障害があると判断することができる。例えば、第１のネットワークデバイスは、第１のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスは障害があると判断する。別のケースでは、第２のネットワークデバイスは、第１のパケットに対応する応答を生成し、その応答を第１のネットワークデバイスに送信することを選択する場合がある。この場合、第２のネットワークデバイスにより送信された応答パケットを受信したとき、第１のネットワークデバイスは、応答パケットで運ばれるリンク状態情報又はインターフェース状態情報に基づいて、サービスを運ぶためのパスが障害があるかどうかを判断することができる。例えば、第１のネットワークデバイスは、応答パケットに基づいて、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスは障害があると判断することができる。

【0034】

別の例において、第２のネットワークデバイスは、さらに、受信した第１のパケットに基づいて、サービスを運ぶために使用されるパスのパス品質を検出し、例えば、第１のネットワークデバイスと第２のネットワークデバイスとの間のパス上のパケット損失及び遅延などの品質データを検出することができる。一ケースにおいて、第２のネットワークデバイスは、対応する品質フィードバックデータを第１のネットワークデバイスに送信される応答パケットに含めることができ、それにより、第１のネットワークデバイスは、双方向パス品質検出結果を判断する。別のケースでは、第２のネットワークデバイスは、代替的に、検出を通じて得られた品質データに基づいて一方向パス品質検出結果を直接判断してもよい。

【0035】

いくつかの可能な実装において、この方法において、例えば、第２のネットワークデバイスが、第１の指示とサービスの識別情報とに基づいて、サービスを運ぶためのパスを検出することは、第２のネットワークデバイスが、第１のパケットが検出パケットであると判断し、第１の指示に基づいて実行される検出がローカルでサポートされていると判断した場合、第２のネットワークデバイスが、ローカル検出ポリシーに従って、サービスを運ぶためのパスを検出することをさらに含んでもよい。ローカル障害検出ポリシーに従って、第１のパケットは対応する検出プロセスに送信されてもよく、対応する検出プロセスで障害検出が実行される。例えば、第１のパケットがＢＦＤ検出パケットであると仮定すると、ＢＦＤ検出パケットがローカルでサポートされていると判断したとき、第２のネットワークデバイスは、ＢＦＤ検出パケット内のサービス関連の内容及び検出情報をローカルＢＦＤプロセスに送信して、ＢＦＤプロセスを使用することにより対応する障害検出を実行する。第１の指示に基づいて実行される検出がローカルでサポートされていることは、第１の指示により示される検出機能がネットワークデバイスのローカル構成を通じて効にされていることを意味する場合がある。第１のパケットを対応する検出プロセスに送信することは、例えば、第１のパケット内のトンネル情報（第１のパケット内のＳＲＨなど）が除去された後の残りのサービス関連の内容及び検出情報を対応する検出プロセスに送信することでもよいことに留意されたい。

【0036】

第１の態様と第２の態様で提供される方法において、第１のネットワークデバイスは、サービスを運ぶイングレスＰＥデバイスでもよく、第２のネットワークデバイスは、サービスを運ぶエグレスＰＥデバイスでもよい。代替的に、第１のネットワークデバイスは、第１の態様及び第２の態様に記載された検出方法をネットワークにおいて開始することができる別のタイプのネットワークデバイスでもよく、第２のネットワークデバイスは、受信した検出パケットに応答し、対応するパス検出を実行することができる別の可能なタイプのデバイスでもよい。

【0037】

第１の態様と第２の態様で提供される方法において、第１のネットワークデバイスと第２のネットワークデバイスとの間で運ばれるサービスは、レイヤ２仮想プライベートネットワーク（layer 2 virtual private network、Ｌ２ＶＰＮ）サービスでもよい。Ｌ２ＶＰＮサービスは、例えば、従来のＶＰＮ技術又はイーサネット仮想プライベートネットワーク（Ethernet virtual private network、ＥＶＰＮ）技術により運ばれるサービスを含んでもよい。従来のＶＰＮサービスとＥＶＰＮサービスとの双方が、仮想専用線（virtual leased line、ＶＬＬ）サービスモデル又は仮想プライベートローカルエリアネットワークサービス（virtual private LAN service、ＶＰＬＳ）モデルを使用することによりネットワークに配備される場合がある。

【0038】

第１の態様と第２の態様で提供される方法において、第１のパケットはＢＦＤパケットでもよく、あるいは運用管理及び保守（operation administration and maintenance、ＯＡＭ）パケットでもよい。第１のパケットの異なるタイプ、例えば、サービスパス障害検出又はサービスパス品質検出に基づいて、異なるサービスパス検出機能を実装することができる。サービスパス品質検出は、遅延、パケット損失、又はジッタなどの指標に基づいて実行されてもよい。

【0039】

第１のパケットがＢＦＤパケットであるとき、前述の方法によれば、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶためのパス上の接続性検出を実施できるだけでなく、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶためのパス上の接続性検出も実施することができる。このようにして、第１のネットワークデバイスは、第１のネットワークデバイスと第２のネットワークデバイスとの間のトンネルパスの接続性だけでなく、第１のネットワークデバイスからアクセス側ネットワークデバイスへの、サービスを運ぶために使用されるパスの接続性も習得して、サービスレベルの接続性検出の効果を達成することができる。

【0040】

第１のパケットがＯＡＭパケットであるとき、前述の方法に従って検出されるパス状態は、パス接続性とパス品質を含んでもよい。可能な一ケースにおいて、ＯＡＭパケットがパス品質検出を実施することは、第１のネットワークデバイスがＯＡＭパケットを第２のネットワークデバイスに送信して、第１のネットワークデバイスにより送信されたデータの統計情報（例えば、送信されたデータパケットの数量及びタイムスタンプ）を通知することを含んでもよい。第２のネットワークデバイスは、ＯＡＭパケットで運ばれたサービスの識別情報に基づいて検出すべきサービスを決定し、検出すべきサービスのための受信データに対応する受信統計結果を得て、その統計情報を処理することにより、検出すべきサービスを運ぶためのパスに対応するパス品質検出結果を得ることができる。任意で、第２のネットワークデバイスは、検出結果を運ぶＯＡＭパケットをさらに生成し、このパケットを第１のネットワークデバイスに送信して、第１のネットワークデバイスに検出すべきサービスのパス品質を通知してもよい。代替的に、別の可能なケースにおいて、ＯＡＭパケットがパス品質検出を実施することは、第１のネットワークデバイスがＯＡＭパケットを第２のネットワークデバイスに送信して、第１のネットワークデバイスにより送信されたデータの統計情報を通知することを含んでもよい。第２のネットワークデバイスは、ＯＡＭパケットで運ばれたサービスの識別情報に基づいて検出すべきサービスを決定し、検出すべきサービスの受信データに対応する統計結果を得て、この統計結果を生成されたＯＡＭパケットに含め、そのパケットを第１のネットワークデバイスに送信して、第１のネットワークデバイスに、受信したＯＡＭパケット内の統計結果を処理し、検出すべきサービスを運ぶためのパスの検出結果を得て、さらに検出すべきサービスを運ぶためのパスの品質を判断するように指示することができる。さらに、ＯＡＭパケットは検出パケットとして使用される。１つの態様において、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶためのパスのパス品質を検出することができ、別の態様において、サービスを運ぶためのパスの接続性を検出することができる。

【0041】

第３の態様によれば、本出願の一実施形態は、サービスパス検出を実施する装置をさらに提供する。この装置は第１のネットワークデバイスに適用され、この装置はＳＲｖ６をサポートするネットワークに適用される。この装置は、生成ユニットと送信ユニットを含むことができる。生成ユニットは、インターネットプロトコルバージョン６ＩＰｖ６に基づいて第１のパケットを生成するように構成され、第１のパケットは、第１の指示とサービスの識別情報を含み、第１の指示は、第１のパケットが検出パケットであることを示す。送信ユニットは、第１のパケットを第２のネットワークデバイスに送信して、第１のパケットを受信する第２のネットワークデバイスに、第１の指示とサービスの識別情報とに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶためのパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶためのパスとのうちの少なくとも１つを検出するよう指示するように構成される。

【0042】

サービスの識別情報は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。

【0043】

第１の指示は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。

【0044】

一例において、第１のパケットは第１のＩＰｖ６ヘッダを含み、第１の指示は、第１のＩＰｖ６ヘッダ内のネクストヘッダフィールドで運ばれ、あるいは、第１のパケットは第１のＩＰｖ６拡張ヘッダを含み、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のセグメントルーティングヘッダＳＲＨ内のネクストヘッダフィールドで運ばれる。第１のパケットの第１のＩＰｖ６拡張ヘッダは、アラートラベルと制御ワードをさらに含み、アラートラベルと制御ワードは、第１のパケットのペイロードｐａｙｌｏａｄ内の検出情報を示し、検出情報は、第２のネットワークデバイスに、検出情報に基づいて、サービスを運ぶためのパスを検出するように指示する。

【0045】

別の例において、第１のパケットは第１のＩＰｖ６ヘッダを含み、第１の指示は、第１のＩＰｖ６ヘッダ内の第１の宛先アドレスＤＡフィールド内の引数ａｒｇｓフィールドで運ばれ、あるいは、第１のパケットは第１のＩＰｖ６拡張ヘッダを含み、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内の第１のＤＡフィールド内のａｒｇｓフィールドで運ばれる。

【0046】

さらに別の例において、第１のパケットは第１のＩＰｖ６拡張ヘッダを含み、第１の指示は、第１のＩＰｖ６拡張ヘッダのＳＲＨ内のフラグｆｌａｇｓフィールドで運ばれる。

【0047】

さらに別の例において、第１のパケットは第１のＩＰｖ６拡張ヘッダを含み、第１の指示は、第１のＩＰｖ６拡張ヘッダのホップバイホップＨＢＨオプションヘッダ内のタイプ・レングス・値ＴＬＶフィールドで運ばれ、あるいは第１のＩＰｖ６拡張ヘッダの宛先オプションヘッダＤＯＨ内のＴＬＶフィールドで運ばれる。

【0048】

いくつかの可能な実装において、送信ユニットはさらに、第２のパケットを第２のネットワークデバイスに送信するように構成され、第２のパケットは、サービスを運ぶために使用されるサービスパケットであり、第２のパケットは第１の指示を含まない。第２のパケットは、第２の指示をさらに含んでもよく、第２の指示は、第２のパケットがサービスパケットであることを示し、第２の指示は、第１の指示と異なる。

【0049】

第２の指示が第１の指示と異なることは、第２のパケットが第２のＩＰｖ６ヘッダを含み、第２の指示は、第２のＩＰｖ６ヘッダ内のネクストヘッダフィールドで運ばれ、第１の指示は、第１のＩＰｖ６ヘッダ内のネクストヘッダフィールドの第１の値であり、第２の指示は、第２のＩＰｖ６ヘッダ内のネクストヘッダフィールドの第２の値である；第２のパケットが第２のＩＰｖ６拡張ヘッダを含み、第２の指示は、第２のＩＰｖ６拡張ヘッダの第２のＳＲＨ内のネクストヘッダフィールドで運ばれ、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内のネクストヘッダフィールドの第１の値であり、第２の指示は、第２のＳＲＨ内のネクストヘッダフィールドの第２の値である；第２のパケットが第２のＩＰｖ６ヘッダを含み、第２の指示は、第２のＩＰｖ６ヘッダ内の第２のＤＡフィールド内のａｒｇｓフィールドで運ばれ、第１の指示は、第１のＩＰｖ６ヘッダ内の第１のＤＡフィールド内のａｒｇｓフィールドの第３の値であり、第２の指示は、第２のＤＡフィールド内のａｒｇｓフィールドの第４の値である；第２のパケットが第２のＩＰｖ６拡張ヘッダを含み、第２の指示は、第２のＩＰｖ６拡張ヘッダの第２のＳＲＨ内の第２のＤＡフィールド内のａｒｇｓフィールドで運ばれ、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内の第１のＤＡフィールド内のａｒｇｓフィールドの第３の値であり、第２の指示は、第２のＳＲＨ内の第２のＤＡフィールド内のａｒｇｓフィールドの第４の値である；あるいは、第２のパケットが第２のＩＰｖ６拡張ヘッダを含み、第２の指示は、第２のＩＰｖ６拡張ヘッダのＳＲＨ内のｆｌａｇｓフィールドで運ばれ、第１の指示は、第１のＩＰｖ６拡張ヘッダのＳＲＨ内のフラグｆｌａｇｓフィールドの第５の値であり、第２の指示は、第２のＩＰｖ６拡張ヘッダのＳＲＨ内のフラグｆｌａｇｓフィールドの第６の値であることを含んでもよい。

【0050】

いくつかの可能な実装において、この装置は判断ユニットをさらに含んでもよい。判断ユニットは、第１のパケットに対する第２のネットワークデバイスの応答パケットが予め設定された期間内に受信されない場合、第１のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスは障害があると判断するように構成される。

【0051】

いくつかの可能な実装において、この装置は受信ユニットと判断ユニットをさらに含んでもよい。受信ユニットは、第１のパケットに対する第２のネットワークデバイスの応答パケットを受信するように構成され、判断ユニットは、応答パケットに基づいて、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスのパス状態を判断するように構成される。

【0052】

いくつかの可能な実装において、装置は切り替えユニットをさらに含んでもよい。切り替えユニットは、第１のパケットに対する第２のネットワークデバイスの応答パケットが予め設定された期間内に受信されないことに基づいて、サービスを運ぶために使用されるパスは障害があると判断し、あるいはパス状態に基づいて、サービスを運ぶために使用されるパスは障害があるか又はパス品質要件を満たしていないと判断したときに、サービスを運ぶために使用されるパスを第１のネットワークデバイスから第３のネットワークデバイスへのパスに切り替えるように構成され、第３のネットワークデバイスは、切り替えの後にサービスを運ぶ。

【0053】

第３の態様で提供されるサービスパス検出を実施する装置は、第１の態様で言及された関連する動作を実行するように構成される。装置の具体的な実装と効果については、第１の態様における関連する説明を参照する。詳細はここで再度説明されない。

【0054】

第４の態様によれば、本出願の一実施形態は、サービスパス検出を実施する装置をさらに提供する。この装置は第２のネットワークデバイスに適用され、この装置はＳＲｖ６をサポートするネットワークに適用される。この装置は、受信ユニットと検出ユニットを含むことができる。受信ユニットは、第１のネットワークデバイスにより送信された第１のパケットを受信するように構成され、第１のパケットは第１の指示とサービスの識別情報を含み、第１の指示は、第１のパケットが検出パケットであることを示す。検出ユニットは、第１の指示とサービスの識別情報とに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶためのパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶためのパスとのうちの少なくとも１つを検出するように構成される。

【0055】

サービスの識別情報は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。

【0056】

第１の指示は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。

【0057】

【0058】

【0059】

【0060】

【0061】

いくつかの可能な実装において、受信ユニットはさらに、第１のネットワークデバイスにより送信された第２のパケットを受信するように構成され、第２のパケットは、サービスを運ぶために使用されるサービスパケットであり、第２のパケットは第１の指示を含まない。第２のパケットは第２の指示をさらに含んでもよく、第２の指示は、第２のパケットがサービスパケットであることを示し、第２の指示は、第１の指示と異なる。

【0062】

【0063】

いくつかの可能な実装において、この装置は送信ユニットをさらに含んでもよい。送信ユニットは、第１のネットワークデバイスに応答パケットを送信するように構成され、それにより、第１のネットワークデバイスは、応答パケットに基づいて、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶためのパスは障害があることを判断する。第２のネットワークデバイスにより送信される応答パケットは、第２のネットワークデバイスのインターフェース状態情報を含んでもよく、インターフェース状態情報は、第１のネットワークデバイスに、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶためのパスが障害があることを判断するように指示する。

【0064】

いくつかの可能な実装において、検出ユニットは具体的に、第１のパケットが検出パケットであると判断され、第１の指示に基づいて実行される検出がローカルでサポートされていると判断された場合、ローカル検出ポリシーに従って、サービスを運ぶためのパスを検出するように構成されてもよい。

【0065】

第４の態様で提供されるサービスパス検出を実施する装置は、第２の態様で言及された関連する動作を実行するように構成される。装置の具体的な実装と効果については、第２の態様における関連する説明を参照する。詳細はここで再度説明されない。

【0066】

第３の態様及び第４の態様で提供される装置において、サービスパス検出を実施する、第１のネットワークデバイスに適用される装置は、サービスを運ぶイングレスＰＥデバイスでもよく、サービスパス検出を実施する、第２のネットワークデバイスに適用される装置は、サービスを運ぶエグレスＰＥデバイスでもよい。

【0067】

第３の態様及び第４の態様で提供される装置において、サービスパス検出を実施する装置間で運ばれるサービスは、Ｌ２ＶＰＮサービスでもよい。Ｌ２ＶＰＮサービスは、例えば、従来のＶＰＮ技術又はＥＶＰＮ技術で運ばれるサービスを含んでもよい。従来のＶＰＮサービスとＥＶＰＮサービスの双方が、ＶＬＬサービスモデル又はＶＰＬＳサービスモデルを使用することによりネットワークに配備されてもよい。

【0068】

第３の態様及び第４の態様で提供される装置において、第１のパケットはＢＦＤパケットでもよく、あるいはＯＡＭパケットでもよい。

【0069】

第５の態様によれば、本出願は、ネットワークデバイスをさらに提供する。ネットワークデバイスは、ネットワークデバイスが第１の態様又は第２の態様で提供される方法を実施することを可能にするように構成されたプロセッサを含む。ネットワークデバイスは、メモリをさらに含むことができる。メモリはプロセッサに結合される。プロセッサがメモリに記憶された命令を実行したとき、ネットワークデバイスは、第１の態様又は第２の態様で提供される方法を実施することを可能にされる。ネットワークデバイスは、通信インターフェースをさらに含むことができる。通信インターフェースは、別のデバイスと通信するためにネットワークデバイスにより使用される。例えば、通信インターフェースは、トランシーバ、回路、バス、モジュール、又は別のタイプの通信インターフェースでもよい。本出願において、メモリ内の命令は、予め記憶されていてもよく、あるいはネットワークデバイスが使用されるときにインターネットからダウンロードされ、記憶されてもよい。メモリ内の命令のソースは、本出願において具体的に限定されない。

【0070】

第６の態様によれば、本出願は、ネットワークシステムをさらに提供し、ネットワークシステムは、第１のネットワークデバイスと第２のネットワークデバイスを含む。第１のネットワークデバイスは、第１の態様で提供される方法を実行するように構成され、第２のネットワークデバイスは、第２の態様で提供される方法を実行するように構成される。

【0071】

第７の態様によれば、本出願は、プロセッサとインターフェース回路とを含むチップを提供する。インターフェース回路は、命令を受信し、命令をプロセッサに送信するように構成され、プロセッサは、第１の態様又は第２の態様で提供される方法に対応する命令を実行するように構成される。

【0072】

第８の態様によれば、本出願は、コンピュータ読取可能記憶媒体を提供する。コンピュータ読取可能記憶媒体は、プログラムコード又は命令を記憶する。プログラムコード又は命令がコンピュータ上で実行されたとき、コンピュータは、第１の態様又は第２の態様で提供される方法を実行することを可能にされる。

【0073】

第９の態様によれば、本出願は、コンピュータプログラムを含むコンピュータプログラム製品を提供する。コンピュータプログラムがプロセッサにより実行されたとき、第１の態様又は第２の態様で提供される方法が実施される。

【図面の簡単な説明】

【0074】

【図1】本出願の一実施形態によるネットワークシステム１０の構造の概略図である。

【図2】本出願の一実施形態によるサービスパス検出を実施する方法１００のフローチャートである。

【図3a】本出願の一実施形態によるパケット１のフォーマットの概略図である。

【図3b】本出願の一実施形態による別のパケット１のフォーマットの概略図である。

【図3c】本出願の一実施形態による、図３ａに対応するパケット２のフォーマットの概略図である。

【図3d】本出願の一実施形態による、図３ｂに対応するパケット２のフォーマットの概略図である。

【図4a】本出願の一実施形態によるパケット１のフォーマットの概略図である。

【図4b】本出願の一実施形態による別のパケット１のフォーマットの概略図である。

【図4c】本出願の一実施形態による、図４ａに対応するパケット２のフォーマットの概略図である。

【図4d】本出願の一実施形態による、図４ｂに対応するパケット２のフォーマットの概略図である。

【図5a】本出願の一実施形態による、パケット１のフォーマットの概略図である。

【図5b】本出願の一実施形態による、図５ａに対応するパケット２のフォーマットの概略図である。

【図6a】本出願の一実施形態による、パケット１のフォーマットの概略図である。

【図6b】本出願の一実施形態による、別のパケット１のフォーマットの概略図である。

【図6c】本出願の一実施形態による、図６ａに対応するパケット２のフォーマットの概略図である。

【図6d】本出願の一実施形態による、図６ｂに対応するパケット２のフォーマットの概略図である。

【図7】本出願の一実施形態によるサービスパス検出を実施する装置７００の構造の概略図である。

【図8】本出願の一実施形態によるサービスパス検出を実施する装置８００の構造の概略図である。

【図9】本出願の一実施形態によるネットワークデバイス９００の構造の概略図である。

【図10】本出願の一実施形態によるネットワークデバイス１０００の構造の概略図である。

【図11】本出願の一実施形態によるネットワークシステム１１００の構造の概略図である。

【発明を実施するための形態】

【0075】

現在、ＳＲｖ６ネットワークでは、トンネルレベルの障害検出のみを実行することができ、したがって、トンネルレベルの切り替えは、トンネル内で障害が検出されたときにのみ実行することができる。例えば、図１に示すネットワークシステム１０は、ＰＥデバイス１１、ＰＥデバイス１２、ＰＥデバイス１３、カスタマエッジ（customer edge、ＣＥ）デバイス２１、ＣＥデバイス２２、プロバイダ（provider、Ｐ）デバイス３１、Ｐデバイス３２、及びＰデバイス３３を含むことができる。ＰＥデバイス１１は、ＣＥデバイス２１に接続され、ＰＥデバイス１１は、Ｐデバイス３１を介してＰＥデバイス１２に接続され、ＰＥデバイス１１は、Ｐデバイス３２及びＰデバイス３３を介してＰＥデバイス１３に接続され、ＰＥデバイス１２及びＰＥデバイス１３は、ＣＥデバイス２２に接続されている。ＰＥデバイス１１とＰＥデバイス１２との間にトンネル１があり、ＰＥデバイス１１とＰＥデバイス１３との間にトンネル２があり、トンネル１がサービス１とサービス２を運ぶと仮定する。ＰＥデバイス１１は、トンネル検出パケットを使用することにより、トンネル１で障害が発生していることを検出し、トンネル１で運ばれているサービス１とサービス２の双方をトンネル２に切り替えることができる。換言すれば、切り替えの後、サービス１のトラフィックとサービス２のトラフィックの双方が、ＰＥデバイス１３によりＣＥデバイス２２に送信される。

【0076】

しかしながら、トンネルレベルの障害検出の粒度は、過度に粗い。ひとたび障害がサービスにより引き起こされ、トンネルで運ばれる別のサービスが正常に実行可能であると、この障害検出方法は、障害が発生しているパス内のサービスを正確に検出することができず、障害が発生しているサービス転送パスを正確に切り替えることができず、トンネルレベルのパス切り替えのみを実行することができる。結果として、カスタマＰＥデバイスは、トンネルで運ばれる全てのサービスに対するパス切り替えを実行し、換言すれば、トンネルで正常に実行されているサービスを運ぶためのパスも切り替えられる。結果的に、ネットワークリソースが浪費される。さらに、別のパス検出シナリオでは、サービスレベル検出は、サービスを運ぶためのパスの品質を把握し、より良いサービスをさらに提供するために、パス品質に対して実行される必要がある。

【0077】

これに基づいて、本出願の実施形態は、サービスパス検出を実施する方法を提供する。第１のネットワークデバイスは、インターネットプロトコルバージョン６（internet protocol version 6、ＩＰｖ６）に基づいて、第１の指示とサービスの識別情報とを含む第１のパケットを生成し、第１のパケットを第２のネットワークデバイスに送信することができる。第１の指示は、第１のパケットが検出パケットであることを示し、サービスの識別情報はサービスを示す。このようにして、第１のパケットを受信する第２のネットワークデバイスは、第１のパケット内の第１の指示に基づいて、第１のパケットが検出パケットであると判断し、第１のパケット内のサービスの識別情報に基づいて、サービスを運ぶためのパスを検出すること、例えば、サービスを運ぶためのパスの障害及び／又は品質を検出することを判断することができる。本出願の実施形態で提供される方法によれば、送信者ネットワークデバイスは、送信される検出パケットに指示とサービスの識別情報を追加し、それにより、受信者ネットワークデバイスは、受信したパケットが検出パケットであることを正確に判断し、対応するサービスを認識して、検出パケットに基づいて、サービスを運ぶためのパスを検出することができることを習得できる。これは、粗い粒度が要件を満たすことができず、ネットワークリソースが浪費されるという問題を解決する。これらの問題は、現在、ネットワークデバイス間のトンネルレベルの検出のみが実施可能であるため、引き起こされている。このようにして、パス品質に対するサービスレベル検出を実行するための要件も満たされ、より細かい粒度及びより正確なサービスレベルのパス検出が実施され、サービスレベルのパス切り替えに対して正確な基盤が提供され、ネットワークにおけるサービスの正常な実行が保証される。

【0078】

図１に示すネットワークシステム１０をなお一例として用いる。本出願の実施形態で提供されるパス検出プロセスは、例えば以下のステップを含むことができる。Ｓ１１：ＰＥデバイス１１が、ＩＰｖ６に基づいてパケット４１を生成し、パケット４１は、指示５１とサービス１の識別情報とを含み、指示５１は、パケット４１が検出パケットであることを示し、サービス１の識別情報は、サービス１を識別するために使用される。この場合、パケット４１は、受信者デバイスに、サービス１を運ぶためのパスを検出するように指示する。Ｓ１２：ＰＥデバイス１１が、Ｐデバイス３１を介してパケット４１をＰＥデバイス１２に送信する。Ｓ１３：パケット４１を受信した後、ＰＥデバイス１２が、指示５１に基づいて、受信したパケットが検出パケットであると判断し、パケット４１内のサービス１の識別情報に基づいて、サービス１を運ぶパスを検出することができる。一ケースにおいて、以下のＳ１４ａとＳ１５ａが実行されてもよく、別のケースにおいて、以下のＳ１４ｂとＳ１５ｂが実行されてもよい。Ｓ１４ａ：ＰＥデバイス１２が、サービス１を運ぶためのパスは障害があると判断した場合、ＰＥデバイス１２は、パケット４１に応答しない。Ｓ１５ａ：ＰＥデバイス１１が、パケット４１に対する応答パケットを予め設定された期間（例えば、１秒）内に受信しない場合、ＰＥデバイス１１は、ＰＥデバイス１１とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスは障害があると判断する。Ｓ１４ｂ：ＰＥデバイス１２が、サービス１を運ぶためのパスの状態を判断し、パケット４１に対する応答パケットをＰＥデバイス１１に送信し、応答パケットは、サービス１を運ぶためのパスの判断された状態を含むことができる。パス状態は、ＰＥデバイス１２とアクセス側ネットワークデバイス（例えば、ＣＥデバイス２２）との間にあり、かつサービス１を運ぶためのパスのパス品質及び／又はパス接続性を含んでもよい。パス状態は、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパスのパス品質及び／又はパス接続性をさらに含んでもよい。Ｓ１５ｂ：ＰＥデバイス１１が、応答パケットに基づいて、ＰＥデバイス１１とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスのパス状態を判断する。次いで、以下のＳ１６がさらに実行されてもよい。具体的には、Ｓ１５ａに基づいて、ＰＥデバイス１１とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスは障害があると判断したとき、又は、Ｓ１５ｂに基づいて、パス状態が、ＰＥデバイス１１とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスは障害があること、又は、ＰＥデバイス１１とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスはパス品質要件を満たしていないことを示すと判断したとき、ＰＥデバイス１１は、サービス１を、ＰＥデバイス１３を含むパスに切り替える。切り替えの後、サービス１はＰＥデバイス１３により運ばれ、サービス２は依然としてＰＥデバイス１２により運ばれる。このようにして、より精巧なパス検出及び切り替えが実施され、リソース利用はより合理的である。

【0079】

一ケースにおいて、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービスを運ぶためのパスが到達可能であり、ＰＥデバイス１２が、ＰＥデバイス１１により送信された検出パケットを受信することができる場合、ＰＥデバイス１２は、サービス１を運ぶためのパスの取得されたパス状態を応答パケットに含め、応答パケットをＰＥデバイス１１に送信することができる。応答パケットで運ばれるパス状態は、ＰＥデバイス１２により取得された、ＰＥデバイス１２とアクセス側ネットワークデバイス（例えば、ＣＥデバイス２２）との間のパスの品質又は接続性の関連情報を含んでもよい。このようにして、ＰＥデバイス１１は、応答パケットに基づいて、ＰＥデバイス１２からアクセス側ネットワークデバイスまでの、サービス１を運ぶためのパス範囲が障害があるかどうか、又はパス品質が要件を満たしているかどうかを認識することができる。別のケースにおいて、ＰＥデバイス１１とＰＥデバイス１２との間のリンク又はデバイスが障害があり、ＰＥデバイス１２が障害があるとき、ＰＥデバイス１２は、パケット４１を受信しない場合がある。したがって、ＰＥデバイス１１は、ＰＥデバイス１２により送信された応答パケットを予め設定された期間内に受信せず、ＰＥデバイス１１とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスは障害があると判断することができる。別のケースにおいて、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパスは障害があると判断したとき、ＰＥデバイス１２は、代替的に、バックアップパスを使用することによりＰＥデバイス１１にパケットを能動的に送信して、ＰＥデバイス１１に、サービス１を運ぶためのパスは障害があることを通知し、ＰＥデバイス１１に、サービス１を運ぶためのパスの品質が要件を満たしていないことを通知し、あるいはＰＥデバイス１１に、サービス１を運ぶためのパス上の関連するインターフェース、デバイス、又はリンクの状態を通知してもよく、それにより、ＰＥデバイス１１は、ＰＥデバイス１２から受信した状態情報に基づいて、サービスを運ぶためのパスは障害があり又はパス品質要件を満たしていないかどうかを判断する。

【0080】

図１のネットワークシステム１０において、ＰＥデバイスは直接接続されてもよい。ＰＥデバイスは、代替的に、１つ以上の転送デバイス（forwarding devices）を介して間接的に接続されてもよく、転送デバイスは、これらに限られないがＰデバイスを含む。

【0081】

本出願の実施形態におけるネットワークデバイスは、サービスを運ぶ（carry）ことができるデバイス、例えば、ルータ、スイッチ、フォワーダ（forwarder）、又はファイアウォールであってよいことに留意されたい。

【0082】

本出願の各実施形態で提供される方法は、ＳＲｖ６ネットワーク又は別の必要な適用シナリオ、例えば、ＩＰｖ６プロトコルの実行をサポートする別の派生ネットワークに適用されてもよいことに留意されたい。

【0083】

本出願の各実施形態で言及されるサービスは、レイヤ２仮想プライベートネットワーク（layer 2 virtual private network、Ｌ２ＶＰＮ）サービスでもよいことに留意されたい。Ｌ２ＶＰＮサービスは、例えば、従来のＶＰＮ技術又はイーサネット仮想プライベートネットワーク（Ethernet virtual private network、ＥＶＰＮ）技術により運ばれるサービスを含んでもよい。Ｌ２ＶＰＮサービスでは、従来のＶＰＮサービスとＥＶＰＮサービスの双方が、仮想専用線（virtual leased line、ＶＬＬ）サービスモデル又は仮想プライベートローカルエリアネットワークサービス（virtual private LAN service、ＶＰＬＳ）モデルを使用することによりネットワークに配備される場合がある。ＶＬＬは、ポイント・ツー・ポイントサービスをサポートするために使用され、ＶＰＬＳは、ポイント・ツー・マルチポイントサービス又はマルチポイント・ツー・マルチポイントサービスをサポートするために使用される。図１に示すネットワークシステム１０を一例として用いる。図１に示すネットワークシステム１０が従来のＶＰＮネットワークである場合、ＶＬＬサービスモデルか又はＶＰＬＳサービスモデルに関係なく、ＰＥデバイス１１とＰＥデバイス１２との間の接続、及びＰＥデバイス１１とＰＥデバイス１３との間の接続は各々、擬似ワイヤ（pseudo wire、ＰＷ）と呼ばれることがある。図１に示すネットワークシステム１０がＥＶＰＮネットワークである場合、ＶＬＬサービスモデルでは、ＰＥデバイス１１とＰＥデバイス１２との間の接続、及びＰＥデバイス１１とＰＥデバイス１３との間の接続は各々、仮想プライベートワイヤサービス（virtual private wire service、ＶＰＷＳ）ネイバー（neighbor）と呼ばれることがある。従来のＶＰＮネットワークとＥＶＰＮネットワークは、同じサービスタイプを運ぶことがある。ＥＶＰＮネットワークは、ボーダーゲートウェイプロトコル（border gateway protocol、ＢＧＰ）を使用することにより実装でき、従来のＶＰＮネットワークは、ラベル配布プロトコル（label distribution protocol、ＬＤＰ）及びＢＧＰなどの複数のプロトコルのうちの少なくとも１つを使用することにより実装できる。

【0084】

本出願の各実施形態で言及される検出パケットは、サービスを運ぶためのパスの接続性又はサービスを運ぶためのパスの品質（例えば、パス上の遅延及びパケット損失などの指標）を検出するために使用され得ることに留意されたい。検出パケットは、例えば、双方向転送検出（bidirectional forwarding detection、ＢＦＤ）パケット又は運用管理及び保守（operation administration and maintenance、ＯＡＭ）パケットなどでもよい。検出パケットがＢＦＤパケットであるとき、本出願の実施形態で提供される方法は、例えば、静的ＢＦＤ検出、動的ＢＦＤ検出、又はシームレス双方向転送検出（seamless bidirectional forwarding detection、ＳＢＦＤ）をサポートすることができる。サービスを運ぶためのパスの検出される状態は、パスの接続性又は品質を参照する場合がある。検出パケットがＯＡＭパケットであるとき、本出願の実施形態で提供される方法は、例えば、接続障害管理（connectivity fault management、ＣＦＭ）検出又はＹ．１７３１検出をサポートすることができる。検出パケットの特定のタイプとサポートされる検出タイプは、本出願の実施形態の実装に影響しない。

【0085】

本出願の実施形態で提供されるネットワーク障害検出方法の理解を容易にするため、以下では、添付の図面を参照して方法を説明する。

【0086】

図２は、本出願の一実施形態によるサービスパス検出を実施する方法１００の概略フローチャートである。方法１００は、第１のネットワークデバイスと第２のネットワークデバイスを含むネットワークシナリオに適用することができる。一例において、第１のネットワークデバイスは、検出すべきターゲットサービスを運ぶトンネルイングレスＰＥデバイスでもよく、第２のネットワークデバイスは、ターゲットサービスを運ぶトンネルエグレスＰＥデバイスでもよい。理解を容易にするため、図１に示すネットワークシステム１０の構造を一例として用いる。ＰＥデバイス１１とＰＥデバイス１２との間の相互作用を説明に用いる。検出すべきターゲットサービスは、ＰＥデバイス１１及びＰＥデバイス１２で運ばれるサービス１である。特定の実装の間、方法１００は、例えば以下のＳ１０１～Ｓ１０４を含むことができる。

【0087】

Ｓ１０１：ＰＥデバイス１１が、ＩＰｖ６に基づいてパケット４１を生成し、パケット４１は、指示５１とサービス１の識別情報を含み、指示５１は、パケット４１が検出パケットであることを示す。

【0088】

特定の実装の間、ＳＲｖ６ネットワークにおいて、ＰＥデバイス１１は、ＩＰｖ６に基づいて検出パケットをカプセル化して、パケット４１を得ることができる。パケット４１は、ＩＰｖ６に基づいてカプセル化された検出パケットと呼ばれることもある。例えば、検出パケットがＢＦＤパケットであると仮定すると、Ｓ１０１におけるパケット４１は、ＩＰｖ６に基づいてカプセル化されたＢＦＤパケットと呼ばれることがあり、カプセル化の前のＢＦＤパケットは、カプセル化を通じて得られたパケット４１内の検出情報に対応する。

【0089】

サービス１の識別情報は、パケット４１のＩＰｖ６ヘッダ１で運ばれる場合があり、あるいはＩＰｖ６拡張ヘッダ１’で運ばれる場合があり、サービス１を識別するために使用される。例えば、サービス１の識別情報は、サービスを識別するためにＰＥデバイス１２により割り振られたＶＰＮＳＩＤでもよい。

【0090】

指示５１は、パケット４１のＩＰｖ６ヘッダ１で運ばれる場合があり、あるいは指示５１は、ＩＰｖ６拡張ヘッダ１’で運ばれる場合がある。以下では、例を用いることにより、様々なケースにおけるパケット４１で運ばれる指示５１の位置について説明する。

【0091】

一例において、ＳＲｖ６ベストエフォート（best effort、ＢＥ）シナリオでは、指示５１は、ＩＰｖ６ヘッダ１内のネクストヘッダ（next header）フィールドで運ばれる場合がある。例えば、パケット４１のＩＰｖ６ヘッダ１内のネクストヘッダフィールドが１３７に等しい場合、それは、パケット４１が検出パケットであることを示す。この例において、パケット４１は、ＩＰｖ６拡張ヘッダ１’をさらに含んでもよい。ＩＰｖ６拡張ヘッダ１’は、アラートラベル（alert label）と制御ワードを含むことができる。アラートラベルと制御ワードは、パケット４１のペイロード（payload）が検出情報を運ぶことを示す。検出情報は、ＰＥデバイス１２に、検出情報に基づいて、サービス１を運ぶためのパス上で障害検出又は品質検出を実行するように指示する。アラートラベルと制御ワードが検出情報を示すことは、アラートラベルと制御ワードとの値に基づいて、その後に運ばれる内容が検出情報であると判断すること、又は、アラートラベルと制御ワードとの値に基づいて、その後に運ばれる内容が検出情報であると判断し、検出情報のタイプを判断することでもよい。例えば、アラートラベル１３と制御ワードに基づいて、その後に運ばれる内容が検出情報であり、検出情報のタイプがＢＦＤ情報であることが判断されてもよい。さらに、指示５１は、代替的に、ＩＰｖ６ヘッダ１内のネクストヘッダフィールドと、ＩＰｖ６拡張ヘッダ１’内にあるアラートラベル及び制御ワードで運ばれると考えられてもよい。ＩＰｖ６ヘッダ１内のネクストヘッダフィールド、ＩＰｖ６拡張ヘッダ１’内のアラートラベル、及びＩＰｖ６拡張ヘッダ１’内の制御ワードは連帯的に、パケット４１が検出パケットであることを示す。図３ａに、パケット４１のフォーマットの概略図を示す。パケット４１は、ＩＰｖ６ヘッダ１とＩＰｖ６拡張ヘッダ１’を含むことができる。ＩＰｖ６ヘッダ１は、ソースアドレス（source address、ＳＡ）フィールド、宛先アドレス（destination address、ＤＡ）フィールド、及びネクストヘッダフィールドを含むことができる。ＳＡフィールドの値は、ＰＥデバイス１１のアドレスであり、例えば、ＰＥデバイス１１のループバック（loopback）アドレス１：：１に等しい。ＤＡフィールドの値は、ＰＥデバイス１２のＶＰＮセグメント識別子（segment identifier、ＳＩＤ）であり、例えば、ＰＥデバイス１２のＥｎｄ．ＤＸ２Ａ３：：１５００：０に等しい。ネクストヘッダフィールドの値は、１３７でもよい。ＩＰｖ６拡張ヘッダ１’は、アラートラベルと制御ワードを含んでもよい。パケット４１のペイロードは、インターネットプロトコル（internet protocol、ＩＰ）、ユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）、及び検出情報を含むことができる。アラートラベルが１３に等しいとき、検出情報はＢＦＤ情報である。

【0092】

別の例において、ＳＲｖ６ポリシー（policy）シナリオでは、指示５１は、ＩＰｖ６拡張ヘッダ１のセグメントルーティングヘッダ（segment routing header、ＳＲＨ）内のネクストヘッダフィールドで運ばれる場合がある。例えば、パケット４１のＩＰｖ６拡張ヘッダ１’内のネクストヘッダフィールドが１３７に等しい場合、それは、パケット４１が検出パケットであることを示す。この例において、ＩＰｖ６拡張ヘッダ１’は、アラートラベル、制御ワード、及び検出情報をさらに含むことができる。アラートラベルと制御ワードは、パケット４１のペイロード内の検出情報を示す。検出情報は、ＰＥデバイス１２に、検出情報に基づいて、サービス１を運ぶためのパス上の障害検出を実行するように指示する。さらに、指示５１は、代替的に、ＩＰｖ６拡張ヘッダ１’のＳＲＨ内のネクストヘッダフィールド、アラートラベル、及び制御ワードで運ばれると考えられてもよく、その３つは連帯的に、パケット４１が検出パケットであることを示す。図３ｂに、パケット４１のフォーマットの概略図を示す。パケット４１は、ＩＰｖ６ヘッダ１とＩＰｖ６拡張ヘッダ１’を含むことができる。ＩＰｖ６ヘッダ１は、ＳＡフィールドとＤＡフィールドを含むことができる。ＩＰｖ６拡張ヘッダ１’は、ネクストヘッダフィールド、アラートラベル、及び制御ワードを含むことができる。パケット４１のペイロードは、ＩＰ、ＵＤＰ、及び検出情報を含むことができる。ネクストヘッダフィールドが１３７に等しく、アラートラベルが１３に等しい場合、それは、検出情報がＢＦＤ情報であることを示す。

【0093】

さらに別の例において、ＳＲｖ６ＢＥシナリオでは、指示５１は、ＩＰｖ６ヘッダ１内のＤＡフィールドで運ばれる場合があり、例えば、ＩＰｖ６ヘッダ１内のＤＡフィールド内の引数（ａｒｇｓ）フィールドで運ばれる場合がある。例えば、パケット４１におけるＩＰｖ６ヘッダ１内のＤＡフィールド内のａｒｇｓフィールドが３に等しい場合、それは、パケット４１が検出パケットであることを示す。この例において、パケット４１のペイロードは検出情報を含むことができる。図４ａに、パケット４１のフォーマットの概略図を示す。パケット４１は、ＩＰｖ６ヘッダ１とペイロードを含むことができる。ＩＰｖ６ヘッダ１は、ＳＡフィールドとＤＡフィールドを含むことができる。ＳＡフィールドの値は、ＰＥデバイス１１のアドレスであり、例えば、ＰＥデバイス１１のループバックアドレス１：：１に等しい。ＤＡフィールドの値は、ＰＥデバイス１２のＶＰＮＳＩＤであり、例えば、Ｅｎｄ．ＤＸ２Ａ３：：１５００：３に等しい（換言すれば、ＤＡフィールド内のａｒｇｓフィールドは３に等しい）。ペイロードは検出情報を含み、検出情報はＢＦＤ情報であってよい。別の可能な方法において、ＶＰＮＳＩＤ内のａｒｇｓフィールドは、代替的に、別の値、例えば別の非０の正の整数に設定されてもよい。

【0094】

別の例において、ＳＲｖ６ポリシーシナリオでは、指示５１は、ＩＰｖ６拡張ヘッダ１’のＳＲＨ内のＤＡフィールドで運ばれる場合があり、例えば、ＩＰｖ６拡張ヘッダ１’内のＤＡフィールド内のａｒｇｓフィールドで運ばれる場合がある。例えば、パケット４１におけるＩＰｖ６拡張ヘッダ１’内のＤＡフィールド内のａｒｇｓフィールドが３に等しい場合、それは、パケット４１が検出パケットであることを示す。この例において、パケット４１のペイロードは検出情報を含むことができる。図４ｂに、パケット４１のフォーマットの概略図を示す。パケット４１は、ＩＰｖ６ヘッダ１、ＩＰｖ６拡張ヘッダ１’、及びペイロードを含むことができる。ＩＰｖ６ヘッダ１は、ＳＡフィールドとＤＡフィールドを含むことができる。ＳＡフィールドの値は、ＰＥデバイス１１のアドレスであり、例えば、ＰＥデバイス１１のループバックアドレス１：：１に等しい。ＤＡフィールドの値は、ＰＥデバイス１２のＶＰＮＳＩＤであり、例えば、ＰＥデバイス１２のＥｎｄ．ＤＸ２Ａ３：：１５００：３に等しい。ＩＰｖ６拡張ヘッダ１’は、ＳＲＨを含むことができる。ペイロードは、ＩＰ、ＵＤＰ、及び検出情報を含むことができる。ＳＲＨ内のＤＡフィールド内のａｒｇｓフィールドが３に等しい場合、検出情報はＢＦＤ情報であってよい。

【0095】

さらに別の例において、指示５１は、ＩＰｖ６拡張ヘッダ１’のＳＲＨ内のフラグ（ｆｌａｇｓ）フィールドで運ばれる場合がある。例えば、パケット４１におけるＩＰｖ６拡張ヘッダ１’のＳＲＨ内のフラグが１に等しい場合、それは、パケット４１が検出パケットであることを示す。指示５１を運ぶフラグは、未定義のｆｌａｇｓフィールド内の任意のビットでもよく、あるいはｆｌａｇｓ内の占有されたＯ－ｆｌａｇフラグビットを再利用することにより表されてもよい。この例において、パケット４１のペイロードは検出情報を含むことができる。図５ａに、パケット４１のフォーマットの概略図を示す。パケット４１は、ＩＰｖ６ヘッダ１、ＩＰｖ６拡張ヘッダ１’、及びペイロードを含むことができる。ＩＰｖ６ヘッダ１は、ＳＡフィールドとＤＡフィールドを含むことができる。ＩＰｖ６拡張ヘッダ１’は、ＳＲＨを含むことができる。ペイロードは、ＩＰ、ＵＤＰ、及び検出情報を含むことができる。ＳＲＨ内のｆｌａｇｓ内のビットの値は１でもよく、検出情報はＢＦＤ情報であってよい。

【0096】

さらに別の例において、一ケースでは、指示５１は、ＩＰｖ６拡張ヘッダ１’のホップバイホップ（hop-by-hop、ＨＢＨ）オプションヘッダ内のタイプ・レングス・値（type-length-value、ＴＬＶ）フィールドで運ばれる場合がある。ＩＰｖ６拡張ヘッダ１’のＨＢＨオプションヘッダは、パケット４１が検出パケットであることを示すＴＬＶフィールドを含む。パケット４１のペイロードは、検出情報を含むことができる。図６ａに、パケット４１のフォーマットの概略図を示す。パケット４１は、ＩＰｖ６ヘッダ１、ＩＰｖ６拡張ヘッダ１’、及びペイロードを含むことができる。ＩＰｖ６ヘッダ１は、ＳＡフィールドとＤＡフィールドを含むことができる。ＩＰｖ６拡張ヘッダ１’は、ＨＢＨオプションヘッダを含むことができる。ペイロードは、ＩＰ、ＵＤＰ、及び検出情報を含むことができる。ＨＢＨオプションヘッダはＴＬＶフィールドを含み、検出情報はＢＦＤ情報であってよい。別のケースでは、指示５１は、代替的に、ＩＰｖ６拡張ヘッダ１’の宛先オプションヘッダ（destination option header、ＤＯＨ）内のＴＬＶフィールドで運ばれてもよく、ＩＰｖ６拡張ヘッダ１’のＤＯＨは、パケット４１が検出パケットであることを示すＴＬＶフィールドを含む。パケット４１のペイロードは、検出情報を含むことができる。図６ｂに、パケット４１のフォーマットの概略図を示す。パケット４１は、ＩＰｖ６ヘッダ１、ＩＰｖ６拡張ヘッダ１’、及びペイロードを含むことができる。ＩＰｖ６ヘッダ１は、ＳＡフィールドとＤＡフィールドを含むことができる。ＩＰｖ６拡張ヘッダ１’は、ＤＯＨを含むことができる。ペイロードは、ＩＰ、ＵＤＰ、及び検出情報を含むことができる。ＤＯＨはＴＬＶフィールドを含み、検出情報はＢＦＤ情報であってよい。

【0097】

前述の例では、パケット４１がＢＦＤパケットである一例を用いることにより説明を提供している。パケット４１がＯＡＭパケットである場合、指示５１とサービス１の識別情報を運ぶ方法については、前述の例の実装を参照する。この場合、パケット４１のペイロード内の検出情報はＯＡＭ情報であってよい。ＯＡＭ情報は、例えば、ＰＥデバイス１１によりＰＥデバイス１２に送信されたデータパケットの数量及びタイムスタンプを含んでもよい。

【0098】

パケット４１が指示５１を運ぶ前述の方法は全て例であり、パケット４１は任意の他の可能な方法で指示５１を運んでもよいことに留意されたい。

【0099】

Ｓ１０２：ＰＥデバイス１１が、パケット４１をＰＥデバイス１２に送信する。

【0100】

いくつかの可能な実装において、ＰＥデバイス１１がパケット４１をＰＥデバイス１２に送信するためのリンク又はデバイスが障害があり、パケット４１をＰＥデバイス１２に成功裏に送信できない場合、ＰＥデバイス１２は、ＰＥデバイス１１により送信されたパケット４１を受信できない。したがって、ＰＥデバイス１１は、ＰＥデバイス１２により送信された応答パケットを予め設定された期間内に受信せず、ＰＥデバイス１１とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスは障害があると判断することができる。ＰＥデバイス１２がパケット４１を成功裏に受信できないことに対応する障害の内容は、ＰＥデバイス１１とＰデバイス３１との間のリンクが障害がある、Ｐデバイス３１とＰＥデバイス１２との間のリンクが障害がある、Ｐデバイス３１が障害がある、又はＰＥデバイス１２が障害があることを含んでもよい。

【0101】

他のいくつかの可能な実装において、ＰＥデバイス１２は、パケット４１を成功裏に受信することができる。換言すれば、Ｓ１０２の後、Ｓ１０３とＳ１０４がさらに方法１００に含まれる。この場合、検出は、方法１００に従って実施されてもよい。関連する実装については、以下の説明を参照する。

【0102】

Ｓ１０３：ＰＥデバイス１２が、ＰＥデバイス１１により送信されたパケット４１を受信する。

【0103】

特定の実装の間、サービス１を運ぶためのパスを検出することに対する要件があるとき、Ｓ１０２及びＳ１０３を実行して、対応する検出を実施してもよい。代替的に、サービスを運ぶためのパスは周期的に検出されてもよく、具体的には、Ｓ１０２及びＳ１０３を各周期で実行して、対応する検出を実施し、検出周期は、実際の要件に基づいて柔軟に設定されてもよい。

【0104】

Ｓ１０４：ＰＥデバイス１２が、指示５１とサービス１の識別情報とに基づいて、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパスと、ＰＥデバイス１２とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスとのうちの少なくとも１つを検出する。

【0105】

特定の実装の間、パケット４１を受信した後、ＰＥデバイス１２は、パケット４１内にある指示５１とサービス１の識別情報とに基づいて、サービス１を運ぶためのパスを検出することができる。１つの態様において、ＰＥデバイス１２は、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶために使用されるパスを検出し、例えば、ＰＥデバイス１２とＰデバイス３１との間のリンクが障害があるかどうかを検出し、別の例では、Ｐデバイス３１に接続するためにＰＥデバイス１２により使用されるインターフェースが障害があるかどうかを検出することができる。別の態様において、ＰＥデバイス１２は、代替的に、ＰＥデバイス１２とアクセス側ネットワークデバイス（例えば、ＣＥデバイス２２）との間にあり、かつサービス１を運ぶために使用されるパスを検出し、例えば、ＰＥデバイス１２とＣＥデバイス２２との間のリンクが障害があるかどうかを検出し、別の例では、ＣＥデバイス２２に接続するためにＰＥデバイス１２により使用されるインターフェースが障害があるかどうかを検出することができる。

【0106】

ＰＥデバイス１２が、サービス１を運ぶためのパスが障害がないこと又はパス品質が要件を満たしていることを検出した場合、ＰＥデバイス１２は、ＰＥデバイス１１に応答パケットを返すことができ、応答パケットは、サービス１を運ぶためのパスが正常であることをＰＥデバイス１１に通知するために使用される。

【0107】

ＰＥデバイス１２が、サービス１を運ぶパスは障害があること又はパス品質が要件を満たしていないことを検出した場合、ＰＥデバイス１２は、パケット４１に応答しない場合があり、あるいはＰＥデバイス１２は、障害が発生していること又はパス品質が要件を満たしていないことを通知するために使用される応答パケットをＰＥデバイス１１に送信することができる。

【0108】

一例において、ＰＥデバイス１２が、サービス１を運ぶためのパスは障害があるか又はパス品質が要件を満たしていないと判断したとき、例えば、ＰＥデバイス１２が、ＣＥデバイス２２に接続するために使用されるローカルインターフェースが障害がある、ＣＥデバイス２２に接続するためにＰＥデバイス１２により使用されるリンクが障害がある、又はＰＥデバイス１１に接続するためにＰＥデバイス１２により使用されるパスの品質が要件を満たしていない（例えば、遅延が予め設定された遅延閾値を超えている場合）と認識したとき、Ｓ１０４の後、この方法は、ＰＥデバイス１２がＰＥデバイス１１に応答パケットを送信することと、応答パケットを受信した後、ＰＥデバイス１１が、応答パケットに基づいて、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパスと、ＰＥデバイス１２とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスとのうちの少なくとも１つのパス状態を判断できることをさらに含んでもよい。パス状態は、対応するパスの接続性及び／又は品質を含む。応答パケットは、これらに限られないが、ＰＥデバイス１２のローカル状態情報、ＰＥデバイス１２とアクセス側ネットワークデバイスとの間のリンクの状態情報、及びアクセス側ネットワークデバイスに接続するためにＰＥデバイス１２により使用されるインターフェースの状態情報を含んでもよい。さらに、応答パケットは、ＰＥデバイス１２とＰＥデバイス１１との間のパスの状態情報、及びネットワーク側ネットワークデバイスに接続するためにＰＥデバイス１２により使用されるインターフェースの状態情報をさらに含んでもよい。ＰＥデバイス１１は、応答パケットに基づいて、サービス１を運ぶためのパスの品質と接続性を判断することができる。代替的に、ＰＥデバイス１１は、応答パケットに基づいて、サービス１を運ぶためのパス上の各パスセグメントの状態、例えば、リンク品質又は特定の障害位置をより正確に判断してもよい。例えば、ＰＥデバイス１１は、ＰＥデバイス１２とＰデバイス３１との間のリンクの状態、ＰＥデバイス１２とＣＥデバイス２２との間のリンクの状態、Ｐデバイス３１に接続するためにＰＥデバイス１２により使用されるインターフェースの状態、又はＣＥデバイス２２に接続するためにＰＥデバイス１２により使用するインターフェースの状態を判断することができる。

【0109】

あり得る一ケースにおいて、ＰＥデバイス１２全体が障害がある場合、ＰＥデバイス１２はもはやＰＥデバイス１１に応答パケットを送信できないことに留意されたい。別のあり得るケースにおいて、ＰＥデバイス１２が、ＰＥデバイス１２に関連づけられたパス上に障害があると判断した場合でも、ＰＥデバイス１２は、応答パケットを使用することにより障害の存在をＰＥデバイス１１に依然として通知することができる。例えば、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパス上に障害があると仮定すると、ＰＥデバイス１２は、別の到達可能なパスを選択してＰＥデバイス１１に応答パケットを送信して、サービス１を運ぶために使用されるパスは障害があることをＰＥデバイス１１に通知することができる。

【0110】

別の例において、ＰＥデバイス１２が、サービス１を運ぶためのパスは障害があるか又はパス品質が要件を満たしていないと判断したとき、ＰＥデバイス１２は、応答パケットを送信しない場合があり、これは具体的に、これらに限られないが、検出メカニズムにおいて障害があると判断されたときに応答パケットが送信されないこと、又は、ＰＥデバイス１２とＰデバイス３１との間のリンク上の障害、Ｐデバイス３１に接続するためにＰＥデバイス１２により使用されるインターフェース上の障害、又は別の理由に起因して応答パケットを送信できないことを含んでもよい。ＰＥデバイス１１に、予め設定された期間（例えば、１秒）が設定されてもよく、予め設定された期間は、ＰＥデバイス１１により予め設定され、かつ検出パケットを送信した後に応答パケットを受信するのを待機するための最大許容可能時間でもよい。この場合、パケット４１の送信から開始した予め設定された期間の後、ＰＥデバイス１１は、パケット４１に対するＰＥデバイス１２により送信された応答パケットを依然として受信せず、ＰＥデバイス１１は、ＰＥデバイス１１とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスは障害があり、又はパス品質が要件を満たしていないと判断することができる。サービス１を運ぶためのパスが障害があるケースは、これらに限られないが、ＰＥデバイス１２が障害がある、Ｐデバイス３１が障害がある、ＣＥデバイス２２が障害がある、ＰＥデバイス１１とＰデバイス３１との間のリンクが障害がある、Ｐデバイス３１とＰＥデバイス１２との間のリンクが障害がある、ＰＥデバイス１２とＣＥデバイス２２との間のリンクが障害がある、ＰＥデバイス１１とＰデバイス３１との間のインターフェースが障害がある、Ｐデバイス３１とＰＥデバイス１２との間のインターフェースが障害がある、ＰＥデバイス１２とＣＥデバイス２２との間のインターフェースが障害がある、又は、ＰＥデバイス１２に接続されたカスタマネットワーク内のデバイス、リンク、又はインターフェースが障害があることを含んでもよい。

【0111】

可能な一実装において、パケット４１がＢＦＤパケットである場合、ＰＥデバイス１１は、ＢＦＤパケットをＰＥデバイス１２に送信して、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパスが障害があるかどうかを認識するだけでなく、ＢＦＤパケット内のサービス１の識別情報に基づいて、ＰＥデバイス１２とアクセス側ネットワークデバイス（例えば、ＣＥデバイス２２）との間にあり、かつサービス１を運ぶためのパスが障害があるかどうかも認識する。このようにして、ＰＥデバイス１１は、ＢＦＤパケットを使用することにより、サービス１を運ぶためのパス全体の接続性を認識して、サービスレベルの接続性検出の効果を達成することができる。

【0112】

別の可能な実装において、パケット４１がＯＡＭパケットである場合、ＰＥデバイス１１は、ＯＡＭパケットをＰＥデバイス１２に送信して、サービス１を運ぶためのパスの接続性及び品質を検出する。一例として、パス品質検出を用いる。一ケースにおいて、例えば、ＯＡＭパケットがパス品質検出を実現するプロセスは、ＰＥデバイス１１がＯＡＭパケットをＰＥデバイス１２に送信して、ＰＥデバイス１１により送信されたサービスデータパケットの統計情報（例えば、送信されたデータパケットの数量及びタイムスタンプなどの情報）を通知することを含んでもよい。ＰＥデバイス１２は、ＯＡＭパケットで運ばれるＶＰＮＳＩＤに基づいて、検出すべきＶＰＮに対応するサービス１を決定して、デバイスにおいてＰＥデバイス１２により取得され、かつ検出すべきサービス１に対応する受信したデータパケットの統計結果と、受信したＯＡＭパケット内の統計情報とを処理し、検出すべきサービス１を運ぶためのパスに対応する品質検出結果を得ることができる。次いで、ＰＥデバイス１２は、検出結果を運ぶＯＡＭ応答パケットを生成し、このパケットをＰＥデバイス１１に送信して、ＰＥデバイス１１に、受信したＯＡＭ応答パケットから、検出すべきサービス１を運ぶためのパスの品質検出結果を得て、検出すべきサービスを運ぶためのパスの品質を判断するように指示することができる。別のケースにおいて、例えば、ＯＡＭパケットがパス品質検出を実現するプロセスは、代替的に、ＰＥデバイス１１がＯＡＭパケットをＰＥデバイス１２に送信して、送信されたサービスデータパケットの統計情報をＰＥデバイス１２に通知することを含んでもよい。ＰＥデバイス１２は、ＯＡＭパケットで運ばれるＶＰＮＳＩＤに基づいて、検出すべきＶＰＮに対応するサービス１を決定し、ＰＥデバイス１２により取得され、かつ検出すべきサービス１に対応する受信したデータパケットの統計結果を、応答に使用されるＯＡＭパケットに含め、このパケットをＰＥデバイス１１に送信することができる。このようにして、ＰＥデバイス１１は、受信した応答ＯＡＭパケットに基づいて処理を実行し、検出すべきサービス１を運ぶためのパスの品質検出結果を得て、検出すべきサービス１を運ぶためのパスの品質を判断する。前述の２つのケースでは、一例として一方向検出を用いている。別のあり得るケースにおいて、ＰＥデバイス１１とＰＥデバイス１２は、代替的に、サービスを運ぶためのパス上で双方向検出を実行することができる。例えば、ＰＥデバイス１１は、ＯＡＭパケットをＰＥデバイス１２に送信して、ＰＥデバイス１１により送信されたサービスデータパケットの統計情報を通知し、ＰＥデバイス１２により送信された応答パケットを受信する。応答パケットは、ＰＥデバイス１１に、サービスの双方向パスデータパケットに対する統計を収集するように指示することができ、応答パケットは、リターンパス上のサービスのデータパケットに対する統計の収集に関する統計情報をさらに運ぶことができる。ＰＥデバイス１１は、応答パケットに基づいて、サービスのデータパケットに対する双方向パス品質検出結果を判断することができる。このようにして、ＯＡＭパケットは検出パケットとして使用される。ＰＥデバイス１１により受信される応答パケットは、以下の３つ、すなわち、サービス１を運ぶためのパスの接続性検出結果（具体的には、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパスと、ＰＥデバイス１２とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスとのうちの少なくとも１つが障害があるかどうか）、サービス１を運ぶためのパスのパス品質検出結果（具体的には、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパスと、ＰＥデバイス１２とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスとのうちの少なくとも１つのパスの品質が要件を満たしているかどうか）、及びサービス１を運ぶためのパスのパス品質の統計結果（具体的には、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパスと、ＰＥデバイス１２とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスとのうちの少なくとも１つのパス品質パラメータであり、ＰＥデバイス１１は、パス品質パラメータを処理して、パス品質が要件を満たしているかどうかを示すパス品質検出結果を得ることができる）のうちの、少なくとも１つを含むことができる。パス品質検出は、一方向パス上で品質検出を実行することを指す場合があり、あるいは双方向パス上で品質検出を実行することを指す場合がある。

【0113】

いくつかの可能な実装において、例えば、Ｓ１０４は、ＰＥデバイス１２が、パケット４１が検出パケットであると判断し、指示５１に基づいて実行される検出がローカルでサポートされていると判断した場合、ＰＥデバイス１２が、ローカル障害検出ポリシーに従って、サービス１を運ぶためのパス上の障害検出を実行することを含んでもよい。ローカル障害検出ポリシーに従って、パケット４１が対応する検出プロセスに送信されてもよく、対応する検出プロセスで障害検出が実行される。例えば、パケット４１がＢＦＤ検出パケットであると仮定すると、ＢＦＤ検出がローカルでサポートされていると判断したとき、ＰＥデバイス１２は、ＢＦＤ検出パケット内のサービス関連の内容及び検出情報をローカルＢＦＤプロセスに送信して、ＢＦＤプロセスを使用することにより対応する障害検出を実行する。別の例として、パケット４１がＯＡＭ検出パケットであると仮定すると、ＯＡＭ検出がローカルでサポートされていると判断したとき、ＰＥデバイス１２は、ＯＡＭ検出パケット内のサービス関連の内容及び検出情報をローカルＯＡＭインスタンスに送信して、ＯＡＭインスタンスで対応する検出を実行する。

【0114】

指示５１に基づいて実行される検出がローカルでサポートされていることは、指示５１により示される検出の対応する検出機能がＰＥデバイスのローカル構成を通じて有効にされていることを意味する場合がある。サービス１は、例えば、従来のＶＰＮサービス１又はＥＶＰＮサービス１でもよい。あり得る一ケースにおいて、検出パケットが、トンネル情報を示すＳＲＨを含む場合、検出プロセスに送信される内容は、検出パケットからＳＲＨが除去された内容であってよい。

【0115】

一例において、パケット４１が図５ａに示されている場合、パケット４１内のＤＡフィールドがローカルＶＰＮＳＩＤと一致すると判断した後、ＰＥデバイス１２は、パケット４１内の指示５１に基づいて、パケット４１が検出パケットであると判断し、ＰＥデバイス１２が指示５１に基づいて実行される検出をローカルでサポートしており、ＰＥデバイス１２がサービス１を認識することができるデバイスである（例えば、ＰＥデバイス１２はエグレスＰＥデバイスである）と判断することができる。この場合、パケット４１内のサービス関連の内容及び検出情報が対応する検出プロセスに送信されて、対応する検出プロセスで障害検出を実行する。

【0116】

別の例において、パケット４１が図６ａに示されている場合、パケット４１内のＩＰｖ６拡張ヘッダ１’のＨＢＨオプションヘッダが指示５１を運ぶためのＴＬＶフィールドを含むと判断した後、ＰＥデバイス１２は、パケット４１内の指示５１に基づいて、パケット４１が検出パケットであると判断し、指示５１に基づいて実行される検出がローカルでサポートされており、ＰＥデバイス１２がサービス１を認識することができるデバイスであると判断することができる。パケット４１内のサービス関連の内容及び検出情報が対応する検出プロセスに送信されて、対応する検出プロセスで障害検出を実行する。

【0117】

さらに別の例において、パケット４１が図６ｂに示されている場合、パケット４１内のＤＡフィールドがローカルＶＰＮＳＩＤと一致すると判断した後、ＰＥデバイス１２は、パケット４１内のＩＰｖ６拡張ヘッダ１’のＤＯＨが指示５１を運ぶためのＴＬＶフィールドを含むと判断し、パケット４１内の指示５１に基づいて、パケット４１が検出パケットであると判断し、指示５１に基づいて実行される検出がローカルでサポートされており、ＰＥデバイス１２がサービス１を認識することができるデバイスであると判断することができる。パケット４１内のサービス関連の内容及び検出情報が対応する検出プロセスに送信されて、対応する検出プロセスで障害検出を実行する。

【0118】

いくつかの可能な実装において、ＰＥデバイス１１はさらに、サービス１に対応するサービスパケットをＰＥデバイス１２に送信することができる。例えば、方法１００は、以下のステップをさらに含むことができる。Ｓ１０５：ＰＥデバイス１１が、パケット４２をＰＥデバイス１２に送信し、パケット４２は、サービス１を運ぶために使用されるサービスパケットであり、パケット４２は指示５１を含まない。

【0119】

一ケースにおいて、パケット２は、指示５１を運ぶためのフィールドを含まない。例えば、パケット４１は、ＩＰｖ６拡張ヘッダ１’のＨＢＨオプションヘッダ内のＴＬＶフィールドを使用することにより指示５１を運ぶ。この場合、対応するパケット４２は図６ｂに示されており、ＨＢＨオプションヘッダは対応するＴＬＶフィールドを含まない。別の例として、パケット４１は、ＩＰｖ６拡張ヘッダ１’のＤＯＨ内のＴＬＶフィールドを使用することにより指示５１を運ぶ。この場合、対応するパケット４２は図６ｄに示されており、ＤＯＨは対応するＴＬＶフィールドを含まない。

【0120】

別のケースにおいて、パケット４２は、指示５１を運ぶためのフィールドを含む。このフィールドは、パケット４２において指示５２を運ぶ。指示５２は、パケット４２がサービスパケットであることを示し、指示５２は、指示５１と異なる。一例において、パケット４２はＩＰｖ６ヘッダ２を含み、指示５２は、ＩＰｖ６ヘッダ２内のネクストヘッダフィールドで運ばれ、指示５１は、ＩＰｖ６ヘッダ１内のネクストヘッダフィールドの第１の値である。この場合、指示５２は、ＩＰｖ６ヘッダ２内のネクストヘッダフィールドの第２の値であり、第１の値は、第２の値と異なる。例えば、パケット４１におけるＩＰｖ６ヘッダ１内のネクストヘッダフィールドが１３７に等しい場合、対応するパケット４２は図３ｃに示されており、パケット４２におけるＩＰｖ６ヘッダ２内のネクストヘッダフィールドは１４３に等しい。別の例において、パケット４２はＩＰｖ６拡張ヘッダ２’を含み、指示５２は、ＩＰｖ６拡張ヘッダ２’のＳＲＨ内のネクストヘッダフィールドで運ばれ、指示５１は、ＩＰｖ６拡張ヘッダ１’のＳＲＨ内のネクストヘッダフィールドの第１の値である。この場合、指示５２は、ＩＰｖ６拡張ヘッダ２’のＳＲＨ内のネクストヘッダフィールドの第２の値であり、第１の値は、第２の値と異なる。例えば、パケット４１におけるＩＰｖ６拡張ヘッダ１’のＳＲＨ内のネクストヘッダフィールドが１３７に等しい場合、対応するパケット４２は図３ｄに示されており、パケット４２におけるＩＰｖ６拡張ヘッダ２’のＳＲＨ内のネクストヘッダフィールドは１４３に等しい。図３ｃ及び図３ｄの前述の例において、パケット４２内のネクストヘッダフィールドの値が全て１４３であることは一例として用いられている。実際の適用の間、図３ｃ及び図３ｄにおけるパケット４２内のネクストヘッダフィールドの値は、代替的に、異なってもよい。さらに別の例において、パケット４２はＩＰｖ６ヘッダ２を含み、指示５２は、ＩＰｖ６ヘッダ２におけるＤＡフィールド内のａｒｇｓフィールドで運ばれ、指示５１は、ＩＰｖ６ヘッダ１内のＤＡフィールド内のａｒｇｓフィールドの第３の値である。この場合、指示５２は、ＩＰｖ６ヘッダ２内のＤＡフィールド内のａｒｇｓフィールドの第４の値であり、第３の値は、第４の値と異なる。例えば、パケット４１におけるＩＰｖ６ヘッダ１内のＤＡフィールド内のａｒｇｓフィールドが３に等しい場合、対応するパケット４２は図４ｃに示されており、パケット４２におけるＩＰｖ６ヘッダ２内のＤＡフィールド内のａｒｇｓフィールドは０に等しい。さらに別の例において、パケット４２はＩＰｖ６拡張ヘッダ２’を含み、指示５２は、ＩＰｖ６拡張ヘッダ２’のＳＲＨ内のＤＡフィールド内のａｒｇｓフィールドで運ばれ、指示５１は、ＩＰｖ６拡張ヘッダ１’のＳＲＨ内のＤＡフィールド内のａｒｇｓフィールドの第３の値である。この場合、指示５２は、ＩＰｖ６拡張ヘッダ２’のＳＲＨ内のＤＡフィールド内のａｒｇｓフィールドの第４の値であり、第３の値は、第４の値と異なる。例えば、パケット４１におけるＩＰｖ６拡張ヘッダ１’のＳＲＨ内のＤＡフィールド内のａｒｇｓフィールドが３に等しい場合、対応するパケット４２は図４ｄに示されており、パケット４２におけるＩＰｖ６拡張ヘッダ２’のＳＲＨ内のＤＡフィールド内のａｒｇｓフィールドは０に等しい。図４ｃ及び図４ｄの前述の例において、パケット４２内のＤＡフィールドの値が全て０であることは一例として用いられている。実際の適用の間、図４ｃ及び図４ｄにおけるパケット４２内のａｒｇｓフィールドの値は、代替的に、異なってもよい。さらに別の例において、パケット４２はＩＰｖ６拡張ヘッダ２’を含み、指示５２は、ＩＰｖ６拡張ヘッダ２’のＳＲＨ内のｆｌａｇフィールドで運ばれ、指示５１は、ＩＰｖ６拡張ヘッダ１’のＳＲＨ内のｆｌａｇフィールドの第５の値である。この場合、指示５２は、ＩＰｖ６拡張ヘッダ２’のＳＲＨ内のｆｌａｇフィールドの第６の値であり、第５の値は、第６の値と異なる。例えば、パケット４１におけるＩＰｖ６拡張ヘッダ１’のＳＲＨ内のｆｌａｇフィールドが１に等しい場合、対応するパケット４２は図５ｂに示されており、パケット４２におけるＩＰｖ６拡張ヘッダ２’のＳＲＨのｆｌａｇフィールドは０に等しい。

【0121】

このようにして、受信者ＰＥデバイス１２は、受信したパケットを解析することにより、受信したパケットが検出パケットであるか又はサービスパケットであるかを識別して、対応する処理を実行することができる。例えば、ＰＥデバイス１２は、受信したパケット４１を解析することにより指示５１を取得し、指示５１に基づいて、パケット４１が検出パケットであると判断して、Ｓ１０４を実行する。別の例として、ＰＥデバイス１２は、パケット４２を解析することにより、指示５１を含まないパケット４２がサービスパケットであると判断して、サービスパケットの処理ルールに従ってサービスパケットを転送することなどの対応する動作を実行する。

【0122】

いくつかの可能な実装において、ＰＥデバイス１１が、ＰＥデバイス１１とＰＥデバイス１２との間にあり、かつサービス１を運ぶためのパスと、ＰＥデバイス１２とＣＥデバイス２２との間にあり、かつサービス１を運ぶためのパスとのうちの少なくとも１つが障害があると判断した後、サービスの正常な実行を保証するために、ＰＥデバイス１１は、代替的に、サービス１を運ぶために使用されるパスを、ＰＥデバイス１１からＰＥデバイス１３へのパスに切り替えることができ、ＰＥデバイス１３は、切り替えの後にサービス１を運ぶ。切り替えの前、サービス１に対応するサービスパケットは、連続的にＰＥデバイス１１、Ｐデバイス３１、及びＰＥデバイス１２を通じてＣＥデバイス２２に到達する。切り替えの後、サービス１に対応するサービスパケットは、連続的にＰＥデバイス１１、Ｐデバイス３２、Ｐデバイス３３、及びＰＥデバイス１３を通じてＣＥデバイス２２に到達する。しかしながら、切り替えの前か又は切り替えの後かに関係なく、サービス２に対応するサービスパケットは、連続的にＰＥデバイス１１、Ｐデバイス３１、及びＰＥデバイス１２を通じてＣＥデバイス２２に到達する。これは、トンネルレベルの障害検出において、障害が検出された後にトンネル上の全てのサービス（サービス１とサービス２を含む）が切り替えられ、切り替えの後にサービス１とサービス２の双方がＰＥデバイス１１、Ｐデバイス３１、及びＰＥデバイス１２を通じてＣＥデバイス２２に到達するため、ネットワークリソースが無駄にされるという問題を解決し、サービス制御の精度を向上させる。

【0123】

本出願のこの実施形態で提供される方法１００によれば、送信者ネットワークデバイスは、送信される検出パケットに指示とサービスの識別情報を追加し、それにより、受信者ネットワークデバイスは、受信したパケットが検出パケットであるか又はサービスパケットであるかを正確に区別することができることを習得できる。受信したパケットが検出パケットであると判断したとき、受信者ネットワークデバイスは、検出パケット内のサービスの識別情報に基づいて検出すべきサービスを決定し、さらに、検出すべきサービスを運ぶためのパスを検出して、より細かい粒度及びより正確なサービスレベルの障害検出を実施し、サービスレベルの切り替えに対する正確な基盤を提供し、ネットワークにおけるサービスの正常な実行を保証することができる。

【0124】

前述の方法の実施形態に基づき、本出願の一実施形態は、サービスパス検出を実施する装置を提供する。以下では、添付の図面を参照して装置について説明する。

【0125】

図７は、本出願の一実施形態によるサービスパス検出を実施する装置７００の構造の概略図である。装置７００は、第１のネットワークデバイスに適用され、例えば、図１に示す実施形態におけるＰＥデバイス１１の機能を実行することができる。装置７００は、生成ユニット７０１と送信ユニット７０２を含むことができる。

【0126】

生成ユニット７０１は、インターネットプロトコルバージョン６ＩＰｖ６に基づいて第１のパケットを生成するように構成され、第１のパケットは、第１の指示とサービスの識別情報を含み、第１の指示は、第１のパケットが検出パケットであることを示す。

【0127】

装置７００が図１に示すＰＥデバイス１１に適用されるとき、生成ユニット７０１により第１のパケットを生成することの具体的な実装については、図２に示す実施形態のＳ１０１を参照する。

【0128】

送信ユニット７０２は、第１のパケットを第２のネットワークデバイスに送信するように構成され、それにより、第１のパケットを受信する第２のネットワークデバイスは、第１の指示とサービスの識別情報とに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスとのうちの少なくとも１つを検出することができる。

【0129】

装置７００が図１に示すＰＥデバイス１１に適用されるとき、送信ユニット７０２により第１のパケットを送信することの具体的な実装については、図２に示す実施形態のＳ１０２を参照する。

【0130】

サービスの識別情報は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。

【0131】

第１の指示は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。

【0132】

一例において、第１のパケットは第１のＩＰｖ６ヘッダを含み、第１の指示は、第１のＩＰｖ６ヘッダ内のネクストヘッダｎｅｘｔｈｅａｄｅｒフィールドで運ばれ、あるいは、第１のパケットは第１のＩＰｖ６拡張ヘッダを含み、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のセグメントルーティングヘッダＳＲＨ内のネクストヘッダフィールドで運ばれる。第１のパケットの第１のＩＰｖ６拡張ヘッダは、アラートラベルと制御ワードをさらに含み、アラートラベルと制御ワードは、第１のパケットのペイロードｐａｙｌｏａｄ内の検出情報を示し、検出情報は、第２のネットワークデバイスに、検出情報に基づいて、サービスを運ぶパスを検出するように指示する。

【0133】

別の例において、第１のパケットは第１のＩＰｖ６ヘッダを含み、第１の指示、は第１のＩＰｖ６ヘッダ内の第１の宛先アドレスＤＡフィールド内の引数ａｒｇｓフィールドで運ばれ、あるいは、第１のパケットは第１のＩＰｖ６拡張ヘッダを含み、第１の指示は、第１のＩＰｖ６拡張ヘッダの第１のＳＲＨ内の第１のＤＡフィールド内のａｒｇｓフィールドで運ばれる。

【0134】

【0135】

【0136】

いくつかの可能な実装において、送信ユニット７０２はさらに、第２のパケットを第２のネットワークデバイスに送信するように構成され、第２のパケットは、サービスを運ぶために使用されるサービスパケットであり、第２のパケットは第１の指示を含まない。

【0137】

装置７００が図１に示すＰＥデバイス１１に適用されるとき、送信ユニット７０２により第２のパケットを送信することの具体的な実装については、図２に示す実施形態のＳ１０５を参照する。

【0138】

第２のパケットは、第２の指示をさらに含んでもよく、第２の指示は、第２のパケットがサービスパケットであることを示し、第２の指示は、第１の指示と異なる。

【0139】

【0140】

いくつかの可能な実装において、装置７００は、判断ユニットをさらに含んでもよい。判断ユニットは、第１のパケットに対する第２のネットワークデバイスの応答パケットが予め設定された期間内に受信されない場合、第１のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスは障害があると判断するように構成される。

【0141】

いくつかの可能な実装において、装置７００は、受信ユニットと判断ユニットをさらに含んでもよい。受信ユニットは、第１のパケットに対する第２のネットワークデバイスの応答パケットを受信するように構成され、判断ユニットは、応答パケットに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶために使用されるパスとのうちの少なくとも１つのパス状態を判断するように構成される。パス状態は、パス接続性とパス品質のうちの少なくとも１つを含む。

【0142】

いくつかの可能な実装において、装置７００は、切り替えユニットをさらに含んでもよい。切り替えユニットは、第１のパケットに対する第２のネットワークデバイスの応答パケットが予め設定された期間内に受信されないことに基づいて、サービスを運ぶために使用されるパスは障害があると判断し、あるいはパス状態に基づいて、サービスを運ぶために使用されるパスは障害があるか又はパス品質要件を満たしていないと判断したときに、サービスを運ぶために使用されるパスを第１のネットワークデバイスから第３のネットワークデバイスへのパスに切り替えるように構成され、第３のネットワークデバイスは、切り替えの後にサービスを運ぶ。

【0143】

サービスパス検出を実施する装置７００の具体的な実行可能機能及び実装については、図２に示す実施形態のＰＥデバイス１１の対応する説明を参照する。詳細はここで再度説明されない。

【0144】

さらに、本出願の一実施形態は、サービスパス検出を実施する装置８００をさらに提供する。図８に示すように、装置８００は、第２のネットワークデバイスに適用され、例えば、図１に示す実施形態におけるＰＥデバイス１２の機能を実行することができる。装置８００は、受信ユニット８０１と検出ユニット８０２を含むことができる。

【0145】

受信ユニット８０１は、第１のネットワークデバイスにより送信された第１のパケットを受信するように構成され、第１のパケットは、第１の指示とサービスの識別情報を含み、第１の指示は、第１のパケットが検出パケットであることを示す。

【0146】

装置８００が図１に示すＰＥデバイス１２に適用されるとき、受信ユニット８０１により第１のパケットを受信することの具体的な実装については、図２に示す実施形態のＳ１０３を参照する。

【0147】

検出ユニット８０２は、第１の指示とサービスの識別情報とに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶためのパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶためのパスとのうちの少なくとも１つを検出するように構成される。

【0148】

装置８００が図１に示すＰＥデバイス１２に適用されるとき、検出ユニット８０２により、サービスを運ぶためのパスを検出することの具体的な実装については、図２に示す実施形態のＳ１０４を参照する。

【0149】

サービスの識別情報は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。

【0150】

第１の指示は、第１のパケットの第１のＩＰｖ６ヘッダ又は第１のＩＰｖ６拡張ヘッダで運ばれてもよい。

【0151】

【0152】

【0153】

【0154】

【0155】

いくつかの可能な実装において、受信ユニット８０１はさらに、第１のネットワークデバイスにより送信された第２のパケットを受信するように構成され、第２のパケットは、サービスを運ぶために使用されるサービスパケットであり、第２のパケットは第１の指示を含まない。装置８００が図１に示すＰＥデバイス１２に適用されるとき、受信ユニット８０１により第２のパケットを受信することの具体的な実装については、図２に示す実施形態のＳ１０５を参照する。

【0156】

【0157】

【0158】

いくつかの可能な実装において、装置８００は、送信ユニットをさらに含んでもよい。送信ユニットは、応答パケットを第１のネットワークデバイスに送信して、第１のネットワークデバイスに、応答パケットに基づいて、第１のネットワークデバイスと第２のネットワークデバイスとの間にあり、かつサービスを運ぶためのパスと、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶためのパスとのうちの少なくとも１つのパス状態を判断するよう指示するように構成され、パス状態は、パスの接続性とパスの品質のうちの少なくとも１つを含む。第２のネットワークデバイスにより送信される応答パケットは、第２のネットワークデバイスのインターフェース状態情報を含み、インターフェース状態情報は、第１のネットワークデバイスに、第２のネットワークデバイスとアクセス側ネットワークデバイスとの間にあり、かつサービスを運ぶためのパスが障害があるかどうか、又はパス品質が良いか又は悪いかを判断するように指示する。

【0159】

いくつかの可能な実装において、検出ユニット８０２は具体的に、第１のパケットが検出パケットであると判断され、第１の指示に基づいて実行される検出がローカルでサポートされていると判断された場合、ローカル検出ポリシーに従って、サービスを運ぶためのパスを検出するように構成されてもよい。

【0160】

サービスパス検出を実施する装置８００の具体的な実行可能機能及び実装については、図２に示す実施形態におけるＰＥデバイス１２の対応する説明を参照する。詳細はここで再度説明されない。

【0161】

サービスパス検出を実施するための前述の装置７００は、サービスを運ぶイングレスＰＥデバイスでもよく、サービスパス検出を実施する装置８００は、サービスを運ぶエグレスＰＥデバイスでもよい。

【0162】

サービスパス検出を実施する装置７００とサービスパス検出を実施する装置８００との間で運ばれるサービスは、Ｌ２ＶＰＮサービスでもよい。Ｌ２ＶＰＮサービスは、例えば、従来のＶＰＮ技術又はＥＶＰＮ技術で運ばれるサービスを含んでもよい。従来のＶＰＮサービス及びＥＶＰＮサービスの双方が、ＶＬＬサービスモデル又はＶＰＬＳモデルを使用する場合がある。

【0163】

サービスパス検出を実施する装置７００及びサービスパス検出を実施する装置８００において、第１のパケットはＢＦＤパケットでもよく、あるいはＯＡＭパケットでもよい。

【0164】

図９は、本出願の一実施形態によるネットワークデバイス９００の構造の概略図である。ネットワークデバイス９００は、例えば、図１に示す実施形態における任意のＰＥデバイスでもよく、あるいは図７又は図８に示す実施形態におけるサービスパス検出を実施する装置のデバイス実装でもよい。

【0165】

図９を参照する。ネットワークデバイス９００は、プロセッサ９１０、通信インターフェース９２０、及びメモリ９３０を含む。ネットワークデバイス９００には１つ以上のプロセッサ９１０があってもよく、図９では一例として１つのプロセッサを使用している。本出願のこの実施形態において、プロセッサ９１０、通信インターフェース９２０、及びメモリ９３０は、バスシステムを使用することにより又は別の方法で接続されてもよい。図９では、プロセッサ９１０、通信インターフェース９２０、及びメモリ９３０がバスシステム９４０を使用することにより接続される一例を用いている。

【0166】

プロセッサ９１０は、ＣＰＵ、ＮＰ、又はＣＰＵとＮＰの組み合わせでもよい。プロセッサ９１０は、ハードウェアチップをさらに含んでもよい。ハードウェアチップは、特定用途向け集積回路（application-specific integrated circuit、ＡＳＩＣ）、プログラマブル論理デバイス（programmable logic device、ＰＬＤ）、又はこれらの組み合わせでもよい。前述のＰＬＤは、複合プログラマブル論理デバイス（complex programmable logic device、ＣＰＬＤ）、フィールドプログラマブルゲートアレイ（field-programmable gate array、ＦＰＧＡ）、汎用アレイ論理（generic array logic、ＧＡＬ）、又はこれらの任意の組み合わせでもよい。

【0167】

ネットワークデバイス９００が第１のネットワークデバイスを含むとき、プロセッサ９１０は、前述の方法の実施形態における、第１の指示とサービスの識別情報とを含む第１のパケットを生成すること、及び第１のパケットを第２のネットワークデバイスに送信することなどの、関連機能を実行することができる。ネットワークデバイス９００が第２のネットワークデバイスであるとき、プロセッサ９１０は、前述の方法の実施形態における、第１の指示とサービスの識別情報とを含む第１のパケットを、第１のネットワークデバイスから受信すること、及び第１の指示とサービスの識別情報とに基づいて、サービスを運ぶためのパスを検出することなどの、関連機能を実行することができる。

【0168】

通信インターフェース９２０は、パケットを受信及び送信するように構成される。具体的には、通信インターフェース９２０は、受信インターフェースと送信インターフェースを含むことができる。受信インターフェースは、パケットを受信するように構成することができ、送信インターフェースは、パケットを送信するように構成することができる。１つ以上の通信インターフェース９２０があってもよい。可能な一実装において、通信インターフェース９２０は、図７に示す送信ユニット７０２又は図８に示す受信ユニット８０１の機能を実装するように構成されてもよい。

【0169】

メモリ９３０は、揮発性メモリ（英語：volatile memory）、例えば、ランダムアクセスメモリ（random access memory、ＲＡＭ）を含むことができる。代替的に、メモリ９３０は、不揮発性メモリ（英語：non-volatile memory）、例えば、フラッシュメモリ（英語：flash memory）、ハードディスクドライブ（hard disk drive、ＨＤＤ）、ソリッドステートドライブ（solid-state drive、ＳＳＤ）を含んでもよい。メモリ９３０は、さらに、前述のタイプのメモリの組み合わせを含んでもよい。例えば、メモリ９３０は、上記で言及されたサービスの識別情報を記憶することができる。

【0170】

任意で、メモリ９３０は、オペレーティングシステムとプログラム、実行可能モジュール又はデータ構造、これらのサブセット、又はこれらの拡張セットを記憶する。プログラムは、様々な動作を実施するために使用される様々な動作命令を含むことができる。オペレーティングシステムは、様々な基本サービスを実施し、ハードウェアベースのタスクを処理するための、様々なシステムプログラムを含むことができる。プロセッサ９１０は、本出願の実施形態で提供されるサービスパス検出を実施する方法を実施するための、メモリ９３０内のプログラムを読み取ることができる。可能な一実装において、メモリ９３０は、図７に示す生成ユニット７０１又は図８に示す検出ユニット８０２の機能を実装するために使用されるプログラムコードなどのプログラムコードを記憶してもよい。

【0171】

メモリ９３０は、ネットワークデバイス９００内のメモリコンポーネントでもよく、あるいはネットワークデバイス９００とは独立した記憶装置でもよい。

【0172】

バスシステム９４０は、ペリフェラルコンポーネントインターコネクト（peripheral component interconnect、ＰＣＩ）バス、拡張業界標準アーキテクチャ（extended industry standard architecture、ＥＩＳＡ）バスなどでもよい。バスシステム９４０は、アドレスバス、データバス、制御バスなどに分類される場合がある。表現を容易にするため、図９ではバスを表すために１つの太線のみを用いているが、これは、１つのバスのみ又は１つのタイプのバスのみがあることを意味するわけではない。

【0173】

図１０は、本出願の一実施形態による別のネットワークデバイス１０００の構造の概略図である。ネットワークデバイス１０００は、図１に示す実施形態における任意のＰＥデバイスとして構成されてもよく、あるいは図７又は図８に示す実施形態におけるサービスパス検出を実施する装置のデバイス実装でもよい。

【0174】

ネットワークデバイス１０００は、メイン制御ボード１０１０とインターフェースボード１０３０を含む。

【0175】

メイン制御ボード１０１０は、主処理装置（main processing unit、ＭＰＵ）又はルートプロセッサカード（route processor card）とも呼ばれる。メイン制御ボード１０１０は、ルート計算、デバイス管理、デバイス保守、及びプロトコル処理の機能を含む、ネットワークデバイス１０００内の各コンポーネントを制御し、管理する。メイン制御ボード１０１０は、中央処理装置１０１１とメモリ１０１２を含む。

【0176】

インターフェースボード１０３０は、ライン処理ユニットカード（line processing unit、ＬＰＵ）、ラインカード（line card）、又はサービスボードとも呼ばれる。インターフェースボード１０３０は、様々なサービスインターフェースを提供し、データパケット転送を実施するように構成される。サービスインターフェースは、これらに限られないが、イーサネットインターフェース、ＰＯＳ（パケット・オーバー・ＳＯＮＥＴ／ＳＤＨ（Packet over SONET/SDH））インターフェースなどを含む。イーサネットインターフェースは、例えば、フレキシブルイーサネットクライアント（Flexible Ethernet Clients、ＦｌｅｘＥクライアント）である。インターフェースボード１０３０は、中央処理装置１０３１、ネットワークプロセッサ１０３２、転送エントリメモリ１０３４、及び物理インターフェースカード（physical interface card、ＰＩＣ）１０３３を含む。

【0177】

インターフェースボード１０３０上の中央処理装置１０３１は、インターフェースボード１０３０を制御及び管理し、メイン制御ボード１０１０上の中央処理装置１０１１と通信するように構成される。

【0178】

ネットワークプロセッサ１０３２は、パケット転送処理を実施するように構成される。ネットワークプロセッサ８３２の形態は、転送チップでもよい。具体的には、上りリンクパケットの処理は、パケットのインバウンドインターフェースの処理と転送テーブルの検索を含み、下りリンクパケットの処理は、転送テーブルの検索を含むなどである。

【0179】

物理インターフェースカード１０３３は、物理層相互接続機能を実装するように構成され、それにより、元のトラフィックはインターフェースボード１０３０に入り、処理されたパケットは物理インターフェースカード１０３３から送出される。物理インターフェースカード１０３３は少なくとも１つの物理インターフェースを含み、物理インターフェースは物理インターフェースとも呼ばれる。物理インターフェースカード１０３３は、サブカードと呼ばれることもあり、インターフェースボード１０３０に設置されてもよく、光／電気信号をパケットに変換すること、パケットに対する妥当性チェックを実行すること、及びパケットを処理のためにネットワークプロセッサ１０３２に転送することを担う。いくつかの実施形態において、インターフェースボード１０３０の中央処理装置８３１が、代替的にネットワークプロセッサ１０３２の機能を実行し、例えば汎用ＣＰＵに基づいてソフトウェア転送を実施してもよく、それにより、ネットワークプロセッサ１０３２は、物理インターフェースカード１０３３において必要とされない。

【0180】

任意で、ネットワークデバイス１０００は複数のインターフェースボードを含む。例えば、ネットワークデバイス１０００はインターフェースボード１０４０をさらに含む。インターフェースボード１０４０は、中央処理装置１０４１、ネットワークプロセッサ１０４２、転送エントリメモリ１０４４、及び物理インターフェースカード１０４３を含む。

【0181】

任意で、ネットワークデバイス１０００は切り替えボード１０２０をさらに含む。切り替えボード１０２０は、スイッチファブリックユニット（switch fabric unit、ＳＦＵ）と呼ばれることもある。ネットワークデバイスが複数のインターフェースボード１０３０を有するとき、切り替えボード１０２０は、インターフェースボード間のデータ交換を完了するように構成される。例えば、インターフェースボード１０３０とインターフェースボード１０４０は、切り替えボード８２０を使用することにより互いに通信することができる。

【0182】

メイン制御ボード１０１０とインターフェースボード１０３０は結合されている。例えば、メイン制御ボード１０１０、インターフェースボード１０３０、インターフェースボード１０４０、及び切り替えボード１０２０は、インターワーキングを実施するために、システムバスを使用することによりシステムバックプレーンに接続される。可能な一実装において、メイン制御ボード１０１０とインターフェースボード１０３０との間にプロセス間通信（inter-process communication、ＩＰＣ）チャネルが確立され、ＩＰＣチャネルを使用することによりメイン制御ボード１０１０とインターフェースボード１０３０との間で通信が実行される。

【0183】

論理的には、ネットワークデバイス１０００は制御プレーンと転送プレーンを含む。制御プレーンは、メイン制御ボード１０１０と中央処理装置１０３１を含み、転送プレーンは、転送エントリメモリ１０３４、物理インターフェースカード１０３３、及びネットワークプロセッサ１０３２などの、転送を実行するコンポーネントを含む。制御プレーンは、ルータ、転送テーブルの生成、シグナリング及びプロトコルパケットの処理、並びにデバイス状態の構成及び保守などの機能を実行する。制御プレーンは、生成された転送テーブルを転送プレーンに配信する。転送プレーンでは、ネットワークプロセッサ１０３２は、テーブルを検索し、制御プレーンにより配信された転送テーブルに基づいて、物理インターフェースカード１０３３により受信されたパケットを転送する。制御プレーンにより配信された転送テーブルは、転送エントリメモリ１０３４に記憶することができる。いくつかの実施形態において、制御プレーンと転送プレーンは完全に分離されている場合があり、同じデバイス上にない。

【0184】

ネットワークデバイス１０００が第１のネットワークデバイスとして構成されている場合、中央処理装置１０１１は、第１の指示とサービスの識別情報とを含む第１のパケットを生成することができる。ネットワークプロセッサ１０３２は、第１のパケットを第２のネットワークデバイスに送信するために物理インターフェースカード１０３３をトリガすることができる。

【0185】

ネットワークデバイス１０００が第２のネットワークデバイスとして構成されている場合、中央処理装置１０１１は、第１のネットワークデバイスから、第１の指示とサービスの識別情報とを含む第１のパケットを受信し、第１の指示とサービスの識別情報とに基づいて、サービスを運ぶためのパスを検出することができる。ネットワークプロセッサ１０３２は、第１のネットワークデバイスに応答パケットを送信するために物理インターフェースカード１０３３をトリガすることができる。

【0186】

サービスパス検出を実施する装置７００における送信ユニット７０２などは、ネットワークデバイス１０００における物理インターフェースカード１０３３又は物理インターフェースカード１０４３と同等でもよいことを理解されたい。サービスパス検出を実施する装置７００における生成ユニット７０１などは、ネットワークデバイス１０００における中央処理装置１０１１又は中央処理装置１０３１と同等でもよい。サービスパス検出を実施する装置８００における受信ユニット８０１などは、ネットワークデバイス１０００における物理インターフェースカード１０３３又は物理インターフェースカード１０４３と同等でもよい。サービスパス検出を実施する装置８００における検出ユニット８０２などは、ネットワークデバイス１０００における中央処理装置１０１１又は中央処理装置１０３１と同等でもよい。

【0187】

本出願のこの実施形態において、インターフェースボード１０４０上の動作は、インターフェースボード１０３０上の動作と同じであることを理解されたい。簡潔にするため、詳細は再度説明されない。この実施形態におけるネットワークデバイス１０００は、前述の方法の実施形態における任意のノードに対応し得ることを理解されたい。ネットワークデバイス１０００におけるメイン制御ボード１０１０、インターフェースボード１０３０、及び／又はインターフェースボード１０４０は、前述の方法の実施形態における任意のノードにより実施される機能及び／又は様々なステップを実施することができる。簡潔にするため、詳細はここで再度説明されない。

【0188】

１つ以上のメイン制御ボードがあってもよく、複数のメイン制御ボードがあるとき、アクティブメイン制御ボードとスタンバイメイン制御ボードが含まれてもよいことを理解されたい。１つ以上のインターフェースボードがあってもよい。ネットワークデバイスの、より強力なデータ処理能力は、より多くの、提供されるインターフェースボードを示す。代替的に、インターフェースボードに１つ以上の物理インターフェースカードがあってもよい。切り替えボードがない場合があり、あるいは１つ以上の切り替えボードがある場合がある。複数の切り替えボードがある場合、切り替えボードは、負荷分散と冗長バックアップを連帯的に実施することができる。集中型の転送アーキテクチャにおいて、切り替えボードはネットワークデバイスに必要とされない場合があり、インターフェースボードがシステム全体のサービスデータを処理する。分散型の転送アーキテクチャでは、ネットワークデバイスは、少なくとも１つの切り替えボードを有する場合があり、その切り替えボードを使用することにより、複数のインターフェースボード間のデータ交換を実施して、大容量のデータ交換及び処理能力を提供する。したがって、分散型アーキテクチャにおけるネットワークデバイスのデータアクセス及び処理能力は、集中型アーキテクチャにおけるデバイスのものより大きい。任意で、ネットワークデバイスの形態は、代替的に、１つのボードのみがあり、すなわち切り替えボードがなく、ボード上にインターフェースボードとメイン制御ボードとの機能が統合されているものでもよい。この場合、インターフェースボード上の中央処理装置とメイン制御ボード上の中央処理装置とをボード上の１つの中央処理装置に組み合わせて、２つの中央処理装置により重ね合わせられた機能を実行してもよい。この形態のデバイス（例えば、ローエンドのスイッチ又はルータなどのネットワークデバイス）は、低いデータ交換及び処理能力を有する。使用されるアーキテクチャは、特定のネットワーキング配備シナリオに依存する。

【0189】

いくつかの可能な実施形態において、前述のノードは、仮想化デバイスとして実装されてもよい。例えば、仮想化デバイスは、パケット機能を送信するために使用されるプログラムを実行する仮想マシン（英語：Virtual Machine、ＶＭ）でもよく、仮想マシンは、ハードウェアデバイス（例えば、物理サーバ）に配備される。仮想マシンは、ソフトウェアによりシミュレートされ、完全なハードウェアシステム機能を有し、完全に分離された環境で実行される完全なコンピュータシステムである。仮想マシンは、各ノードとして構成されてもよい。例えば、各ノードは、ネットワーク機能仮想化（Network Functions Virtualization、ＮＦＶ）技術と組み合わせた汎用物理サーバに基づいて実装されてもよい。各ノードは、仮想ホスト、仮想ルータ、又は仮想スイッチである。当業者は、ＮＦＶ技術を参照して本出願を読むことにより、汎用物理サーバ上で、前述の機能を有するノードを仮想化することができる。詳細はここで再度説明されない。

【0190】

前述の製品の形態におけるネットワークデバイスは、前述の方法の実施形態における各ノードの任意の機能を有することを理解されたい。詳細はここで再度説明されない。

【0191】

本出願の一実施形態は、図１１に示すように、ネットワークシステム１１００をさらに提供する。ネットワークシステム１１００は、第１のネットワークデバイス１１０１と第２のネットワークデバイス１１０２を含むことができる。第１のネットワークデバイス１１０１は、図１に示すＰＥデバイス１１、図７に示すサービスパス検出を実施する装置７００、図９に示す第１のネットワークデバイスとして構成されたネットワークデバイス９００、又は図１０に示す第１のネットワークデバイスとして構成されたネットワークデバイス１０００でもよい。第２のネットワークデバイス１１０２は、図１に示すＰＥデバイス１２、図８に示すサービスパス検出を実施する装置８００、図９に示す第２のネットワークデバイスとして構成されたネットワークデバイス９００、又は図１０に示す第２のネットワークデバイスとして構成されたネットワークデバイス１０００でもよい。

【0192】

本出願の一実施形態は、プロセッサとインターフェース回路とを含むチップをさらに提供する。インターフェース回路は、命令を受信し、命令をプロセッサに送信するように構成される。プロセッサは、例えば、図７に示すサービスパス検出を実施する装置７００の特定の実装形態でもよく、前述の方法を実行するように構成されてもよい。別の例として、プロセッサは、図８に示すサービスパス検出を実施する装置８００の特定の実装形態でもよく、前述の方法を実行するように構成されてもよい。プロセッサはメモリに結合されている。メモリは、プログラム又は命令を記憶するように構成される。プログラム又は命令がプロセッサにより実行されたとき、チップシステムは、前述の方法の実施形態のいずれか１つにおける方法を実施することを可能にされる。

【0193】

任意で、チップシステムに１つ以上のプロセッサがあってもよい。プロセッサは、ハードウェアを使用することにより実装されてもよく、あるいはソフトウェアを使用することにより実装されてもよい。プロセッサがハードウェアを使用することにより実装されるとき、プロセッサは、論理回路、集積回路などでもよい。プロセッサがソフトウェアを使用することにより実装されるとき、プロセッサは、汎用プロセッサでもよく、メモリに記憶されたソフトウェアコードを読み取ることにより実装される。

【0194】

任意で、代替的に、チップシステムに１つ以上のメモリがあってもよい。メモリは、プロセッサと統合されてもよく、あるいはプロセッサと別個に配置されてもよい。これは本出願において限定されない。例えば、メモリは、非一時的プロセッサ、例えば読取専用メモリＲＯＭでもよい。メモリとプロセッサは、同じチップに統合されてもよく、あるいは異なるチップに別個に配置されてもよい。メモリのタイプ、及びメモリとプロセッサの配置の方法は、本出願において具体的に限定されない。

【0195】

例えば、チップシステムは、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）、特定用途向け集積回路（application-specific integrated circuit、ＡＳＩＣ）、システムオンチップ（system on chip、ＳｏＣ）、中央処理装置（central processing unit、ＣＰＵ）、ネットワークプロセッサ（network processor、ＮＰ）、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）、マイクロコントローラユニット（micro controller unit、ＭＣＵ）、プログラマブル論理デバイス（programmable logic device、ＰＬＤ）、又は別の統合チップでもよい。

【0196】

本出願の一実施形態は、命令又はコンピュータプログラムを含む、コンピュータ読取可能記憶媒体をさらに提供する。命令又はコンピュータプログラムがコンピュータ上で実行されたとき、コンピュータは、前述の実施形態で提供されるサービスパス検出を実施する方法を実行することを可能にされる。

【0197】

本出願の一実施形態は、命令又はコンピュータプログラムを含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータ上で実行されたとき、コンピュータは、前述の実施形態で提供されるサービスパス検出を実施する方法を実行することを可能にされる。

【0198】

本出願の明細書、特許請求の範囲、及び添付の図面において、用語「第１の」、「第２の」、「第３の」、「第４の」等（存在する場合）は、類似のオブジェクト間で区別することを意図しており、必ずしも特定の順序又はシーケンスを示すわけではない。このような方法で使用されるデータは、適切な状況において言い換え可能である場合があり、それにより、本明細書で説明される実施形態は、本明細書で例示又は説明された内容以外の順序で実施できることを理解されたい。さらに、「含む」、「有する」などの用語、及びこれらの任意のバリエーションは、非排他的な包含をカバーすることを意図している。例えば、一連のステップ又はユニットを含むプロセス、方法、システム、製品、又はデバイスは、必ずしも明確に列挙されたステップ又はユニットに限定されず、明確に列挙されていないか又はそのようなプロセス、方法、製品、又はデバイスに内在する他のステップ又はユニットを含んでもよい。

【0199】

簡便及び簡潔な説明を目的として、前述のシステム、装置、及びユニットの詳細な作業プロセスについては、前述の方法の実施形態における対応するプロセスを参照することが当業者には明確に理解され得る。詳細はここで再度説明されない。

【0200】

本出願で提供されるいくつかの実施形態において、開示されたシステム、装置、及び方法は他の方式で実施されてもよいことを理解されたい。例えば、説明された装置の実施形態は、単なる一例である。例えば、ユニットへの分割は、単なる論理的なサービス分割であり、実際の実装の間には他の分割でもよい。例えば、複数のユニット又はコンポーネントが組み合わせられ、又は別のシステムに統合されてもよく、あるいは、いくつかの機能が無視されてもよく、又は実行されなくてもよい。さらに、表示され又は論じられた相互結合又は直接結合又は通信接続は、いくつかのインターフェースを通じて実装されてもよい。装置又はユニット間の間接結合又は通信接続は、電子的、機械的、又は他の形式で実装されてもよい。

【0201】

別個の部品として説明されたユニットは、物理的に別個でも又はそうでなくてもよく、ユニットとして表示された部品は、物理的なユニットでも又はそうでなくてもよく、１つの位置に配置されてもよく、あるいは複数のネットワークユニットに分散されてもよい。ユニットの一部又は全部が、実施形態の解決策の目的を達成するために、実際の要件に基づいて選択されてもよい。

【0202】

さらに、本出願の実施形態におけるサービスユニットは１つの処理ユニットに統合されてもよく、ユニットの各々が物理的に単独で存在してもよく、あるいは２つ以上のユニットが１つのユニットに統合される。統合されたユニットは、ハードウェアの形で実装されてもよく、あるいはソフトウェアサービスユニットの形で実装されてもよい。

【0203】

統合されたユニットがソフトウェアサービスユニットの形で実装され、独立した製品として販売又は使用されるとき、統合されたユニットは、コンピュータ読取可能記憶媒体に記憶されてもよい。このような理解に基づいて、本質的に本出願の技術的解決策、又は従来の技術に貢献する部分、又は技術的解決策の全部又は一部が、ソフトウェア製品の形で実装されてもよい。コンピュータソフトウェア製品は、記憶媒体に記憶され、コンピュータデバイス（これは、パーソナルコンピュータ、サーバ、ネットワークデバイスなどでもよい）に、本出願の実施形態で説明された方法のステップの全て又は一部のステップを実行するよう指示するためのいくつかの命令を含む。前述の記憶媒体は、プログラムコードを記憶することができる様々な媒体、例えば、ＵＳＢフラッシュドライブ、リムーバブルハードディスク、読取専用メモリ（Read-Only Memory、ＲＯＭ）、ランダムアクセスメモリ（Random Access Memory、ＲＡＭ）、磁気ディスク、及び光ディスクを含む。

【0204】

当業者は、前述の例の１つ以上において、本発明に記載されたサービスがハードウェア、ソフトウェア、ファームウェア、又はこれらの任意の組み合わせを使用することにより実装されてもよいことを認識すべきである。サービスがソフトウェアを使用することにより実装されるとき、前述のサービスは、コンピュータ読取可能媒体に記憶され、あるいはコンピュータ読取可能媒体上の１つ以上の命令又はコードとして伝送されてもよい。コンピュータ読取可能媒体は、コンピュータ記憶媒体と通信媒体を含み、通信媒体は、ある場所から別の場所へのコンピュータプログラムの伝送を容易にする任意の媒体を含む。記憶媒体は、汎用又は専用のコンピュータにとってアクセス可能な任意の利用可能な媒体であってよい。

【0205】

本発明の目的、技術的解決策、及び有益な効果はさらに、前述の特定の実装において詳細に説明されている。前述は単に本発明の特定の実装であることを理解されたい。

【0206】

前述の実施形態は、単に本出願の技術的解決策を説明することを意図しており、本出願を限定することを意図していない。本出願は、前述の実施形態を参照して詳細に説明されているが、当業者は、依然として、本出願の実施形態の技術的解決策の範囲から逸脱することなく、前述の実施形態に記載されている技術的解決策に対して修正を行い、又はその一部の技術的特徴に対して同等な置換を行うことができることを理解すべきである。

【図1】