特許 7432095 ＳＲｖ６サービス機能チェーンでパケットを転送する方法、ＳＦＦ、およびＳＦデバイス

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

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

(11)【特許番号】

(24)【登録日】2024-02-07

(45)【発行日】2024-02-16

(54)【発明の名称】ＳＲｖ６サービス機能チェーンでパケットを転送する方法、ＳＦＦ、およびＳＦデバイス

(51)【国際特許分類】

   H04L 45/50 20220101AFI20240208BHJP

【ＦＩ】

H04L45/50

【請求項の数】 15

(21)【出願番号】P 2022555904

(86)(22)【出願日】2021-05-17

(65)【公表番号】

(43)【公表日】2023-05-26

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

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

(87)【国際公開日】2021-11-25

【審査請求日】2022-10-20

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

(32)【優先日】2020-05-18

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

(73)【特許権者】

【識別番号】504161984

【氏名又は名称】ホアウェイ・テクノロジーズ・カンパニー・リミテッド

(74)【代理人】

【識別番号】110000877

【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所

(72)【発明者】

【氏名】ジャン、ヨンカン

(72)【発明者】

【氏名】フ、ジボ

【審査官】小林 義晴

(56)【参考文献】

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

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

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

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

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

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

【請求項1】

ＳＲｖ６サービス機能チェーンでパケットを転送する方法であって、前記方法が、
サービス機能転送器（ＳＦＦ）が第１のインターネットプロトコルバージョン６を介したセグメントルーティング（ＳＲｖ６）パケットを受信する段階であって、前記第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ（Ｅｎｄ．ＰＴ．ＳＩＤ）が含まれており、前記Ｅｎｄ．ＰＴ．ＳＩＤが、セグメントルーティングヘッダ（ＳＲＨ）を取り除くことなく前記第１のＳＲｖ６パケットをサービス機能（ＳＦ）デバイスに転送するよう前記ＳＦＦに指示するのに用いられる、受信する段階と、
前記ＳＦＦが前記Ｅｎｄ．ＰＴ．ＳＩＤおよび前記第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成する段階であって、前記第２のＳＲｖ６パケットには制御フラグが含まれており、前記制御フラグが、前記第２のＳＲｖ６パケットにおいて前記制御フラグの後に続くインターネットプロトコルバージョン６（ＩＰｖ６）拡張ヘッダをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはＳＲＨが含まれている、生成する段階と、
前記ＳＦＦが前記第２のＳＲｖ６パケットを前記ＳＦデバイスに送信する段階と
を備えている、方法。

【請求項2】

前記制御フラグがさらに、前記ＳＦＦにパケットを戻すプロセスにおいて、前記ＩＰｖ６拡張ヘッダを戻すよう前記ＳＦデバイスに指示するのに用いられ、前記ＳＦＦが前記第２のＳＲｖ６パケットを前記ＳＦデバイスに送信する前記段階の後に、前記方法がさらに、
前記ＳＦＦが前記ＳＦデバイスから第３のＳＲｖ６パケットを受信する段階であって、前記第３のＳＲｖ６パケットには前記ＩＰｖ６拡張ヘッダが含まれており、前記第３のＳＲｖ６パケットおよび前記第２のＳＲｖ６パケットが同じＳＲＨを有している、受信する段階と、
前記ＳＦＦが前記第３のＳＲｖ６パケットの前記ＳＲＨに基づいて前記第３のＳＲｖ６パケットに対して転送処理を行う段階と
を備えている、請求項１に記載の方法。

【請求項3】

ＳＲｖ６サービス機能チェーンでパケットを処理する方法であって、前記方法が、
サービス機能（ＳＦ）デバイスが第２のインターネットプロトコルバージョン６を介したセグメントルーティング（ＳＲｖ６）パケットをサービス機能転送器（ＳＦＦ）から受信する段階であって、前記第２のＳＲｖ６パケットには制御フラグが含まれており、前記制御フラグが、前記第２のＳＲｖ６パケットにおいて前記制御フラグの後に続くインターネットプロトコルバージョン６（ＩＰｖ６）拡張ヘッダをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダ（ＳＲＨ）が含まれている、受信する段階と、
前記ＳＦデバイスが前記制御フラグに基づいて前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットする段階と
を備えている、方法。

【請求項4】

前記制御フラグがさらに、前記ＳＦＦにパケットを戻すプロセスにおいて、前記ＩＰｖ６拡張ヘッダを戻すよう前記ＳＦデバイスに指示するのに用いられ、前記方法がさらに、
前記ＳＦデバイスが前記制御フラグに基づいて前記ＳＦＦに第３のＳＲｖ６パケットを送信する段階を備えており、前記第３のＳＲｖ６パケットには前記ＩＰｖ６拡張ヘッダが含まれており、前記第３のＳＲｖ６パケットおよび前記第２のＳＲｖ６パケットが同じＳＲＨを有している、請求項３に記載の方法。

【請求項5】

前記第２のＳＲｖ６パケットにはホップバイホップオプションヘッダが含まれており、前記ホップバイホップオプションヘッダには前記制御フラグが含まれている、請求項３または４に記載の方法。

【請求項6】

前記ホップバイホップオプションヘッダにはタイプ－長さ－値（ＴＬＶ）が含まれており、前記ＴＬＶが前記制御フラグを搬送するのに用いられる、請求項５に記載の方法。

【請求項7】

前記制御フラグが、前記第２のＳＲｖ６パケットの前記ＳＲＨをオフセットするよう前記ＳＦデバイスに指示するのに用いられる、または
前記制御フラグが、前記第２のＳＲｖ６パケットの前記ＳＲＨと前記ＳＲＨ以外の別のＩＰｖ６拡張ヘッダとをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットにおいて前記別のＩＰｖ６拡張ヘッダが前記制御フラグの後に続く、請求項３から６のいずれか一項に記載の方法。

【請求項8】

前記ＳＦデバイスが前記制御フラグに基づいて前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットする前記段階の後に、前記方法がさらに、
前記ＳＦデバイスがサービス処理を行う段階を備えている、請求項３に記載の方法。

【請求項9】

前記第２のＳＲｖ６パケットにはさらにターゲット情報が含まれており、前記ターゲット情報とは、前記ＳＦデバイスが前記サービス処理を行うときに用いる必要がある情報であり、サービス処理を行う前記段階が、
前記ターゲット情報に基づいて前記サービス処理を行う段階を含んでいる、請求項８に記載の方法。

【請求項10】

前記ターゲット情報にはサービス機能チェーン（ＳＦＣ）メタデータおよび仮想プライベートネットワークＩＤ（ＶＰＮ ＩＤ）のうちの少なくとも一方が含まれている、請求項９に記載の方法。

【請求項11】

サービス機能転送器（ＳＦＦ）であって、前記ＳＦＦが、
第１のインターネットプロトコルバージョン６を介したセグメントルーティング（ＳＲｖ６）パケットを受信するように構成された受信モジュールであって、前記第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ（Ｅｎｄ．ＰＴ．ＳＩＤ）が含まれており、前記Ｅｎｄ．ＰＴ．ＳＩＤが、セグメントルーティングヘッダ（ＳＲＨ）を取り除くことなく前記第１のＳＲｖ６パケットをサービス機能（ＳＦ）デバイスに転送するよう前記ＳＦＦに指示するのに用いられる、受信モジュールと、
前記Ｅｎｄ．ＰＴ．ＳＩＤおよび前記第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成するように構成された生成モジュールであって、前記第２のＳＲｖ６パケットには制御フラグが含まれており、前記制御フラグが、前記第２のＳＲｖ６パケットにおいて前記制御フラグの後に続くインターネットプロトコルバージョン６（ＩＰｖ６）拡張ヘッダをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはＳＲＨが含まれている、生成モジュールと、
前記第２のＳＲｖ６パケットを前記ＳＦデバイスに送信するように構成された送信モジュールと
を備えている、ＳＦＦ。

【請求項12】

サービス機能（ＳＦ）デバイスであって、前記ＳＦデバイスが、
第２のインターネットプロトコルバージョン６を介したセグメントルーティング（ＳＲｖ６）パケットをサービス機能転送器（ＳＦＦ）から受信するように構成された受信モジュールであって、前記第２のＳＲｖ６パケットには制御フラグが含まれており、前記制御フラグが、前記第２のＳＲｖ６パケットにおいて前記制御フラグの後に続くインターネットプロトコルバージョン６（ＩＰｖ６）拡張ヘッダをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダ（ＳＲＨ）が含まれている、受信モジュールと、
前記制御フラグに基づいて前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットするように構成された処理モジュールと
を備えている、ＳＦデバイス。

【請求項13】

ネットワークシステムであって、前記システムがサービス機能転送器（ＳＦＦ）とサービス機能（ＳＦ）デバイスとを備えており、前記ＳＦＦが請求項１または２に記載の方法を行うように構成されており、前記ＳＦデバイスが請求項３から１０のいずれか一項に記載の方法を行うように構成されている、ネットワークシステム。

【請求項14】

サービス機能転送器（ＳＦＦ）に、請求項１または２に記載の方法を実行させるためのコンピュータプログラム。

【請求項15】

サービス機能（ＳＦ）デバイスに、請求項３から１０のいずれか一項に記載の方法を実行させるためのコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、２０２０年５月１８日に出願された「ＳＲｖ６サービス機能チェーンでパケットを転送する方法、ＳＦＦ、およびＳＦデバイス（ＭＥＴＨＯＤ ＦＯＲ ＦＯＲＷＡＲＤＩＮＧ ＰＡＣＫＥＴ ＩＮ ＳＲＶ６ ＳＥＲＶＩＣＥ ＦＵＮＣＴＩＯＮ ＣＨＡＩＮ， ＳＦＦ， ＡＮＤ ＳＦ ＤＥＶＩＣＥ）」と題する中国特許出願第２０２０１０４２１８９３．２号に基づく優先権を主張し、当該中国特許出願はその全体が参照により本明細書に組み込まれる。

【0002】

本願は通信技術の分野に関し、特に、ＳＲｖ６サービス機能チェーンでパケットを転送する方法、ＳＦＦ、およびＳＦデバイスに関する。

【背景技術】

【0003】

セグメントルーティング（英名：ｓｅｇｍｅｎｔ ｒｏｕｔｉｎｇ、略してＳＲ）とは、ソースルーティングに基づいてパケットを転送するのに用いられる技術である。インターネットプロトコルバージョン６（英名：ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６、略してＩＰｖ６）を介したセグメントルーティング（略してＳＲｖ６）とは、ＳＲ技術とＩＰｖ６プロトコルとを組み合わせた技術である。具体的には、一般的なＩＰｖ６パケットでは、ＩＰｖ６パケットの宛先アドレス（Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ、ＤＡ）が固定されている。しかしながら、ＳＲｖ６フィールドでは、ＩＰｖ６パケットのＤＡがＳＲｖ６セグメントＩＤ（英名：ｓｅｇｍｅｎｔ ＩＤ、略してＳＩＤ）であり、ＩＰｖ６パケットのＤＡはネクストホップノードを識別し、ホップバイホップ転送を完了させるためにＳＲｖ６ノードがＤＡを常に更新する。

【0004】

ＳＲｖ６技術では、ＩＰｖ６転送プレーンに基づいてＳＲを実施するために、セグメントルーティングヘッダ（英名：Ｓｅｇｍｅｎｔ Ｒｏｕｔｉｎｇ Ｈｅａｄｅｒ、略してＳＲＨ）と呼ばれるＩＰｖ６拡張ヘッダが追加される。ＳＲＨとは本質的に、ルーティングタイプのＩＰｖ６拡張ヘッダである。ＳＲＨには、ＳＩＤリスト（英名：ＳＩＤ ｌｉｓｔ、セグメントリストとも呼ばれる）が含まれている。ＳＩＤリストには、順番に配置された１つまたは複数のＳＩＤが含まれている。ＳＲｖ６パケットとは、ＳＲＨを搬送するＩＰｖ６パケットを指す。

【0005】

サービス機能チェーン（英名：ｓｅｒｖｉｃｅ ｆｕｎｃｔｉｏｎ ｃｈａｉｎ、略してＳＦＣ）とは、トラフィックが複数のサービス機能（英名：ｓｅｒｖｉｃｅ ｆｕｎｃｔｉｏｎ、略してＳＦ）デバイスを指定された順番で通過するのを可能にする順序付きサービス機能セットであり、複数のＳＦデバイスはパケットを順番に処理して、サービス処理プロセスを完了させる。

【0006】

ＳＦＣはＳＲｖ６のＳＦＣに向かって徐々に進化している。しかしながら、多くのＳＦデバイスが現在もまだＳＲｖ６をサポートしていない。言い換えれば、ＳＦデバイスはＳＲｖ６非対応（英名：ＳＲｖ６－ｕｎａｗａｒｅ）デバイスであり、このＳＦデバイスはＳＲｖ６パケットのＳＲＨを識別できない。このことを考慮して、ＳＦデバイスは通常、１つまたは複数のサービス機能転送器（英名：Ｓｅｒｖｉｃｅ Ｆｕｎｃｔｉｏｎ Ｆｏｒｗａｒｄｅｒ、略してＳＦＦ）に接続されている。ＳＲｖ６サービス機能チェーンでパケットを転送するプロセスでは、ＳＦＦはＳＲプロキシ（英名：ＳＲ ｐｒｏｘｙ）機能を実装して、ＳＲＨを取り除く方式でＳＲｖ６パケットをＳＦデバイスに転送し、ＳＦデバイスがＳＲｖ６パケットを通常どおり処理できることを保証する。

【0007】

ＳＲプロキシのタイプとしては、動的プロキシ、静的プロキシ、共有メモリプロキシ、またはマスカレードプロキシなどがあり得る。一例として、動的プロキシの処理プロセスを用いる。ＳＦＦがパケットを転送するプロセスとは、以下の通りである。ＳＦＦはＳＲｖ６パケットを受信し、ＳＲｖ６パケットの宛先アドレスに基づいてローカルＳＩＤテーブルに照会し、宛先アドレスがローカルＳＩＤテーブルにあるエンドポイント動的プロキシＳＩＤ（Ｅｎｄ．ＡＤ．ＳＩＤ、Ｅｎｄがｅｎｄｐｏｉｎｔを示し、Ｄがｄｙｎａｍｉｃを示し、ＳＩＤがセグメントＩＤを示す）である場合、ＳＦＦはＥｎｄ．ＡＤ．ＳＩＤに対応する動的プロキシオペレーションを行い（具体的には、ＳＦＦはＳＲｖ６パケットからＳＲＨを取り除いて、ＳＲＨを含まないパケットを取得し）、ＳＲＨを含まないパケットをＳＦデバイスに送信し、ＳＲＨをキャッシュに格納する。ＳＦデバイスはＳＲＨを含まないパケットを受信し、そのパケットを処理し、処理したパケットをＳＦＦに戻す。ＳＦＦは、ＳＦデバイスから戻された、ＳＲＨを含まないパケットを受信した後に、ＳＲＨをキャッシュから取得し、処理されたパケットのＳＲＨを復元し、このパケットをＳＲｖ６パケットに復元して、このＳＲｖ６パケットを転送する。

【0008】

前述の方法を用いる場合、転送プロセスにおいて、ＳＦＦはＳＲｖ６パケットのＳＲＨを取り除き、ＳＦデバイスから戻されたパケットに対してはＳＲＨを復元する必要がある。その結果、ＳＦＦの実装が複雑になり、ＳＦＦのオーバーヘッドが高くなる。

【発明の概要】

【0009】

本願の実施形態では、ＳＦＦの実装を簡略化するために、ＳＲｖ６サービス機能チェーンでパケットを転送する方法、ＳＦＦ、およびＳＦデバイスを提供する。その技術的解決手段は、以下の通りである。

【0010】

第１態様によれば、ＳＲｖ６サービス機能チェーンでパケットを転送する方法が提供される。本方法では、サービス機能転送器（ＳＦＦ）が第１のインターネットプロトコルバージョン６を介したセグメントルーティング（ＳＲｖ６）パケットを受信し、第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ（Ｅｎｄ．ＰＴ．ＳＩＤ）が含まれており、Ｅｎｄ．ＰＴ．ＳＩＤは、セグメントルーティングヘッダ（ＳＲＨ）を取り除くことなく第１のＳＲｖ６パケットをサービス機能（ＳＦ）デバイスに転送するようＳＦＦに指示するのに用いられる。ＳＦＦは、Ｅｎｄ．ＰＴ．ＳＩＤと第１のＳＲｖ６パケットとに基づいて第２のＳＲｖ６パケットを生成し、第２のＳＲｖ６パケットには制御フラグが含まれており、制御フラグは、第２のＳＲｖ６パケットにおいて制御フラグの後に続くインターネットプロトコルバージョン６（ＩＰｖ６）拡張ヘッダをオフセットするようＳＦデバイスに指示するのに用いられ、第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダにはＳＲＨが含まれている。ＳＦＦは、第２のＳＲｖ６パケットをＳＦデバイスに送信する。

【0011】

以上では、ＳＲｖ６サービス機能チェーンを実装する方法を提供している。Ｅｎｄ．ＰＴ．ＳＩＤを提供して用いるのは、ＳＦＦがＳＲＨを取り除くことなくＳＲｖ６パケットをＳＦデバイスに転送するのを識別するためである。Ｅｎｄ．ＰＴ．ＳＩＤに基づいて、ＳＦＦは、ＳＲｖ６パケットのＳＲＨを取り除くのではなく、このＳＲｖ６パケットをＳＦデバイスに送信する。さらに、ＳＦＦが制御フラグをＳＲｖ６パケットに含めることで、制御フラグはＩＰｖ６拡張ヘッダをオフセットする必要があるシナリオを識別するのに用いられるようになる。ＳＦデバイスは、ＳＲｖ６パケットを受信した後に、制御フラグに基づいてＳＲｖ６パケットのＩＰｖ６拡張ヘッダを直接的にオフセットしてＳＲＨを省略する。この方法を用いると、ＳＦＦはＳＲｖ６ ＳＦＣプロキシ機能をサポートする必要がない。具体的には、パケット転送プロセスにおいて、ＳＦＦはＳＲＨを取り除いてＳＲＨを復元するという段階を行う必要がないため、ＳＦＦを転送プレーンに実装するのが大幅に簡略化される。さらに、ＳＦＦはｃａｃｈｅの生成または維持を必要としないので、ｓｔａｔｅｌｅｓｓ転送プレーンが実装され得る。ＳＦデバイスでは、ＳＦデバイスはＳＲｖ６およびＥｎｄ．ＡＮ ＳＩＤ機能を実装することなく、ＳＲｖ６のＳＦＣ機能を実装できる。

【0012】

任意選択で、制御フラグはさらに、ＳＦＦにパケットを戻すプロセスにおいてＩＰｖ６拡張ヘッダを戻すようＳＦデバイスに指示するのに用いられ、ＳＦＦが第２のＳＲｖ６パケットをＳＦデバイスに送信することの後に、本方法はさらに以下のことを含んでいる。

【0013】

ＳＦＦはＳＦデバイスから第３のＳＲｖ６パケットを受信し、第３のＳＲｖ６パケットにはＩＰｖ６拡張ヘッダが含まれており、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じＳＲＨを有している。ＳＦＦは、第３のＳＲｖ６パケットのＳＲＨに基づいて、第３のＳＲｖ６パケットに対して転送処理を行う。

【0014】

任意選択で、第３のＳＲｖ６パケットは、ＳＦデバイスがサービス処理を行うことで取得されるパケットである。

【0015】

任意選択で、第２のＳＲｖ６パケットにはホップバイホップオプションヘッダが含まれており、ホップバイホップオプションヘッダには制御フラグが含まれている。

【0016】

ホップバイホップオプションヘッダは常にＩＰｖ６パケットの最初のＩＰｖ６拡張ヘッダとして用いられるため、ホップバイホップオプションヘッダがＳＦデバイスにより容易に解析されることで、ＳＦデバイスは、ホップバイホップオプションヘッダに基づいて制御フラグおよびターゲット情報を識別して、関連する処理を行うことができるようになる。

【0017】

任意選択で、ホップバイホップオプションヘッダにはタイプ－長さ－値（ＴＬＶ）が含まれており、ＴＬＶは制御フラグを搬送するのに用いられる。

【0018】

任意選択で、制御フラグは第２のＳＲｖ６パケットのＳＲＨをオフセットするようＳＦデバイスに指示するのに用いられる、または、制御フラグは第２のＳＲｖ６パケットのＳＲＨとＳＲＨ以外の別のＩＰｖ６拡張ヘッダとをオフセットするようＳＦデバイスに指示するのに用いられる。別のＩＰｖ６拡張ヘッダは、第２のＳＲｖ６パケットにおいて制御フラグの後に続く。

【0019】

任意選択で、第２のＳＲｖ６パケットにはさらにターゲット情報が含まれており、ターゲット情報は、ＳＦデバイスがサービス処理を行うときに用いる必要がある情報であり、ターゲット情報は以下の方式で取得される。すなわち、ＳＦＦは第１のＳＲｖ６パケットのＳＲＨからターゲット情報を取得する。

【0020】

サービス処理のために、ＳＦデバイスは、ＳＲＨにカプセル化されているいくつかの情報を認識する必要があり得る。しかしながら、ＳＦデバイスは通常、ＳＲＨを識別できない。その結果、ＳＲＨのサービス情報を取得できないため、ＳＦデバイスはＳＲＨのサービス情報に基づいてサービス処理を行うことができない。その代わりに、ＳＦＦがＳＲＨを解析し、ＳＲＨに含まれているサービス情報をＳＦＦがＳＦデバイスに渡すことで、ＳＦデバイスはＳＲＨに含まれているサービス情報を取得できるようになる。さらに、ＳＦデバイスはＳＲＨを解析する必要がない。この任意選択の方式は、ＳＦデバイスがＳＲＨのサービス情報に基づいてサービス処理を行うという要件を満たしており、この方式でＳＲｖ６－ｕｎａｗａｒｅのＳＦデバイスがＳＲＨのサービス情報に基づいてサービス処理を行うことができるため、応用範囲が広がる。

【0021】

任意選択で、ＳＦＦは第１のＳＲｖ６パケットのＳＲＨからサービス情報を取得し、サービス情報に基づいてマッピング関係情報に照会してターゲット情報を取得する。マッピング関係情報は、サービス情報とターゲット情報との対応関係を格納している。

【0022】

ＳＦＦは、ＳＲＨにあるサービス情報をＳＦデバイスが識別可能なターゲット情報にマッピングし、このターゲット情報をＳＦデバイスに送信される第２のＳＲｖ６パケットに含める。これにより、サービス情報はＳＦデバイスに理解される形態でＳＦデバイスに渡されるようになり、ＳＦデバイスはターゲット情報に基づいてサービス処理を行うことができる。これにより、ＳＦデバイスがＳＲＨのサービス情報を識別せず、サービス情報に基づくサービス処理を行うことができないというケースが回避され、ＳＦデバイスがＳＲＨのサービス情報に基づいてサービス処理を行うという要件が満たされる。さらに、ＳＲｖ６－ｕｎａｗａｒｅのＳＦデバイスに方式２を適用できるので、応用範囲が広がる。

【0023】

任意選択で、ターゲット情報には、サービス機能チェーン（ＳＦＣ）メタデータおよび仮想プライベートネットワークＩＤ（ＶＰＮ ＩＤ）のうちの少なくとも一方が含まれている。あるいは、サービス情報にはＳＦＣメタデータおよびＶＰＮ ＩＤのうちの少なくとも一方が含まれている。

【0024】

任意選択で、ターゲット情報および制御情報は、第２のＳＲｖ６パケットの同じＴＬＶに位置している。

【0025】

第２態様によれば、ＳＲｖ６サービス機能チェーンでパケットを処理する方法が提供される。本方法では、ＳＦデバイスが第２のインターネットプロトコルバージョン６を介したセグメントルーティング（ＳＲｖ６）パケットをサービス機能転送器（ＳＦＦ）から受信する。第２のＳＲｖ６パケットには制御フラグが含まれており、制御フラグは、第２のＳＲｖ６パケットにおいて制御フラグの後に続くインターネットプロトコルバージョン６（ＩＰｖ６）拡張ヘッダをオフセットするようＳＦデバイスに指示するのに用いられ、第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダ（ＳＲＨ）が含まれている。ＳＦデバイスは制御フラグに基づいて、第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダをオフセットする。

【0026】

任意選択で、制御フラグはさらに、ＳＦＦにパケットを戻すプロセスにおいて、ＩＰｖ６拡張ヘッダを戻すようＳＦデバイスに指示するのに用いられ、本方法はさらに、ＳＦデバイスが制御フラグに基づいてＳＦＦに第３のＳＲｖ６パケットを送信する段階を含み、第３のＳＲｖ６パケットにはＩＰｖ６拡張ヘッダが含まれており、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じＳＲＨを有している。

【0027】

任意選択で、第３のＳＲｖ６パケットは、ＳＦデバイスがサービス処理を行うことで取得されるパケットである。

【0028】

任意選択で、第２のＳＲｖ６パケットにはホップバイホップオプションヘッダが含まれており、ホップバイホップオプションヘッダには制御フラグが含まれている。

【0029】

任意選択で、ホップバイホップオプションヘッダにはタイプ－長さ－値（ＴＬＶ）が含まれており、ＴＬＶは制御フラグを搬送するのに用いられる。

【0030】

任意選択で、制御フラグは第２のＳＲｖ６パケットのＳＲＨをオフセットするようＳＦデバイスに指示するのに用いられる、または制御フラグは第２のＳＲｖ６パケットのＳＲＨとＳＲＨ以外の別のＩＰｖ６拡張ヘッダとをオフセットするようＳＦデバイスに指示するのに用いられる。別のＩＰｖ６拡張ヘッダは、第２のＳＲｖ６パケットにおいて制御フラグの後に続く。

【0031】

任意選択で、第２のＳＲｖ６パケットにはさらにターゲット情報が含まれており、ターゲット情報は、ＳＦデバイスがサービス処理を行うときに用いられる必要がある情報であり、サービス処理を行うことは、ターゲット情報に基づいてサービス処理を行うことを含んでいる。

【0032】

任意選択で、ターゲット情報には、サービス機能チェーン（ＳＦＣ）メタデータおよび仮想プライベートネットワークＩＤ（ＶＰＮ ＩＤ）のうちの少なくとも一方が含まれている。

【0033】

任意選択で、ターゲット情報および制御情報は、第２のＳＲｖ６パケットの同じＴＬＶに位置している。

【0034】

第３態様によれば、ＳＲｖ６サービス機能チェーンでパケットを転送する方法が提供される。本方法は、サービス機能転送器（ＳＦＦ）が第１のインターネットプロトコルバージョン６を介したセグメントルーティング（ＳＲｖ６）パケットを受信する段階を含み、第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ（Ｅｎｄ．ＰＴ．ＳＩＤ）が含まれており、Ｅｎｄ．ＰＴ．ＳＩＤは、セグメントルーティングヘッダ（ＳＲＨ）を取り除くことなく第１のＳＲｖ６パケットをサービス機能（ＳＦ）デバイスに転送するようＳＦＦに指示するのに用いられる。ＳＦＦは、Ｅｎｄ．ＰＴ．ＳＩＤと第１のＳＲｖ６パケットとに基づいて第２のＳＲｖ６パケットを生成し、第２のＳＲｖ６パケットのインターネットプロトコルバージョン６（ＩＰｖ６）拡張ヘッダにはＳＲＨが含まれており、ＳＦＦは第２のＳＲｖ６パケットをＳＦデバイスの第１のインタフェースに送信し、ＳＦデバイスは第１のインタフェースを通じて受信したパケットのＩＰｖ６拡張ヘッダをオフセットするように構成されている。

【0035】

以上では、ＳＲｖ６サービス機能チェーンを実装する方法を提供している。Ｅｎｄ．ＰＴ．ＳＩＤを提供して用いるのは、ＳＦＦがＳＲＨを取り除くことなくＳＲｖ６パケットをＳＦデバイスに転送するのを識別するためである。Ｅｎｄ．ＰＴ．ＳＩＤに基づいて、ＳＦＦは、ＳＲｖ６パケットのＳＲＨを取り除くのではなく、このＳＲｖ６パケットをＳＦデバイスに送信する。さらに、ＳＦデバイスに対して指定されたインバウンドインタフェースが、ＩＰｖ６拡張ヘッダをオフセットする必要があるシナリオを識別するのに用いられる。ＳＦＦは、ＳＦデバイスに対して指定されたインバウンドインタフェースにＳＲｖ６パケットを送信する。ＳＦデバイスは、指定されたインバウンドインタフェースを通じてＳＲｖ６パケットを受信した後に、ＳＲｖ６パケットのＩＰｖ６拡張ヘッダを直接的にオフセットして、サービス処理のためにＳＲＨを省略する。この方法を用いると、ＳＦＦはＳＲｖ６のＳＦＣプロキシ機能をサポートする必要がない。具体的には、パケット転送プロセスにおいて、ＳＦＦはＳＲＨを取り除いてＳＲＨを復元するという段階を行う必要がないため、ＳＦＦを転送プレーンに実装するのが大幅に簡略化される。さらに、ＳＦＦはｃａｃｈｅの生成または維持を必要としないので、ｓｔａｔｅｌｅｓｓ転送プレーンが実装され得る。ＳＦデバイスでは、ＳＦデバイスはＳＲｖ６およびＥｎｄ．ＡＮ ＳＩＤ機能を実装することなく、ＳＲｖ６のＳＦＣ機能を実装できる。

【0036】

第４態様によれば、ＳＲｖ６サービス機能チェーンでパケットを処理する方法が提供される。本方法は、サービス機能（ＳＦ）デバイスが第２のインターネットプロトコルバージョン６を介したセグメントルーティング（ＳＲｖ６）パケットを第１のインタフェースを通じてサービス機能転送器（ＳＦＦ）から受信する段階を含む。ＳＦデバイスは、第１のインタフェースを通じて受信したパケットのインターネットプロトコルバージョン６（ＩＰｖ６）拡張ヘッダをオフセットするように構成されており、第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダ（ＳＲＨ）が含まれている。ＳＦデバイスは第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダをオフセットする。

【0037】

第５態様によれば、ＳＲｖ６サービス機能チェーンでパケットを転送する方法が提供される。本方法は、サービス機能転送器（ＳＦＦ）が第１のインターネットプロトコルバージョン６を介したセグメントルーティング（ＳＲｖ６）パケットを受信する段階を含む。第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ（Ｅｎｄ．ＰＴ．ＳＩＤ）が含まれており、Ｅｎｄ．ＰＴ．ＳＩＤは、セグメントルーティングヘッダ（ＳＲＨ）を取り除くことなく第１のＳＲｖ６パケットをサービス機能（ＳＦ）デバイスに転送するようＳＦＦに指示するのに用いられる。ＳＦＦはＥｎｄ．ＰＴ．ＳＩＤおよび第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成し、第２のＳＲｖ６パケットのインターネットプロトコルバージョン６（ＩＰｖ６）拡張ヘッダにはＳＲＨが含まれている。ＳＦＦは第２のＳＲｖ６パケットをＳＦデバイスに送信し、ＳＦデバイスは、アクセス制御リスト（ＡＣＬ）のマッチング条件を満たしているパケットのＩＰｖ６拡張ヘッダをオフセットするように構成されている。

【0038】

以上では、ＳＲｖ６サービス機能チェーンを実装する方法を提供している。Ｅｎｄ．ＰＴ．ＳＩＤを提供して用いるのは、ＳＦＦがＳＲＨを取り除くことなくＳＲｖ６パケットをＳＦデバイスに転送するのを識別するためである。Ｅｎｄ．ＰＴ．ＳＩＤに基づいて、ＳＦＦは、ＳＲｖ６パケットのＳＲＨを取り除くのではなく、このＳＲｖ６パケットをＳＦデバイスに送信する。さらに、ＳＦデバイスに設定されるＡＣＬが、ＩＰｖ６拡張ヘッダをオフセットする必要があるシナリオを識別するのに用いられる。ＳＦデバイスがＳＲｖ６パケットを受信した後に、ＳＲｖ６パケットがＡＣＬのマッチング条件を満たしているとＳＦデバイスが判定した場合、ＳＦデバイスは、ＳＲｖ６パケットのＩＰｖ６拡張ヘッダを直接的にオフセットしてＳＲＨを省略する。この方法を用いると、ＳＦＦはＳＲｖ６のＳＦＣプロキシ機能をサポートする必要がない。具体的には、パケット転送プロセスにおいて、ＳＦＦはＳＲＨを取り除いてＳＲＨを復元するという段階を行う必要がないため、ＳＦＦを転送プレーンに実装するのが大幅に簡略化される。さらに、ＳＦＦはｃａｃｈｅの生成または維持を必要としないので、ｓｔａｔｅｌｅｓｓ転送プレーンが実装され得る。ＳＦデバイスでは、ＳＦデバイスはＳＲｖ６およびＥｎｄ．ＡＮ ＳＩＤ機能を実装することなく、ＳＲｖ６のＳＦＣ機能を実装できる。

【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】

【図1】本願の一実施形態によるＳＲｖ６パケットの概略図である。

【0066】

【図2】本願の一実施形態によるＳＲＨの概略図である。

【0067】

【図3】本願の一実施形態による、パケットのＩＰｖ６宛先アドレスの変換概略図である。

【0068】

【図4】本願の一実施形態によるＳＲｖ６ ＳＩＤの概略図である。

【0069】

【図5】本願の一実施形態によるＳＲｖ６ Ｅｎｄ ＳＩＤの概略図である。

【0070】

【図6】本願の一実施形態によるＥｎｄ ＳＩＤベースの転送プロセスの概略図である。

【0071】

【図7】本願の一実施形態によるＳＲｖ６ ＳＦＣ実装原理の概略図である。

【0072】

【図8】本願の一実施形態によるＳＲプロキシの概略図である。

【0073】

【図9】本願の一実施形態による静的なＳＲプロキシの概略図である。

【0074】

【図10】本願の一実施形態による転送シナリオの概略図である。

【0075】

【図11】本願の一実施形態によるＳＲｖ６ ＳＦＣのジレンマ分析の概略図である。

【0076】

【図12】本願の一実施形態によるシステムアーキテクチャ１００の概略図である。

【0077】

【図13】本願の一実施形態による、ＳＲｖ６サービス機能チェーンでパケットを転送する方法２００のフローチャートである。

【0078】

【図14】本願の一実施形態による、ＳＲｖ６パケットの挿入モードおよびカプセル化モードの概略図である。

【0079】

【図15】本願の一実施形態による、ＳＲｖ６サービス機能チェーンでのパケット転送の概略図である。

【0080】

【図16】本願の一実施形態による、制御フラグを含むホップバイホップオプションヘッダの概略図である。

【0081】

【図17】本願の一実施形態による、制御フラグおよびターゲット情報を含むホップバイホップオプションヘッダの概略図である。

【0082】

【図18】本願の一実施形態による、ＳＲｖ６サービス機能チェーンでパケットを転送する方法３００のフローチャートである。

【0083】

【図19】本願の一実施形態による、ＳＲｖ６サービス機能チェーンでパケットを転送する方法４００のフローチャートである。

【0084】

【図20】本願の一実施形態によるＳＦＦの構造概略図である。

【0085】

【図21】本願の一実施形態によるＳＦデバイスの構造概略図である。

【0086】

【図22】本願の一実施形態によるＳＦＦの構造概略図である。

【0087】

【図23】本願の一実施形態によるＳＦデバイスの構造概略図である。

【0088】

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

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

【0089】

本願の目的、技術的解決手段、および利点をより明確にするために、以下では添付図面を参照しながら本願の実装形態についてさらに詳細に説明する。

【0090】

本願の本実施形態において提供される、インターネットプロトコルバージョン６を介したセグメントルーティング（英名：ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６ ｆｏｒ Ｓｅｇｍｅｎｔ Ｒｏｕｔｉｎｇ、略してＳＲｖ６）サービス機能チェーンでパケットを転送する方法が、セグメントルーティング（英名：ｓｅｇｍｅｎｔ ｒｏｕｔｉｎｇ、略してＳＲ）分野におけるサービス機能チェーン（英名：ｓｅｒｖｉｃｅ ｆｕｎｃｔｉｏｎ ｃｈａｉｎ、略してＳＦＣ、サービスチェーンとも呼ばれる）シナリオに適用され得る。以下では、ＳＲ技術、ＳＦＣ技術、およびＳＲ ＳＦＣ技術について別々に簡潔に説明する。

【0091】

ＳＲとは、ソースルーティング転送モードに基づくトンネリング技術である。ＳＲ技術には、２つのデータプレーンが含まれており、マルチプロトコルラベルスイッチング（Ｍｕｌｔｉ－Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ、ＭＰＬＳ）およびインターネットプロトコルバージョン６（英名：ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６、略してＩＰｖ６）である。この２つのデータプレーンはそれぞれ、ＳＲ ＭＰＬＳおよびＳＲｖ６と呼ばれている。ＳＲｖ６は通常、ＳＩＤリスト（ＳＩＤ ｌｉｓｔ、ｓｅｇｍｅｎｔ ｌｉｓｔまたはＳＩＤリストとも呼ばれる）を搬送するためのセグメントルーティングヘッダ（英名：Ｓｅｇｍｅｎｔ Ｒｏｕｔｉｎｇ Ｈｅａｄｅｒ、略してＳＲＨ）を用いる。ＳＩＤ ｌｉｓｔは、ＩＰｖ６パケットの転送経路を指定する。ＳＲＨとは、ＩＰｖ６ルーティングヘッダ（ＩＰｖ６ Ｒｏｕｔｉｎｇ Ｈｅａｄｅｒ）である。例えば、ＳＲＨのルーティングタイプ（Ｒｏｕｔｉｎｇ Ｔｙｐｅ）の値が４である。

【0092】

ＳＲの設計思想には、サービスフローの先頭ノードに関するフローごとの（ｐｅｒ－ｆｌｏｗ）状態を維持することが含まれており、通過ノードおよび末尾ノードのｐｅｒ－ｆｌｏｗ状態を維持する必要性はない。サービスフローの先頭ノードは、ＳＲトンネルの先頭ノードである。ＳＲポリシー（ＳＲ ｐｏｌｉｃｙ）とは、ｐｅｒ－ｆｌｏｗ状態を維持する機能である。

【0093】

セグメント（Ｓｅｇｍｅｎｔ、セグメント化とも呼ばれる）またはセグメントＩＤ（Ｓｅｇｍｅｎｔ ＩＤ、ＳＩＤ）とは、ＳＲの中核要素である。Ｓｅｇｍｅｎｔの定義には、Ｓｅｇｍｅｎｔが任意のトポロジー、命令、またはサービスを表すことが含まれている。

【0094】

ＳＲトンネル（ＳＲ Ｔｕｎｎｅｌ）とは、Ｓｅｇｍｅｎｔ ｌｉｓｔを先頭ノードのパケットヘッダにカプセル化することで形成されるトンネルである。ＳＲトンネルは、トラフィックエンジニアリング（Ｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇ、ＴＥ）トンネルアプリケーションに用いられてもよく、運用・管理・保守（Ｏｐｅｒａｔｉｏｎｓ， Ａｄｍｉｎｉｓｔｒａｔｉｏｎ， ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ、ＯＡＭ）検出および高速リルート（Ｆａｓｔ Ｒｅｒｏｕｔｅ、ＦＲＲ）などに用いられてもよい。ＳＲトンネルは、分散方式で確立されても、集中方式で確立されてもよい。分散方式は、インターミディエイト・システム・ツー・インターミディエイト・システム（Ｉｎｔｅｒｍｅｄｉａｔｅ ｓｙｓｔｅｍ ｔｏ ｉｎｔｅｒｍｅｄｉａｔｅ ｓｙｓｔｅｍ、ＩＳ－ＩＳ）、オープン・ショーテスト・パス・ファースト（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ、ＯＳＰＦ）、または境界ゲートウェイプロトコル（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ、ＢＧＰ）を用いてＳＩＤが広告される方式を指す。集中方式は、ＳＤＮコントローラ（英名：ＳＤＮ ｃｏｎｔｒｏｌｌｅｒ）が境界ゲートウェイプロトコルリンクステート（ｂｏｒｄｅｒ ｇａｔｅｗａｙ ｐｒｏｔｏｃｏｌ－ｌｉｎｋ ｓｔａｔｅ、ＢＧＰ－ＬＳ）または経路計算要素通信プロトコル（ｐａｔｈ ｃｏｍｐｕｔａｔｉｏｎ ｅｌｅｍｅｎｔ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐｒｏｔｏｃｏｌ、ＰＣＥＰ）を用いて経路を収集し計算する方式を指す。ここでのトンネルは概して、２点間の一連のエンドツーエンド経路を指し、この２点はそれぞれ、トンネルの始点およびトンネルの終点である。トンネルの始点は先頭ノードであり、トンネルの終点は末尾ノードである。トンネルは、１つの経路または複数の経路を含む。

【0095】

ＳＲＨは、ルーズソースルーティングモードを用いる。具体的には、転送経路上のあらゆるホップがＳＲＨをサポートし解析する必要はなく、ＳＲＨのＳＩＤ ｌｉｓｔが経路上のあらゆるホップノードを含む必要はない。ＳＲｖ６トンネルパケットが、ＳＲＨを含まなくてもよい。

【0096】

先頭ノードは、２つの方式でＳＲトンネルのＳＩＤ ｌｉｓｔを指定できる。一方の方式は明確な候補経路（Ｅｘｐｌｉｃｉｔ ｃａｎｄｉｄａｔｅ ｐａｔｈ）であり、他方の方式は動的な候補経路（Ｄｙｎａｍｉｃ ｃａｎｄｉｄａｔｅ ｐａｔｈ）である。さらに、バインディングＳＩＤ（Ｂｉｎｄｉｎｇ ＳＩＤ、ＢＳＩＤ）が、ＳＲポリシーに対してトラフィックを誘導（ｓｔｅｅｒ）するのに用いられてよく、これにより、いくつかのネットワークのトポロジー詳細が保護され、ハードウェアチップのＭＳＤ仕様の不足が回避される。

【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】

例えば、以下の表１を参照されたい。表１は、ローカルＳＩＤテーブルの一例である。パケットのＩＰｖ６ ＤＡが１０：１：：１：０／１２８であると仮定する。ＳＲノードは、ＳＲｖ６パケットを受信すると、ＳＲｖ６パケットのＩＰｖ６ ＤＡに基づいて表１に照会し、１０：１：：１：０／１２８のＳＩＤタイプがＥｎｄであると判定する。次に、ＳＲノードは、１０：１：：１：０／１２８に基づいてＩＰｖ６ルーティング転送テーブルに照会を続け、１０：１：：１：０／１２８に基づいてＩＰｖ６ルーティング転送テーブルと一致したアウトバウンドインタフェースおよびネクストホップに基づいてパケットを転送する。

【表1】

【0146】

表１の表見出しである［Ｍｙ Ｌｏｃａｌ－ＳＩＤ Ｅｎｄ Ｆｏｒｗａｒｄｉｎｇ Ｔａｂｌｅ］は、ＳＲｖ６ ＥｎｄのローカルＳＩＤテーブルを示している。ＦｕｎｃＴｙｐｅは、Ｆｕｎｃｔｉｏｎタイプを示している。Ｆｌａｖｏｒは特性を示しており、例えば、ＳＲＨの最後から２番目のセグメントＰＯＰ（ｐｅｎｕｌｔｉｍａｔｅ ｓｅｇｍｅｎｔ ＰＯＰ ｏｆ ｔｈｅ ＳＲＨ、略してＰＳＰ）である。Ｌｏｃａｔｏｒ ＩＤは、Ｌｏｃａｔｏｒに割り当てられたＩＤを示している。

【0147】

図６を参照されたい。図６は、本願の一実施形態によるＥｎｄ ＳＩＤベースの転送プロセスの概略図である。この転送プロセスは以下のことを含んでいる。ＳＲＨがノードＡのパケットにプッシュされ、ＳＲＨの経路情報が＜Ｚ：：，Ｆ：：，Ｄ：：，Ｂ：：＞であり、パケットのＩＰｖ６ヘッダの宛先アドレスが［Ｂ：：］である。パケットが通過ノード（例えば、ノードＢまたはノードＤ）を通過するたびに、通過ノードはパケットのＩＰｖ６ ＤＡに基づいてＬｏｃａｌ ＳＩＤテーブルに照会する。タイプがＥｎｄであると通過ノードが判定すると、通過ノードはＩＰｖ６ルーティング転送テーブルに照会を続け、ＩＰｖ６ルーティング転送テーブルに照会されたアウトバウンドインタフェースとネクストホップとに基づいて転送を行う。同時に、ＳＬ値が１だけ減少し、ＩＰｖ６ ＤＡが一度変換される。パケットがノードＦに到着すると、ノードＦは、パケットのＩＰｖ６ヘッダの宛先アドレスに基づいてＬｏｃａｌ ＳＩＤテーブルに照会し、タイプがＥｎｄであると判定し、ＩＰｖ６ルーティング転送テーブルに照会を続け、ＩＰｖ６ルーティング転送テーブルに照会されたアウトバウンドインタフェースに基づいて転送を行う。同時に、ＳＬ値は０に減少し、ＩＰｖ６ ＤＡは［Ｚ：：］に変更される。この場合、経路情報＜Ｚ：：，Ｆ：：，Ｄ：：，Ｂ：：＞に意味はない。したがって、ＰＳＰ特性を用いて、ノードＦはＳＲＨを除去し、次いでＳＲＨを除去したパケットをノードＺに転送する。

【0148】

以下では、ＳＦＣ技術を簡潔に説明する。

【0149】

従来の電気通信ネットワークによるサービスチェーンでは、データパケットが、ネットワーク上を伝送するときに様々なサービスノードを通過する必要があることが多い。これにより、ネットワークは、事前の計画に従って安全且つ高速で安定したサービスをユーザに提供できることが保証される。これらのサービスノードとしては、限定されることはないが、ファイアウォール（Ｆｉｒｅ Ｗａｌｌ、ＦＷ）、負荷分散装置（Ｌｏａｄ Ｂａｌａｎｃｅｒ、ＬＢ）、および侵入防御システム（Ｉｎｔｒｕｓｉｏｎ Ｐｒｅｖｅｎｔｉｏｎ Ｓｙｓｔｅｍ、ＩＰＳ）などが挙げられる。ネットワークトラフィックは、必要なサービスを実現するために、サービスロジックに必要な指定順序でこれらのサービスノードを通過する必要がある。しかしながら、従来の電気通信ネットワークによるサービスチェーンでは、複雑なコマンドラインをハードウェアデバイスに入力することで実現されるポリシー誘導の維持および変更が難しい。さらに、ＶＡＳサーバの展開および物理的位置が制限されている。サービス機能チェーン（英名：ｓｅｒｖｉｃｅ ｆｕｎｃｔｉｏｎ ｃｈａｉｎ、略してＳＦＣ、サービスチェーンとも呼ばれる）の出現によって、従来の電気通信ネットワークによるサービスチェーンの問題が効率的に解決される。

【0150】

ＳＦＣとは、アプリケーション層に順序付きサービスを提供するのに用いられる技術である。ＳＦＣは、ネットワークデバイスのサービスを論理的に接続して、順序付きサービス組み合わせを形成するのに用いられる。サービス機能経路情報を元パケットに追加することで、ＳＦＣは、指定された経路に沿ってパケットがサービスデバイスを順番に通過することを可能にする。従来のネットワークアーキテクチャでは、ＳＦＣ技術が仮想ネットワークを用いてサービスをうまく統合することにより、前述の問題を解決する。ネットワークデバイス同士の大規模な結合により引き起こされる柔軟性のないサービス展開を解決するために、ＳＦＣは、オーバーレイ（Ｏｖｅｒｌａｙ）トポロジーに基づくネットワークプランニングから独立している。基本的な物理ネットワークトポロジーが変わったときに、サービスノードの展開および起動が影響を受けることはない。ベアラネットワークルートが到達可能である限り、仮想サービス機能チェーンを物理サービスノードにマッピングすることが可能である。低い転送効率を解決するために、ＳＦＣは情報をパケットヘッダにカプセル化する。これにより、サービス機能経路上にある各ノードは互いに情報を渡すことができるようになる。この情報を用いると、データに対する動的で柔軟性のあるポリシー処理を、サービス機能チェーン全体で行うことができる。サービスデバイスを共有できないという問題を解決するために、ＳＦＣは転送プレーンとサービスプレーンとを分離している。このようにして、ユーザがサービスデバイスを複数のリソースプールに分割でき、全てのデータトラフィックが分類され、次いでサービス機能チェーンを通じて複数のサービスデバイスに誘導される。したがって、データトラフィックのオフロードにより、サービスデバイスがピークトラフィックを処理する能力に対する性能要件が低下し、サービスデバイスの各リソースが共有される。

【0151】

ＳＦＣデータプレーンにあるネットワークエレメントタイプとしては、サービス分類器（英名：Ｓｅｒｖｉｃｅ Ｃｌａｓｓｉｆｉｅｒ、略してＳＣ）、サービス機能転送器（英名：Ｓｅｒｖｉｃｅ Ｆｕｎｃｔｉｏｎ Ｆｏｒｗａｒｄｅｒ、略してＳＦＦ）、ＳＦＣプロキシ（ＳＦＣ Ｐｒｏｘｙ）、およびサービス機能（英名：ｓｅｒｖｉｃｅ ｆｕｎｃｔｉｏｎ、略してＳＦ）デバイスなどが挙げられる。

【0152】

ＳＣがＳＦＣドメインの入口に配置されている。パケットがＳＦＣドメインに入った後に、トラフィックが最初に分類される。分類の粒度が、分類器の能力およびＳＦＣポリシーにより決定される。分類ルールが大雑把であっても、詳細であってもよい。例えば、大雑把なケースでは、ポートの全パケットがＳＦＣルールを満たしている場合、これらのパケットはサービス機能経路１に沿って伝送される。詳細なケースでは、５倍の要件を満たしているパケットのみが、ＳＦＣルールを満たすことができ、サービス機能経路２に沿って伝送される。

【0153】

ＳＦデバイスが、パケットに対してサービス処理を行うように構成されている。例えば、ＳＦデバイスは、限定されることはないが、ファイアウォール、負荷分散装置、アプリケーションアクセラレータ、合法的傍受（ＬＩ）、ネットワークアドレス変換（英名：Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ、略してＮＡＴ）、帯域幅制御、ウイルス検出、クラウドストレージ、ディープパケットインスペクション（英名：Ｄｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ、略してＤＰＩ）、侵入検出、または侵入防止などであってもよい。ＳＦデバイスの物理エンティティが、コンピューティングデバイスであってよい。コンピューティングデバイスは、限定されることはないが、サーバ、ホスト、パーソナルコンピュータ、ネットワークデバイス、または端末デバイスであってもよい。いくつかの実現可能な実施形態では、ＳＦデバイスは、次のような方式で実装されてよい。すなわち、仮想マシンまたはコンテナがＸ８６アーキテクチャを用いる汎用サーバで作動し、アプリケーションプログラムが仮想マシンまたはコンテナで作動し、アプリケーションプログラムはサービス機能を処理するのに用いられてよい。ＳＦがＳＲｖ６カプセル化を認識できるかどうかに基づいて、ＳＦは、ＳＲｖ６カプセル化対応のＳＦ（ＳＲｖ６－ａｗａｒｅ ＳＦ）とＳＲｖ６カプセル化未対応のＳＦ（ＳＲｖ６－ｕｎａｗａｒｅ ＳＦ）とに分類される。ＳＲｖ６－ａｗａｒｅのＳＦは、受信したＳＲｖ６パケットを識別して処理する。ＳＲｖ６－ｕｎａｗａｒｅのＳＦは、ＳＲｖ６パケットを識別しないので、受信したＳＲｖ６パケットを破棄する。

【0154】

ＳＦＦが、ネットワークから受信したパケットを、ＳＦＦと関連付けられたいくつかのＳＦに転送する。この転送は、ＳＲＨにカプセル化された情報に基づいている。ＳＦは、パケットを処理した後に、このパケットを同じＳＦＦに戻し、ここで、パケットをネットワークに送り戻すかどうかが最終的に判定される。ＳＦＦの物理エンティティとは、ネットワークデバイス、例えば、ルータ（Ｒｏｕｔｅｒ）であってもスイッチであってもよい。

【0155】

ＳＦＣ分野では、ＳＦデバイスが一般に、付加価値サービスデバイス（Ｖａｌｕｅ－ａｄｄｅｄ Ｓｅｒｖｉｃｅ、ＶＡＳ）と呼ばれており、ＳＦＦが一般に「Ｒｏｕｔｅｒ」と呼ばれている。本願のいくつかの実施形態の本文および図面では、ＳＦデバイスを指すのに「ＶＡＳ」という言葉を用いており、ＳＦＦを指すのに「Ｒｏｕｔｅｒ」という言葉を用いている。

【0156】

ＳＦＣ ｐｒｏｘｙが、ＳＦＦとＳＦＦに関連付けられたいくつかのＳＲｖ６－ｕｎａｗａｒｅのＳＦとの間に位置している。ＳＦＣプロキシはＳＦに代わって、ＳＦＦからパケットを受信し、ＳＲｖ６カプセル化情報を削除する。ＳＦＣプロキシは、ローカルロジックコンポーネントを通じてＳＲｖ６－ｕｎａｗａｒｅのＳＦにパケットを送信し、ＳＲｖ６－ｕｎａｗａｒｅのＳＦから送り返されるパケットを受信し、ＳＲｖ６カプセル化情報をパケットに追加し、処理するためにパケットをＳＦＦに送信する。ＳＦＦの観点では、ＳＦＣプロキシはＳＲｖ６－ａｗａｒｅのＳＦに相当する。通常、ＳＦＣ ｐｒｏｘｙおよびＳＦＦは同じハードウェアデバイスに統合されている。

【0157】

以下では、ＳＲｖ６ ＳＦＣ技術について簡潔に説明する。

【0158】

ＳＲｖ６技術の発展に伴い、ＳＲｖ６ ＳＦＣの解決手段がサービス機能チェーンを実装するための優れた解決手段になっている。ＳＲの設計思想とＳＲ ＳＩＤのセマンティクスとに基づいて、ステートレスなサービス機能チェーン（Ｓｔａｔｅｌｅｓｓ ＳＦＣ）が、トポロジー的ＳＩＤ（ｔｏｐｏｌｏｇｉｃａｌ ＳＩＤ）とサービスＳＩＤ（ｓｅｒｖｉｃｅ ＳＩＤ）とを一体的にオーケストレートすることにより実装される。現在、ＳＲ ＳＦＣの実装フレームワークの主な特徴として、以下の特徴が挙げられる。

【0159】

特徴１：ｔｏｐｏｌｏｇｉｃａｌ ＳＩＤおよびｓｅｒｖｉｃｅ ＳＩＤを一体的にオーケストレートして、Ｓｔａｔｅｌｅｓｓ ＳＦＣを実装する。

【0160】

特徴２：ＳＲ対応（ＳＲ－ａｗａｒｅ）のＳＦデバイスの場合、ＳＦデバイスは基本的なＳＲｖ６機能とＳＲｖ６ ＳＦＣのために定義されたＥｎｄ．ＡＮ ＳＩＤタイプとを実装する必要がある。

【0161】

ＳＲ－ａｗａｒｅのＳＦは、ＳＲをサポートするデバイスを指す。Ｅｎｄ．ＡＮは、ＳＲ対応の機能（ＳＲ－ａｗａｒｅ ｆｕｎｃｔｉｏｎ （ｎａｔｉｖｅ））を示すのに用いられる。言い換えれば、Ｅｎｄ．ＡＮは、ＳＲｖ６－ａｗａｒｅのＳＦデバイスにより実装されたＳＲｖ６サービス機能チェーン機能のＳＩＤタイプを示すのに用いられる。ＳＦデバイスは、幅広い範囲の機能（例えば、ファイアウォール、フィルタ、ＤＰＩ、およびＮＡＴ）を有している。したがって、他のＳＩＤタイプと異なり、Ｅｎｄ．ＡＮには、Ｅｎｄ．ＡＳ、Ｅｎｄ．ＡＤ、およびＥｎｄ．ＡＭとして定義された特定の処理ロジックがない。通常、Ｅｎｄ．ＡＮ ＳＩＤタイプは、ＳＲｖ６デバイス（すなわちＳＦデバイス）がＥｎｄ．ＡＮ ＳＩＤタイプのＡｃｔｉｖｅ ＳＩＤを受信した場合、ＳＲｖ６デバイスはＳＦＣ関連の機能処理を行うということを示す。ＳＦデバイスの実際の処理は、具体的な実装形態および設定パラメータに依存する。Ｅｎｄ．ＡＮのＮは、ｎａｔｉｖｅと理解されてよい。

【0162】

特徴３：ＳＲ非対応（ＳＲ－ｕｎａｗａｒｅ）のＳＦデバイスの場合、ＳＦＣプロキシは、ＳＦデバイスを置き換えてＳＲＨを処理するのに用いられる。

【0163】

ＳＦＦは通常、ＳＦＣ ｐｒｏｘｙ機能も実装する。言い換えれば、ＳＦＦおよびＳＦＣ ｐｒｏｘｙは同じデバイスに統合されているので、このデバイスは、ＳＦＦ機能だけでなく、ＳＦＣ ｐｒｏｘｙ機能も実装している。ＳＲ－ｕｎａｗａｒｅのＳＦデバイスは、ＳＲ（ＳＲ－ＭＰＬＳまたはＳＲｖ６）をサポートしないデバイスを指す。

【0164】

ＳＲｖ６ ＳＦＣ技術が簡潔に上述されている。以下では、特徴２および特徴３を詳細に説明する。

【0165】

ＳＲ－ａｗａｒｅのＳＦデバイス用のＳＲｖ６ ＳＦＣ実装解決手段では、Ｅｎｄ．ＡＮ ＳＩＤはＳＲ－ａｗａｒｅのＳＦデバイスに実装され且つ展開されてよく、ＳＲｖ６ ＳＦＣはＥｎｄ．ＡＮ ＳＩＤを用いて実装される。例えば、図７を参照されたい。ＳＲｖ６ ＳＦＣの実装原理が図７に示されており、ＳＲｖ６ ＳＦＣの実装解決手段には、Ｓ１０１～Ｓ１０３が含まれている。

【0166】

Ｓ１０１：Ａｃｔｉｖｅ ＳＩＤがＥｎｄ／Ｅｎｄ．ＸであるＳＲｖ６パケットをＳＦＦが受信すると、ＳＦＦは、Ｅｎｄ／Ｅｎｄ．Ｘを用いてＳＲｖ６パケットをＳＦデバイスに転送する。ＳＦＦにより送信されたパケットのＡｃｔｉｖｅ ＳＩＤはＥｎｄ．ＡＮ ＳＩＤである。

【0167】

Ｓ１０２：ＳＦデバイスはＳＦＦにより転送されたＳＲｖ６パケットを受信し、ＳＲｖ６パケットの宛先アドレスに基づいてローカルＳＩＤテーブルに照会する。Ｅｎｄ．ＡＮタイプが一致している。ＳＦデバイスはＥｎｄ．ＡＮに基づいてトラフィック分類を行い、サービス関連の処理を完了させて、処理したＳＲｖ６パケットをＳＦＦに戻す。ＳＦデバイスから戻されたＳＲｖ６パケットのＡｃｔｉｖｅ ＳＩＤは、Ｅｎｄ．ＡＮ ＳＩＤ以外の別のＳＩＤである。図７では、Ｅｎｄ．ＡＮ ＳＩＤ以外の別のＳＩＤが、ＸＸＸのＳＩＤで表されている。

【0168】

Ｓ１０３：ＳＦＦはＳＦデバイスから戻されたＳＲｖ６パケットを受信し、ＸＸＸのＳＩＤに基づいてＳＲｖ６パケットをダウンストリームデバイスに転送する。ダウンストリームデバイスは、例えば、ＳＦＦのネクストホップＳＦＦ、または別のＳＦデバイスである。

【0169】

ＳＲｖ６ ＳＦＣの進化の最終的な目標には、ＳＦデバイスがＥｎｄ．ＡＮを実装することが含まれている。これは、ＳＲｖ６－ｏｎｌｙネットワークが実装されることを意味している。しかしながら、これには多くの時間がかかると見込まれている。ＳＦデバイスがＥｎｄ．ＡＮの転送機能（様々なポリシーおよび様々なアクション）だけでなく、制御プレーン機能（ＳＩＤの割り当ておよび広告、ならびにＳＤＮ ｃｏｎｔｒｏｌｌｅｒのノースバウンドインタフェースを含む）も実装する必要があるためである。

【0170】

ＳＲｖ６－ｏｎｌｙネットワークでは、ＳＦＦはＥｎｄ／Ｅｎｄ．Ｘなどの基本的なＳＲｖ６機能を実装するだけでよく、さらにＳＦＦはネイティブＩＰｖ６（ｎａｔｉｖｅ ＩＰｖ６）のルーティングおよび転送を実装するだけでよい。

【0171】

前述したＳＲ－ａｗａｒｅのＳＦデバイス用のＳＲｖ６ ＳＦＣ実装解決手段の場合、本解決手段は以下の問題を含む。（１）ＳＦデバイスはＳＲｖ６およびＥｎｄ．ＡＮ ＳＩＤをサポートする必要がある。（２）ライブネットワーク上にある多数の既存のＳＦデバイスにとっては実現可能ではない。

【0172】

ＳＲ－ｕｎａｗａｒｅのＳＦデバイス用のＳＲｖ６ ＳＦＣ実装解決手段では、ＳＦデバイスがＳＲ－ｕｎａｗａｒｅのＳＦデバイスである場合、ｐｒｏｘｙ ＳＩＤがＳＦＦに実装され且つ展開されてよく、ＳＲ ＳＦＣを実現するためにＳＲプロキシ（ＳＲ ｐｒｏｘｙ）機能がＳＦＦにより実装される。図８を参照されたい。図８は、ＳＲ ｐｒｏｘｙの汎用アーキテクチャを示している。ＳＲ ｐｒｏｘｙのプロセスには、以下のＳ１１１およびＳ１１２が含まれている。

【0173】

Ｓ１１１：ＳＲ ｐｒｏｘｙがアップストリームノードからのＳＲトラフィック（ＳＲ ｔｒａｆｆｉｃ、このトラフィックでは各パケットにＳＲＨが含まれている）を受信した場合、ＳＲ ｐｒｏｘｙはこのＳＲ ｔｒａｆｆｉｃをＳＦデバイスに転送する必要がある。ＳＦデバイスがＳＲ－ｕｎａｗａｒｅのＳＦデバイスであることをＳＲ ｐｒｏｘｙが検出した場合、ＳＲ ｐｒｏｘｙはＳＲＨを取り除き、次いで、アウトバウンドインタフェースを通じて非ＳＲトラフィック（Ｎｏｎ ＳＲ ｔｒａｆｆｉｃ、このトラフィックでは各パケットにＳＲＨが含まれていない）をＳｅｒｖｉｃｅに送信する。

【0174】

Ｓ１１２：ＳＲ ｐｒｏｘｙが、インバウンドインタフェース（ＩＦＡＣＥ ＩＮ）を通じて、Ｓｅｒｖｉｃｅから戻されたＮｏｎ ＳＲ ｔｒａｆｆｉｃを受信すると、ＳＲ ｐｒｏｘｙはＳＲ ｈｅａｄｅｒカプセル化を復元し、次いでＳＲ ｈｅａｄｅｒカプセル化が復元されたＳＲ ｔｒａｆｆｉｃをダウンストリームデバイスに転送する。

【0175】

ＳＲ ｐｒｏｘｙには４つのタイプがあり、これらは４つのプロキシモードとも呼ばれている。具体的には、ＳＲ ｐｒｏｘｙとして、静的プロキシ（ｓｔａｔｉｃ ｐｒｏｘｙ）、動的プロキシ（ｄｙｎａｍｉｃ ｐｒｏｘｙ）、マスカレードプロキシ（ｍａｓｑｕｅｒａｄｉｎｇ ｐｒｏｘｙ）、および共有メモリプロキシ（ｓｈａｒｅｄ－ｍｅｍｏｒｙ ｐｒｏｘｙ）が挙げられる。静的プロキシモードはＥｎｄ．ＡＳ ＳＩＤに基づいて実装される。動的プロキシモードはＥｎｄ．ＡＤ ＳＩＤに基づいて実装される。マスカレードプロキシモードはＥｎｄ．ＡＭ ＳＩＤに基づいて実装される。共有メモリプロキシモードでは、プロキシおよびＳＦデバイスは通常、同じデバイスに実装されているので、関連するＳＩＤタイプを定義する必要はない。

【0176】

以下では、静的プロキシおよび動的プロキシの原理および利点を分析する。

【0177】

図９を参照されたい。静的プロキシ方法には、以下のＳ１２１～Ｓ１２３が含まれている。

【0178】

Ｓ１２１：ＳＦＦがＳＲｖ６パケットを受信する。ＳＦＦはＳＲｖ６パケットの宛先アドレスに基づいてローカルＳＩＤテーブルに照会し、Ｅｎｄ．ＡＳが一致する。ＳＦＦは、Ｅｎｄ．ＡＳに対応するオペレーションを行う。Ｅｎｄ．ＡＳに対応するオペレーションには、以下の（１）および（２）が含まれている。

【0179】

（１）ＳＦＦはＳＲｖ６パケットのＳＲＨを取り除いて破棄する。

【0180】

（２）ＳＦＦはトンネルヘッダ（Ｔｕｎｎｅｌ ｈｅａｄｅｒ）を再カプセル化して、Ｔｕｎｎｅｌ ｈｅａｄｅｒを含むパケットをＳＦデバイスに転送する。

【0181】

Ｓ１２２：ＳＦデバイスはＳＦＦから送信されたパケットを受信し、Ｔｕｎｎｅｌ ｈｅａｄｅｒを終了させてサービス処理を実施する。サービス処理が完了した後に、ＳＦデバイスはＴｕｎｎｅｌ ｈｅａｄｅｒを再カプセル化して、このパケットをＳＦＦに戻す。

【0182】

Ｓ１２３：ＳＦＦデバイスはＳＦデバイスから送信されたパケットを受信し、Ｔｕｎｎｅｌ ｈｅａｄｅｒを終了させる。インバウンドインタフェースおよびアクセス制御リスト（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ、ＡＣＬ）に基づいて、ＳＦＦは静的設定でＳＲＨカプセル化を復元し、またＳＦＦはＳＬを取り去りパケットの転送を続ける。

【0183】

この分析を通じて分かるのは、静的プロキシ（Ｅｎｄ．ＡＳ ＳＩＤ）の解決手段の利点として、制御プレーンおよび転送プレーンが両方ともステートレスであり、実装が容易であることが挙げられるということである。この解決手段の欠点には、ＳＦＦがＳＲＨを直接的に破棄して、ＳＲＨにある動的情報の消失を引き起こすことにより、将来のＳＲｖ６進化要件（例えば、その場フロー情報テレメトリ（ｉｎ－ｓｉｔｕ Ｆｌｏｗ ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｌｅｍｅｔｒｙ、ｉＦｉｔ）、ＩＰｖ６用のアプリケーション対応ネットワーキング（Ａｐｐｌｉｃａｔｉｏｎ－ａｗａｒｅ Ｎｅｔｗｏｒｋｉｎｇ ｆｏｒ ＩＰｖ６、ＡＰＮ６）、その場運用・管理・保守（Ｉｎ－ｓｉｔｕ Ｏｐｅｒａｔｉｏｎｓ， Ａｄｍｉｎｉｓｔｒａｔｉｏｎ， ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ Ｉｎ－ｓｉｔｕ ＯＡＭ、略してＩＯＡＭ）、およびネットワークスライシング（Ｎｅｔｗｏｒｋ Ｓｌｉｃｉｎｇ））を満たせないことが含まれている。したがって、この解決手段は、比較的単純で動的性能が低いＳＲｖ６ネットワークに適用可能である。

【0184】

消失した動的情報には複数のタイプがある。例えば、図１０を参照されたい。ここには簡単なシナリオが示されている。具体的には、Ｒ１とＲ４との間に２つの異なる経路がある。一方の経路はＲ１→Ｒ２→Ｒ３→Ｒ４であり、３つのホップを通過する。他方の経路はＲ１→Ｒ５→Ｒ４であり、２つのホップを通過する。Ｒ４は、Ｅｎｄ．ＡＳ ＳＩＤ機能を実装している。パケットがＲ１からＲ４に送信されるとき、同じＩＰｖ６パケットが２つの異なる経路を通ってＲ４に到着する場合には、ＩＰｖ６ ＨｏｐＬｉｍｉｔの値が異なる。これは、Ｅｎｄ．ＡＳ ＳＩＤ処理がＲ４で行われた後に、Ｒ４がＨｏｐＬｉｍｉｔの値を復元できないためである。復元されたＨｏｐＬｉｍｉｔがユーザによって設定されるので、ＨｏｐＬｉｍｉｔの値は設定されると常に固定値になり、前述の相違を認識することも、この相違に適合することも自動的にはできない。

【0185】

動的プロキシ方法には、以下のＳ１３１～Ｓ１３３が含まれている。

【0186】

Ｓ１３１：ＳＦＦがＳＲｖ６パケットを受信する。ＳＦＦはＳＲｖ６パケットの宛先アドレスに基づいてローカルＳＩＤテーブルに照会し、Ｅｎｄ．ＡＤが一致する。ＳＦＦは、Ｅｎｄ．ＡＤに対応するオペレーションを行う。Ｅｎｄ．ＡＤに対応するオペレーションには、以下の（１）および（２）が含まれている。

【0187】

（１）ＳＦＦはＳＲｖ６パケットのＳＲＨを取り除いてキャッシュに格納する。

【0188】

（２）ＳＦＦはＴｕｎｎｅｌ ｈｅａｄｅｒを再カプセル化して、Ｔｕｎｎｅｌ ｈｅａｄｅｒを含むパケットをＳＦデバイスに転送する。

【0189】

Ｓ１３２：ＳＦデバイスはＴｕｎｎｅｌ ｈｅａｄｅｒを終了させてサービス処理を実施する。サービス処理が完了した後に、ＳＦデバイスはＴｕｎｎｅｌ ｈｅａｄｅｒを再カプセル化して、Ｔｕｎｎｅｌ ｈｅａｄｅｒを含むパケットをＳＦＦに戻す。

【0190】

Ｓ１３３：ＳＦＦはＴｕｎｎｅｌ ｈｅａｄｅｒを終了し、インバウンドインタフェースおよびＡＣＬに基づきキャッシュ（ｃａｃｈｅ）を使ってＳＲＨカプセル化を復元し、ＳＬを取り去ってパケットの転送を続ける。

【0191】

この分析を通じて分かるのは、動的プロキシ（Ｅｎｄ．ＡＤ ＳＩＤ）の解決手段の利点として、ｃａｃｈｅの存在によって動的情報が消失しないこと、および自己適応によって将来のＳＲｖ６ネットワーク進化の要件を満たせることが挙げられるということである。この解決手段の欠点としては、転送プレーンがステートフル（ｓｔａｔｅｆｕｌ）（ｃａｃｈｅ）であるため、実施が難しく、性能（容量、レート、および収束）などにある程度の負担をかけることが挙げられる。この方法は、ネットワーク上にある既存のＳＦデバイス、およびＳＲｖ６をサポートしていないＳＦデバイスにとって汎用的解決手段である。

【0192】

静的プロキシ解決手段および動的プロキシ解決手段の分析を通じて分かるのは、関連するオペレーションをＳＦＦが全て行う場合、ＳＲＨを取り除いてＳＲＨを復元するというアクションが過剰なＳＦＦオーバーヘッドを引き起こすということである。ＳＦデバイスは、ＳＲｖ６をサポートする必要がない。その代わりに、ＳＦデバイスとＳＦＦとの間のトンネル（Ｔｕｎｎｅｌ）インターワーキングに注意を払う必要がある。

【0193】

最後に、ＳＲ－ｕｎａｗａｒｅのＳＦデバイス用の解決手段に関する問題には、２つの態様が含まれている。一方では、ＳＦＦ（ＳＦＦ）実装が複雑であり、特に転送チップに対して高い要件がある。他方では、様々なプロキシモードに対して、適用シナリオの限界がいくつかある。

【0194】

前述の分析を通じて分かるのは、ＳＲ－ａｗａｒｅのＳＦ用の解決手段およびＳＲ－ｕｎａｗａｒｅのＳＦ用の解決手段は、制御プレーンに大きな違いはないが、転送プレーンに２つの極端な状態を形成するということである。Ｅｎｄ．ＡＮ解決手段では、ＳＦデバイスを実装するのが複雑である。しかしながら、Ｅｎｄ．ＡＳ解決手段およびＥｎｄ．ＡＤ解決手段では、ＳＦＦを実装するのが複雑である。明らかではあるが、ＳＦデバイスおよびＳＦＦのうちの一方を実装して展開するのは、どの解決手段を用いるかに関係なく複雑である。

【0195】

このことを考慮して、以下では、ジレンマ分析と前述した解決手段の改善策とを提供する。

【0196】

例えば、図１１を参照されたい。ＳＲｖ６パケットでは、トンネル層（Ｔｕｎｎｅｌ ｌａｙｅｒ）情報がＳＲｖ６パケットのＳＲＨに含まれている。サービス層（ｓｅｒｖｉｃｅ ｌａｙｅｒ）情報がＳＲｖ６パケットのｐａｙｌｏａｄに含まれている。ＳＲｖ６の重要な利点とは、Ｐ／ＰＥデバイスがステートレスであることである。しかしながら、サービスにはある状態があり、サービスのその状態がどこで得られるのだろうか。サービスの状態はＳＲｖ６パケットのＳＲＨに含まれている。

【0197】

ＳＦＦおよびＳＦデバイスは、ＳＦＣ転送プレーンに関して２つの重要な役割である。

【0198】

ＳＦＦには、パケットをサービス処理のためにＳＦデバイスに転送する役割がある。パケットカプセル化の観点から見ると、ＳＦＦはｐａｙｌｏａｄ部分ではなく、Ｔｕｎｎｅｌ ｈｅａｄｅｒ（ＳＲＨ）部分だけに注意を払う。さらに、Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性を確保する必要がある。

【0199】

ＳＦデバイスは主にｐａｙｌｏａｄ部分に注目しており、Ｔｕｎｎｅｌ ｈｅａｄｅｒ部分にはめったに注目しない（ＶＰＮ ＩＤなどの少量の情報を搬送するという要件は除く）。

【0200】

ＳＦＦおよびＳＦデバイスの要件が異なることによって、前述の解決手段はＳＲｖ６ ＳＦＣ転送モデルにおいて異なるジレンマを有している。

【0201】

具体的には、ＳＲｖ６ ＳＦＣ技術におけるＥｎｄ．ＡＮ解決手段の場合、ＳＦＦの観点から見ると、ＳＦデバイスは一般的なＳＲｖ６対応ネクストホップであり、したがってＳＦＦは特別な処理を行う必要がない。ＳＦデバイスの観点から見ると、ＳＲＨの後にサービスデータが隠されており、ＳＦデバイスは、さらなる処理を行う前にＥｎｄ．ＡＤ ＳＩＤを認識する必要がある。したがって、ＳＦデバイスが直面するジレンマとは、Ｅｎｄ．ＡＤ ＳＩＤが主にＡＣＬトラフィック分類に用いられ、ＳＦデバイスはＥｎｄ．ＡＤ ＳＩＤしか用いないという点にある。しかしながら、ＳＦＦはＳＲＨ全体をＳＦデバイスに送信する。このことを考慮して、以下の方法の実施形態は、Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性を確保すると共に、ＳＦデバイスがＳＲｖ６ ＳＩＤを解析する段階を省略するのに用いられてよく、これにより、ＳＦデバイスが直面するジレンマが解決される。

【0202】

ＳＲｖ６ ＳＦＣ技術におけるＥｎｄ．ＡＳ解決手段およびＥｎｄ．ＡＤ解決手段の場合、ＳＦＦの観点から見ると、一方でＳＦＦは、ＳＦデバイスがＳＲＨを受信できないため、Ｔｕｎｎｅｌ ｈｅａｄｅｒを置き換える必要がある。しかしながら、Ｔｕｎｎｅｌ ｈｅａｄｅｒを置き換えると、Ｔｕｎｎｅｌ ｌａｙｅｒ情報は連続性を失う。他方では、Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性を確保するために、ＳＦＦは、静的設定（ｓｔａｔｉｃ ｃｏｎｆｉｇｕｒａｔｉｏｎ）またはｃａｃｈｅなどの様々な方式でＴｕｎｎｅｌ ｈｅａｄｅｒを復元する必要がある。いずれの方式も非常に複雑である。

【0203】

ＳＦデバイスの観点から見ると、ＳＲｖ６カプセル化関連の解析タスクがＳＦＦにより完了する。一方では、Ｔｕｎｎｅｌ ｌａｙｅｒカプセル化を変更した後に、ＳＦＦはＶＰＮ ＩＤをマッピングする必要がある。そうしなければ、ＳＦデバイスはＶＰＮ ＩＤを取得できず、ＶＰＮ分離を実施できない。他方では、ＳＦデバイスは通常Ｔｕｎｎｅｌ ｌａｙｅｒ情報を用いないため、ＳＦデバイスは通常Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性に注目しない。したがって、ＳＦＦが直面するジレンマとは、ＳＲｖ６技術を実装するために、ＳＦＦはＳＦデバイスがｕｎａｗａｒｅのＳＦデバイスであるという問題を解決する必要があるという点にある。したがって、ＳＦＦはＴｕｎｎｅｌ ｈｅａｄｅｒを置き換える。Ｔｕｎｎｅｌ ｈｅａｄｅｒを置き換えると、Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性は中断する。Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性を妨げるには、静的設定またはｃａｃｈｅなどの様々な方式を用いる必要がある。分析によれば、前述した解決手段の根本原因とは、前のパケットおよび次のパケットのＴｕｎｎｅｌ ｈｅａｄｅｒを置き換えることにより、Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性を中断させたことである。

【0204】

以下の実施形態を説明する前に、本願のいくつかの実施形態の発明概念を最初に説明する。

【0205】

ＳＲ－ａｗａｒｅのＳＦデバイス用の解決手段およびＳＲ－ｕｎａｗａｒｅのＳＦデバイス用の解決手段では両方とも、ＳＲｖ６ ＳＦＣの転送プレーン機能が１つのＳＦデバイスまたは１つのＳＦＦによって実装されているというのが基本的な考えである。これは極端な考えであり、複雑な実装および展開を引き起こす。しかしながら、本願ではバランスのとれた考えが採用されている。ＳＲｖ６ Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性を確保するという前提に基づいて、ＳＦＦおよびＳＦデバイスにわずかな修正をするだけで、ＳＲｖ６ ＳＦＣの転送プレーン機能を実装できる。このように、ＳＦＦおよびＳＦデバイスの実装が簡略化されて、転送チップに対する要件が大幅に低下する。

【0206】

具体的には、Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性をどのように確保するかが、ＳＦＦの重要な要件である。本願のいくつかの実施形態では、以下のような解決手段を用いて、ＳＦＦの重要な要件を満たしている。すなわち、ＳＦＦはＴｕｎｎｅｌ ｈｅａｄｅｒカプセル化を置き換えることはせずに、完全なＳＲｖ６パケットをＳＦデバイスに転送する。ＳＦデバイスはＴｕｎｎｅｌ ｈｅａｄｅｒを終了させるのではなく、Ｔｕｎｎｅｌ ｈｅａｄｅｒを元のまま戻す（いくつかの制御フラグを除く）。

【0207】

ＳＦデバイスの重要な要件によって、トラフィック分類が容易になり、関連するポリシーとアクションとが関連付けられる。本願のいくつかの実施形態では、ＳＦデバイスの重要な要件が以下のような解決手段を用いて満たされている。すなわち、ＳＦＦは、ＳＦＦによりＳＦデバイスに転送されるＳＲｖ６パケットに、関連する制御フラグを追加して、そのような適用シナリオを明確に識別する。ＳＦデバイスは、ＳＲｖ６パケットを一般的なＩＰｖ６サービスパケットおよびＩＰｖ６トンネルパケットと区別するために、制御フラグを識別する必要がある。ＳＦデバイスは、そのようなパケットを識別する場合に以下のオペレーションを行う。最初に、ＳＦデバイスはＳＲＨを終了するのではなく、サービス処理の後にＳＲＨを元のままＳＦＦに戻す。次に、ＳＦデバイスはＳＲＨ部分をオフセットして、ｐａｙｌｏａｄ部分に対してサービス処理を行う。

【0208】

以上の解決手段を用いて達成される効果には、限定されることはないが、以下のことが含まれている。

【0209】

１．Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性が中断されない。

【0210】

２．Ｔｕｎｎｅｌ ｈｅａｄｅｒのカプセル化フォーマットを修正する必要がなく、ＳＦＦ転送プレーンの実装が簡単である。

【0211】

３．ＳＦＦ設定が簡単であり（復元されるＳＲＨを設定することはない）、転送プレーンはステートレスである（ｃａｃｈｅがない）。

【0212】

４．ＳＦデバイスは、Ｅｎｄ．ＡＮ ＳＩＤおよびＳＲｖ６インフラストラクチャをサポートする必要がなく、ｎａｔｉｖｅ ＩＰｖ６をサポートするだけでよい。

【0213】

パケットのＴｕｎｎｅｌ ｈｅａｄｅｒで示されている部分が、特定のカプセル化方式に依存することがある。例えば、図１４および関連する説明を参照されたい。挿入（ｉｎｓｅｒｔ）モードを用いる場合、Ｔｕｎｎｅｌ ｈｅａｄｅｒはＳＲＨパケットヘッダを指す。カプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）モードを用いる場合、Ｔｕｎｎｅｌ ｈｅａｄｅｒはＳＲＨを含むＩＰｖ６ ｈｅａｄｅｒ全体を指す。例えば、Ｔｕｎｎｅｌ ｈｅａｄｅｒは最外ＩＰｖ６標準ヘッダ、ＳＲＨ、およびＳＲＨ以外の少なくとも１つのＩＰｖ６拡張ヘッダを指す。Ｔｕｎｎｅｌ ｌａｙｅｒ情報の連続性が中断されるということは、ネットワークデバイスがパケットを転送するプロセスにおいてパケットの動的情報が破棄されて、その結果、サービス機能が影響を受けることを意味する。具体的には、ネットワーク上で伝送される情報がＩＰパケットを用いて搬送される。この情報は、２つのカテゴリ、つまり静的情報と動的情報とに分けられる。静的情報は、パケットが生成される前に決定された情報である。例えば、静的情報はユーザによって設定される。動的情報は、生成プロセスまたは伝送プロセスの際に、アルゴリズムを用いて動的に生成される。ユーザが動的情報を予め設定することはできない。例えば、ＴＣＰまたはＵＤＰの送信元ポート番号が動的情報であり、送信元ポート番号は通常、ある範囲内で（疑似）ランダムに選択される。Ｔｕｎｎｅｌ ｈｅａｄｅｒは動的情報も搬送する。Ｅｎｄ．ＡＳ ＳＩＤを用いる場合、動的情報は無条件に破棄される。しかしながら、静的情報だけは指定されてよい。動的情報の消失はサービス機能に影響を与える。

【0214】

図１２を参照されたい。本願の一実施形態がシステムアーキテクチャ１００を提供する。システムアーキテクチャ１００は、ＳＲｖ６ ＳＦＣのアーキテクチャの一例である。

【0215】

制御プレーンの観点から見ると、ＳＲｖ６ ＳＦＣのシステムアーキテクチャには、ＳＤＮ ｃｏｎｔｒｏｌｌｅｒ、およびネットワーク機能仮想化インフラストラクチャ（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、ＮＦＶＩ）などが含まれている。システムアーキテクチャ１００には、ＳＤＮコントローラ、およびネットワーク機能仮想化（英名：Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ、略してＮＦＶ）管理デバイス１またはＮＦＶ管理デバイス１が含まれている。これらのデバイスは、ＳＲｖ６ ＳＦＣの制御プレーンの例である。

【0216】

データプレーンの観点から見ると、ＳＲｖ６ ＳＦＣネットワークエレメントには、サービス分類器、ＳＦＦ、ＳＦＣ ｐｒｏｘｙ、およびＳＦデバイスが含まれている。システムアーキテクチャ１００には、サービス分類器、ＳＦデバイス１、ＳＦデバイス２、ＳＦデバイス３、またはＳＦデバイス４、およびＳＦＦ１またはＳＦＦ２が含まれている。これらのデバイスは、ＳＲｖ６ ＳＦＣのデータプレーンの例である。ＳＦデバイス１、ＳＦデバイス２、ＳＦデバイス３、またはＳＦデバイス４は、ＳＦデバイスの一例である。ＳＦＦ１またはＳＦＦ２はＳＦＦの一例である。

【0217】

システムアーキテクチャ１００におけるＳＦＦは、Ｅｎｄ ＳＩＤおよびＥｎｄ．Ｘ ＳＩＤなどを含むＳＲｖ６機能をサポートする。任意選択で、ＳＦＦは、ＳＲｖ６ ＳＦＣプロキシ機能に関連したＳＩＤ、例えば、Ｅｎｄ．ＡＳ／Ｅｎｄ．ＡＤ／Ｅｎｄ．ＡＭ ＳＩＤをサポートする必要がない。

【0218】

システムアーキテクチャ１００におけるＳＦデバイスは、ＩＰｖ６転送機能をサポートし、本願における以下の方法２００、方法３００、または方法４００に関連した機能もサポートする必要がある。任意選択で、ＳＦデバイスはＳＲｖ６関連の機能を実装する必要がない。

【0219】

あるいは、任意選択で、ＳＦＦおよびＳＦデバイスは１つのデバイスに統合される。例えば、ＳＦデバイス機能はルータに実装される。例えば、ＮＡＴおよびＦＷなどのボードサポート機能がルータに挿入されることにより、ルータは、ボードを使ってＮＡＴおよびＦＷなどの機能を実装するようになる。

【0220】

システムアーキテクチャ１００における各デバイスは、ＳＲ技術、ＳＦＣ技術、およびＳＲ ＳＦＣ技術を上述したときに説明したデバイスに対応することを理解されたい。例えば、システムアーキテクチャ１００におけるＳＦＦは、ＳＦＣ技術を上述したときに説明したＳＦＦに対応する。さらに、システムアーキテクチャ１００におけるＳＦＦは、ＳＲｖ６技術を上述したときに説明したＳＲｖ６ノードに対応する。システムアーキテクチャ１００におけるＳＦＦは、上述したＳＦＣ技術におけるＳＦＦおよびＳＲｖ６ノードのいずれかの機能を含む。システムアーキテクチャ１００におけるＳＦデバイスは、ＳＦＣ技術を上述したときに説明したＳＦデバイスに対応する。システムアーキテクチャ１００におけるＳＦデバイスは、上述したＳＦデバイスのいずれかの機能を含む。説明を簡潔にするために、システムアーキテクチャ１００に関する詳細は、再度説明しない。

【0221】

以上では、システムアーキテクチャ１００を用いて、ＳＲｖ６ ＳＦＣのシステムアーキテクチャについて説明している。以下では、方法２００～方法４００を例に用いて、上記で提供したシステムアーキテクチャに基づいてＳＲｖ６ ＳＦＣを実装する方法のプロセスについて説明する。

【0222】

図１３を参照されたい。図１３は、本願の一実施形態による、ＳＲｖ６サービス機能チェーンでパケットを転送する方法２００のフローチャートである。方法２００における相互作用主体には、ＳＦデバイスとＳＦデバイスがアクセスするＳＦＦとが含まれている。例えば、図１２に示すシステムアーキテクチャ１００では、ＳＦデバイス１とＳＦデバイス１がアクセスするＳＦＦ１によって、方法２００が行われる。別の例では、システムアーキテクチャ１００におけるＳＦデバイス３とＳＦデバイス３がアクセスするＳＦＦ２によって、方法２００が行われる。ＳＦＦ１およびＳＦＦ２により転送されるＳＲｖ６パケットは、システムアーキテクチャ１に示すトラフィック分類器によってもたらされてよい。

【0223】

任意選択で、方法２００は、汎用の中央演算処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）によって、ネットワークプロセッサ（ｎｅｔｗｏｒｋ ｐｒｏｃｅｓｓｏｒ、ＮＰ）によって、ＣＰＵおよびＮＰが一緒に、またはＣＰＵおよびＮＰの代わりにパケット転送に好適な別のプロセッサによって処理される。これは、本願において限定されない。

【0224】

例えば、方法２００にはＳ２０１～Ｓ２０９が含まれている。Ｓ２０１は、方法２００の事前設定処理プロセスである。Ｓ２０２～Ｓ２０９は、方法２００の転送プロセスである。Ｓ２０１が行われる回数が、Ｓ２０２～Ｓ２０９が行われる回数と異なってよいことを理解されたい。例えば、Ｓ２０１は最初に１回行われ、次いでＳ２０２～Ｓ２０９が複数回行われる。

【0225】

Ｓ２０１：ＳＦＦにエンドポイント貫通セグメントＩＤ（Ｅｎｄ．ＰＴ．ＳＩＤ）を設定する。

【0226】

Ｅｎｄ．ＰＴは、本願の本実施形態において定義された新たなＳＩＤタイプである。Ｅｎｄはｅｎｄｐｏｉｎｔを示している。ＰＴは貫通（Ｐｅｎｅｔｒａｔｅ）を意味しており、ＳＲＨを省略するアクションを表している。Ｅｎｄ．ＰＴ．ＳＩＤはＳＲｖ６ ＳＩＤである。Ｅｎｄ．ＰＴ．ＳＩＤのＳＩＤタイプはＥｎｄ．ＰＴである。Ｅｎｄ．ＰＴ．ＳＩＤは、ＳＲＨを取り除くことなく、受信したＳＲｖ６パケットをＳＦデバイスに転送するようＳＦＦに指示するのに用いられる。任意選択で、ＳＦデバイスは、ＩＰｖ６をサポートするがＳＲｖ６をサポートしないデバイスである。任意選択で、Ｅｎｄ．ＰＴ．ＳＩＤはさらに、ＳＲｖ６パケットに制御フラグをカプセル化するようＳＦＦに指示するのに用いられる。

【0227】

任意選択で、Ｅｎｄ．ＰＴ．ＳＩＤはＳＦＦのローカルＳＩＤである。ＳＦＦは、Ｅｎｄ．ＰＴ．ＳＩＤをＳＦＦのローカルＳＩＤテーブルに格納する。Ｅｎｄ．ＰＴ．ＳＩＤのＬｏｃａｔｏｒがＳＦＦに対応し、Ｅｎｄ．ＰＴ．ＳＩＤのＬｏｃａｔｏｒはＳＦＦの位置を特定するのに用いられる。さらに、ＳＦＦはＥｎｄ．ＰＴ．ＳＩＤをＳＲｖ６ネットワークに広告してよい。

【0228】

Ｅｎｄ．ＰＴは新たに定義されたＳＩＤタイプの一例であり、Ｅｎｄ．ＰＴ ＳＩＤは新たに定義されたＳＩＤの一例であり、ＳＩＤタイプおよびＳＩＤの名称は単なる例にすぎず、ＳＩＤタイプおよびＳＩＤは他の呼称も有してよいことを理解されたい。例えば、ＳＩＤは、異なるシナリオでは異なる名称を有することがある。例えば、異なるベンダーが異なる名称を用いる、または異なる規格が異なる名称を用いる。ＳＩＤの呼称が、本願の保護範囲を限定するのに用いられることはない。

【0229】

Ｓ２０２：ＳＦＦは第１のＳＲｖ６パケットを受信する。

【0230】

本実施形態では、ＳＦＦが受信するパケットとＳＦＦが送信するパケットとを区別するために、ＳＦＦが受信するＳＲｖ６パケットが第１のＳＲｖ６パケットと呼ばれ、ＳＦＦが送信するＳＲｖ６パケットが第２のＳＲｖ６パケットと呼ばれ、ＳＦデバイスからＳＦＦに戻されるＳＲｖ６パケットが第３のＳＲｖ６パケットと呼ばれる。第１のＳＲｖ６パケット、第２のＳＲｖ６パケット、および第３のＳＲｖ６パケットには全て、ＳＲＨが含まれている。

【0231】

第１のＳＲｖ６パケットの生成には、複数の方式がある。いくつかの実施形態では、図１４を参照されたい。第１のＳＲｖ６パケットの生成モードは２つある。一方の生成モードは挿入モードと呼ばれており、他方の生成モードはカプセル化モードと呼ばれている。

【0232】

挿入モードでは、ＩＰｖ６パケットに基づいてＳＲｖ６パケットが生成される。先頭ノードが、ＩＰｖ６パケットの最外層にあるＩＰｖ６標準ヘッダとペイロードとの間に、ＩＰｖ６拡張ヘッダＳＲＨを挿入する。挿入モードで生成されるＳＲｖ６パケットには、例えば、ＩＰｖ６標準ヘッダ、ＳＲＨ、ＳＲＨ以外の別のＩＰｖ６拡張ヘッダ、およびペイロードが含まれている。ＳＦデバイスの場合、挿入モードで生成されるＳＲｖ６パケットでは、ＳＲＨがトンネル層情報に属しており、ＳＲＨ以外の別のＩＰｖ６拡張ヘッダおよびペイロードがサービス層情報に属している。本実施形態では、ＳＲＨをオフセットするが、ＳＲＨ以外の別のＩＰｖ６拡張ヘッダまたはペイロードをオフセットしないよう、制御フラグを用いてＳＦデバイスを制御することにより、ＳＦデバイスはＳＲｖ６パケットのトンネル層情報をオフセットして、ＳＲｖ６パケットのサービス層情報を処理するようになる。例えば、ＳＦデバイスは、ＳＲｖ６パケットのサービス層情報の処理（例えば、ペイロード、別のＩＰｖ６拡張ヘッダ、またはその両方の処理）を含むＳＲｖ６パケットに対するサービス処理を行う。

【0233】

カプセル化モードでは、ＩＰｖ４パケット、ＩＰｖ６パケット、またはイーサネットフレームに基づいて、ＳＲｖ６パケットが生成される。ＩＰｖ４パケットに基づいてＳＲｖ６パケットが生成されるプロセスが、一例として用いられる。先頭ノードが、ＩＰｖ４パケットの外側層にＳＲＨおよびＩＰｖ６標準ヘッダを追加する。任意選択で、先頭ノードはさらに、ＳＲＨ以外の別のＩＰｖ６拡張ヘッダを追加する。ＳＦデバイスの場合、カプセル化モードで生成されるＳＲｖ６パケットでは、先頭ノードにより追加されるＳＲＨおよび別のＩＰｖ６拡張ヘッダがトンネル層情報に属しており、ペイロードがサービス層情報に属している。本実施形態では、先頭ノードにより追加されたＳＲＨおよび別のＩＰｖ６拡張ヘッダをオフセットするよう、制御フラグを用いてＳＦデバイスを制御することにより、ＳＦデバイスは、ＳＲｖ６パケットのトンネル層情報をオフセットして、ＳＲｖ６パケットのサービス層情報を処理するようになる。例えば、カプセル化モードにおいて、ＳＦデバイスはＳＲｖ６パケットに対して、ペイロードの処理を含むサービス処理を行う。

【0234】

第１のＳＲｖ６パケットの宛先アドレスにはＥｎｄ．ＰＴ．ＳＩＤが含まれている。ＳＲｖ６パケットには通常、外側ＩＰｖ６ヘッダおよび内側の元パケットが含まれている。外側ＩＰｖ６ヘッダにはＤＡフィールドが含まれており、内側の元パケットにもＤＡフィールドが含まれている。ここでの宛先アドレスは、外側ＩＰｖ６ヘッダのＤＡフィールドで搬送される宛先アドレスを指す。言い換えれば、第１のＳＲｖ６パケットの外側ＩＰｖ６ヘッダにあるＤＡフィールドには、Ｅｎｄ．ＰＴ．ＳＩＤが含まれている。さらに、ＳＲｖ６フィールドでは、Ｌｏｃａｌ ＳＩＤテーブルと一致するＳＲｖ６パケットのＩＰｖ６ ＤＡがＡｃｔｉｖｅ ＳＩＤと呼ばれることがある。したがって、第１のＳＲｖ６パケットのＡｃｔｉｖｅ ＳＩＤがＥｎｄ．ＰＴ．ＳＩＤであると言われてもよい。

【0235】

Ｓ２０３：ＳＦＦは、Ｅｎｄ．ＰＴ．ＳＩＤおよび第１のＳＲｖ６パケットに基づいて、第２のＳＲｖ６パケットを生成する。

【0236】

ＳＦＦは、第１のＳＲｖ６パケットを受信した後に、第１のＳＲｖ６パケットのＡｃｔｉｖｅ ＳＩＤに基づいて、第１のＳＲｖ６パケットに対して転送処理を行う。ＳＲｖ６フィールドでは、Ａｃｔｉｖｅ ＳＩＤに基づく処理プロセスが通常、以下のことを含んでいる。ＳＦＦは、宛先アドレスとローカルＳＩＤテーブル内のＳＩＤとを一致させるために、第１のＳＲｖ６パケットの外側ＩＰｖ６ヘッダにある宛先アドレスに基づいてローカルＳＩＤテーブルに照会し、宛先アドレスと一致したＳＩＤに基づいて、宛先アドレスと一致したＳＩＤに対応するオペレーションを行う。Ｓ２０３では、第１のＳＲｖ６パケットのＡｃｔｉｖｅ ＳＩＤがＥｎｄ．ＰＴ．ＳＩＤであるため、ＳＦＦがローカルＳＩＤテーブルに照会したときに、Ｅｎｄ．ＰＴタイプに一致する。したがって、ＳＦＦはＥｎｄ．ＰＴ．ＳＩＤに対応するオペレーションを行う。具体的には、ＳＦＦはＳＲＨを取り除くことなく第１のＳＲｖ６パケットをＳＦデバイスに転送する。

【0237】

Ｓ２０３は、Ｅｎｄ．ＡＳ ＳＩＤおよびＥｎｄ．ＡＤ ＳＩＤなどのＳＲプロキシ方式と異なる。具体的には、ＳＦＦは、第１のＳＲｖ６パケットに対して転送処理を行うときに、第１のＳＲｖ６パケットのＳＲＨを取り除くことはない。その代わりに、ＳＦＦは、第１のＳＲｖ６パケットをＳＲｖ６パケットのカプセル化形態として保つことにより、ＳＲＨを含む第２のＳＲｖ６パケットはＳＦデバイスに転送されるようになる。

【0238】

第２のＳＲｖ６パケットに含まれたＳＲＨと第１のＳＲｖ６パケットに含まれたＳＲＨとの関係については、複数のケースがある。以下では、説明のためにケースＡおよびケースＢを用いる。

【0239】

ケースＡ：第２のＳＲｖ６パケットに含まれたＳＲＨは、第１のＳＲｖ６パケットに含まれたＳＲＨと異なる。具体的には、第２のＳＲｖ６パケットに含まれたＳＲＨのセグメントリストが、第１のＳＲｖ６パケットに含まれたＳＲＨのセグメントリストと同じであり、第２のＳＲｖ６パケットに含まれたＳＲＨのＳＬが、第１のＳＲｖ６パケットに含まれたＳＲＨのＳＬより１だけ小さい。

【0240】

ケースＡが適用可能なのは、ＳＦＦがＡｃｔｉｖｅ ＳＩＤを更新し、次いでパケットをＳＦに送信する方式である。具体的には、ＳＦＦは最初に、第１のＳＲｖ６パケットのＡｃｔｉｖｅ ＳＩＤを更新して、更新されたＡｃｔｉｖｅ ＳＩＤを含む第２のＳＲｖ６パケットを取得し、次いで第２のＳＲｖ６パケットをＳＦデバイスに転送する。Ａｃｔｉｖｅ ＳＩＤを更新するアクションを行うため、第２のＳＲｖ６パケットに含まれたＳＲＨは、第１のＳＲｖ６パケットに含まれたＳＲＨと比較して変化する。例えば、ＳＦＦは、宛先アドレスをＥｎｄ．ＰＴ．ＳＩＤからセグメントリストにある次のＳＩＤに変更することで、第１のＳＲｖ６パケットの外側ＩＰｖ６ヘッダにある宛先アドレスを更新する。ＳＦＦがＳＬフィールドの値から１を差し引くことで、ＳＬはセグメントリストにある次のＳＩＤを示すようになり、これで、第１のＳＲｖ６パケットのＡｃｔｉｖｅ ＳＩＤが更新される。

【0241】

ケースＢ：第２のＳＲｖ６パケットに含まれたＳＲＨは、第１のＳＲｖ６パケットに含まれたＳＲＨと同じである。

【0242】

ケースＢが適用可能なのは、ＳＦＦが、ＳＦデバイスから戻されたパケットを受信した後にＡｃｔｉｖｅ ＳＩＤを更新する方式である。ケースＢでは、任意選択で、ＳＦＦは第１のＳＲｖ６パケットに含まれたＳＲＨを第２のＳＲｖ６パケットにカプセル化する。これにより、第２のＳＲｖ６パケットは、第１のＳＲｖ６パケットに含まれたＳＲＨを含むようになる。

【0243】

任意選択で、第２のＳＲｖ６パケットの最外ＩＰｖ６ヘッダは、第１のＳＲｖ６パケットの最外ＩＰｖ６ヘッダと同じである。あるいは、第２のＳＲｖ６パケットの最外ＩＰｖ６ヘッダは、第１のＳＲｖ６パケットの最外ＩＰｖ６ヘッダと異なる。例えば、以下の通りである。

【0244】

ＳＦＦは、第１のＳＲｖ６パケットの最外ＩＰｖ６ヘッダにあるホップリミット（Ｈｏｐ Ｌｉｍｉｔ）を更新する。例えば、ＳＦＦがＨｏｐ Ｌｉｍｉｔフィールドの値から１を差し引くことで、第２のＳＲｖ６パケットに含まれたＩＰｖ６ヘッダのＨｏｐ Ｌｉｍｉｔは、第１のＳＲｖ６パケットに含まれたＩＰｖ６ヘッダのＨｏｐ Ｌｉｍｉｔより１小さくなる。

【0245】

第２のＳＲｖ６パケットにおいてＳＲＨの後にある部分としては、ペイロードが挙げられる。第２のＳＲｖ６パケットにおいてＳＲＨの後にある部分としては、ペイロードが挙げられる。第２のＳＲｖ６パケットおよび第１のＳＲｖ６パケットは同じペイロードを有している。ペイロードとは、パケットのｐａｙｌｏａｄ部分を指す。ペイロードの異なる定義に基づいて、第２のＳＲｖ６パケットおよび第１のＳＲｖ６パケットが同じペイロードを有する複数のケースがあり得る。以下では、説明のためにケース１およびケース２を用いる。

【0246】

ケース１：第２のＳＲｖ６パケットおよび第１のＳＲｖ６パケットが同じペイロードを有するということは、第２のＳＲｖ６パケットに含まれた元パケットが第１のＳＲｖ６パケットに含まれた元パケットと同じであることを意味している。例えば、図１５を参照されたい。第１のＳＲｖ６パケットに含まれた元パケットはＩＰｖ４パケットであり、第２のＳＲｖ６パケットに含まれた元パケットはＩＰｖ４パケットであり、第１のＳＲｖ６パケットに含まれたＩＰｖ４パケットは、第２のＳＲｖ６パケットに含まれたＩＰｖ４パケットと同じである。

【0247】

ケース２：第２のＳＲｖ６パケットおよび第１のＳＲｖ６パケットが同じペイロードを有するということは、第２のＳＲｖ６パケットに含まれた元パケットのペイロードが第１のＳＲｖ６パケットに含まれた元パケットのペイロードと同じであることを意味している。例えば、第１のＳＲｖ６パケットに含まれた元パケットがＩＰｖ４パケットであり、ＩＰｖ４パケットにはＩＰｖ４パケットヘッダおよびペイロードが含まれており、ペイロードはＴＣＰパケットである。第２のＳＲｖ６パケットに含まれた元パケットがＩＰｖ４パケットであり、ＩＰｖ４パケットにはＩＰｖ４パケットヘッダおよびペイロードが含まれており、ペイロードはＴＣＰパケットである。第１のＳＲｖ６パケットに含まれたＴＣＰパケットは、第２のＳＲｖ６パケットに含まれたＴＣＰパケットと同じである。

【0248】

第２のＳＲｖ６パケットには制御フラグが含まれている。具体的には、ＳＦＦが、第１のＳＲｖ６パケットに対して転送処理を行うときに制御フラグを追加することで、取得された第２のＳＲｖ６パケットには制御フラグが含まれるようになる。ＳＦＦが第２のＳＲｖ６パケットに制御フラグを追加するのは、ＳＦＦによりＳＦデバイスに転送されたパケットをどのように解析して処理するかを、制御フラグを用いてＳＦデバイスに指示するためである。

【0249】

制御フラグは、第２のＳＲｖ６パケットにおいて制御フラグの後に続くＩＰｖ６拡張ヘッダをオフセット（ｏｆｆｓｅｔ）するようＳＦデバイスに指示するのに用いられる。任意選択で、制御フラグは、第２のＳＲｖ６パケットにおいて制御フラグを含むＩＰｖ６拡張ヘッダの後に続くＩＰｖ６拡張ヘッダをオフセットするようＳＦデバイスに指示するのに用いられる。例えば、制御フラグは、第２のＳＲｖ６パケットにおいてホップバイホップオプションヘッダの後に続くＩＰｖ６拡張ヘッダをオフセットするようＳＦデバイスに指示するのに用いられる。ホップバイホップオプションヘッダは、制御フラグを含むＩＰｖ６拡張ヘッダの一例である。

【0250】

この段落では「オフセット」の意味について説明する。例えば、オフセットされる対象が別の拡張ヘッダＡである。別の拡張ヘッダＡをオフセットすることは、別の拡張ヘッダＡを解析するのではなく、パケットにおいて別の拡張ヘッダＡの後に続く部分を解析して処理することを意味している。

【0251】

任意選択で、制御フラグの指示機能には、以下の方式（１）および方式（２）のうちのいずれか一方が含まれている。

【0252】

方式（１）：制御フラグは、第２のＳＲｖ６パケットのＳＲＨをオフセットするようＳＦデバイスに指示するのに用いられる。

【0253】

任意選択で、方式（１）が適用可能なのは、第１のＳＲｖ６パケットの生成モードが挿入モードである場合である。方式（１）では、ＳＲＨを正確にオフセットするよう指示するのに制御フラグを用いる。任意選択で、ＳＲＨ以外の別のＩＰｖ６拡張ヘッダをオフセットするのを省略するよう指示するのに制御フラグを用いることで、ＳＦデバイスは、制御フラグで指示される通りに、ＳＲＨ以外の別のＩＰｖ６拡張ヘッダを処理するようになる。

【0254】

例えば、先頭から末尾への順で、第２のＳＲｖ６パケットには、ＩＰｖ６標準ヘッダ、制御フラグを含むホップバイホップオプションヘッダ、別の拡張ヘッダＡ、ＳＲＨ、別の拡張ヘッダＢ、およびＩＰｖ４パケットが連続的に含まれている。制御フラグは、ＳＲＨをオフセットするが別の拡張ヘッダＡおよび別の拡張ヘッダＢをオフセットしないよう指示するのに用いられる。ホップバイホップオプションヘッダは、制御フラグを含むＩＰｖ６拡張ヘッダの一例である。別の拡張ヘッダＡおよび別の拡張ヘッダＢは、制御フラグの後に続く他のＩＰｖ６拡張ヘッダの例である。別の拡張ヘッダＡは、ＳＲＨに先行する別のＩＰｖ６拡張ヘッダの一例である。別の拡張ヘッダＢは、ＳＲＨの後に続く別のＩＰｖ６拡張ヘッダの一例である。

【0255】

方式（２）：制御フラグは、第２のＳＲｖ６パケットのＳＲＨおよびＳＲＨ以外の別のＩＰｖ６拡張ヘッダをオフセットするようＳＦデバイスに指示するのに用いられる。

【0256】

第２のＳＲｖ６パケットにおいて、別のＩＰｖ６拡張ヘッダは制御フラグの後に続く。例えば、別のＩＰｖ６拡張ヘッダは、ホップバイホップオプションヘッダの後に続き且つペイロードに先行するＩＰｖ６拡張ヘッダである。任意選択で、第２のＳＲｖ６パケットにおいて、別のＩＰｖ６拡張ヘッダはＳＲＨに先行する。任意選択で、第２のＳＲｖ６パケットにおいて、別のＩＰｖ６拡張ヘッダはＳＲＨの後に続く。ホップバイホップオプションヘッダは、制御フラグを含むＩＰｖ６拡張ヘッダの一例である。

【0257】

任意選択で、方式（２）が適用可能なのは、第１のＳＲｖ６パケットの生成モードがカプセル化モードである場合である。方式（２）では、制御フラグは、制御フラグを含むＩＰｖ６拡張ヘッダの後に続くそれぞれのＩＰｖ６拡張ヘッダをオフセットするよう指示するのに用いられる。例えば、制御フラグは、ホップバイホップオプションヘッダの後に続く最初のＩＰｖ６拡張ヘッダと、ペイロードとの間にあるそれぞれのＩＰｖ６拡張ヘッダをオフセットするよう指示するのに用いられる。

【0258】

例えば、先頭から末尾への順で、第２のＳＲｖ６パケットには、ＩＰｖ６標準ヘッダ、制御フラグを含むホップバイホップオプションヘッダ、別の拡張ヘッダＡ、ＳＲＨ、別の拡張ヘッダＢ、およびＩＰｖ４パケットが連続的に含まれている。制御フラグは、別の拡張ヘッダＡ、ＳＲＨ、および別の拡張ヘッダＢをオフセットするよう指示するのに用いられる。

【0259】

任意選択で、制御フラグは、上述したＩＰｖ６拡張ヘッダをオフセットする指示機能を有しているだけでなく、別の指示機能も有している。具体的には、制御フラグはさらに、パケットをＳＦＦに戻すプロセスにおいて、第２のＳＲｖ６パケット内のオフセットされたＩＰｖ６拡張ヘッダを戻すようＳＦデバイスに指示するのに用いられる。制御フラグの指示機能を用いると、ＳＦデバイスによりオフセットされたＩＰｖ６拡張ヘッダを元のままＳＦＦに戻すことができるので、ＳＦデバイスによりオフセットされたＩＰｖ６拡張ヘッダは、サービス機能チェーンにあるダウンストリームのネットワークエレメントにＳＦＦを通じて常に渡されるようになる。これにより、ＳＦデバイスによりオフセットされたＩＰｖ６拡張ヘッダの伝送がＳＦデバイスで中断されるのを防ぐ。以下では、制御フラグの別の指示機能を方式Ｉおよび方式ＩＩを用いて説明する。

【0260】

方式Ｉ：この方式は前述の方式（１）および挿入モードに対応する。制御フラグはさらに、パケットをＳＦＦに戻すプロセスにおいて、第２のＳＲｖ６パケットのＳＲＨを戻すようＳＦデバイスに指示するのに用いられる。

【0261】

方式ＩＩ：この方式は、前述の方式（２）およびカプセル化モードに対応する。制御フラグはさらに、パケットをＳＦＦに戻すプロセスにおいて、第２のＳＲｖ６パケットのＳＲＨと、第２のＳＲｖ６パケットにおいて制御フラグの後に続くＳＲＨ以外の別のＩＰｖ６拡張ヘッダとを戻すようＳＦデバイスに指示するのに用いられる。例えば、制御フラグはさらに、第２のＳＲｖ６パケット内にあり、且つホップバイホップオプションヘッダの後に続く最初のＩＰｖ６拡張ヘッダと、ペイロードとの間にある、それぞれのＩＰｖ６拡張ヘッダを戻すよう指示するのに用いられる。

【0262】

ＳＦデバイスが第２のＳＲｖ６パケットを受信したときに、ＳＦデバイスが第２のＳＲｖ６パケットの制御フラグを読み出す場合、ＳＦデバイスは、第２のＳＲｖ６パケットをそのＩＰｖ６拡張ヘッダがオフセットされるパケットとみなし、ＩＰｖ６拡張ヘッダをオフセットする方式で第２のＳＲｖ６パケットを処理する。任意選択で、制御フラグは「ＣｔｒｌＩｎｆｏ」と表示される。

【0263】

以上では、ＳＦＦによりＳＲｖ６パケットに追加される制御フラグについて説明している。いくつかの実施形態では、ＳＦＦは、制御フラグだけでなくターゲット情報もＳＲｖ６パケットに追加する。ターゲット情報は、ＳＦデバイスがサービス処理を行うときに用いる必要がある情報である。例えば、ターゲット情報は、ＳＲｖ６ ＳＦＣ関連の情報である。ＳＦＦによるターゲット情報の追加には、複数の方式がある。以下では、説明のために方式１および方式２を用いる。方式１はカプセル化方式の一例であり、方式２はマッピング方式の一例である。

【0264】

方式１：ＳＦＦが第１のＳＲｖ６パケットのＳＲＨを解析し、ＳＦＦは第１のＳＲｖ６パケットに含まれたＳＲＨからターゲット情報を取得する。

【0265】

方式１では、ＳＦＦはＳＲＨからターゲット情報を取得し、第１のＳＲｖ６パケットのＳＲＨにあるターゲット情報を第２のＳＲｖ６パケットにカプセル化する。

【0266】

例えば、ターゲット情報には、ＳＦＣメタデータ（ＳＦＣ ｍｅｔａｄａｔａ）および仮想プライベートネットワークＩＤ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ ＩＤ、ＶＰＮ ＩＤ）のうちの少なくとも一方が含まれている。

【0267】

ＳＦＣメタデータには複数のシナリオが含まれている。例えば、データ通信ネットワーク（Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｎｅｔｗｏｒｋ、ＤＣＮ）では、ＳＦＣメタデータはＤＣコンテキスト割り当て（ＤＣ Ｃｏｎｔｅｘｔ Ａｌｌｏｃａｔｉｏｎ）情報である。例えば、ＳＦＣメタデータには、送信元ノードＩＤ（Ｓｏｕｒｃｅ Ｎｏｄｅ ＩＤ）、送信元インタフェースＩＤ（Ｓｏｕｒｃｅ Ｉｎｔｅｒｆａｃｅ ＩＤ）、テナントＩＤ（Ｔｅｎａｎｔ ＩＤ）、宛先クラス（Ｄｅｓｔｉｎａｔｉｏｎ Ｃｌａｓｓ）、送信元クラス（Ｓｏｕｒｃｅ Ｃｌａｓｓ）、および不透明なサービスクラス（Ｏｐａｑｕｅ Ｓｅｒｖｉｃｅ Ｃｌａｓｓ）が含まれている。例えば、高精度時間プロトコル（Ｐｒｅｃｉｓｉｏｎ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ、ＰＴＰ）では、ＳＦＣメタデータは３２ビットのＰＴＰベースのタイムスタンプである。例えば、ＳＦＣメタデータはナノ秒（Ｎａｎｏｓｅｃｏｎｄ）の情報である。例えば、ネットワークタイムプロトコル（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ、ＮＴＰ）では、ＳＦＣメタデータは３２ビットのＮＴＰベースのタイムスタンプである。例えば、ＳＦＣメタデータは秒（Ｓｅｃｏｎｄ）および端数（Ｆｒａｃｔｉｏｎ）である。例えば、ＳＦＣメタデータには、コンテキストＩＤ（Ｃｏｎｔｅｘｔ ＩＤ）、サブ／エンドポイントＩＤ（Ｓｕｂ／Ｅｎｄｐｏｉｎｔ ＩＤ）、およびサービス情報（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）が含まれている。例えば、ＳＦＣメタデータには、コンテキストＩＤ（Ｃｏｎｔｅｘｔ ＩＤ）、サブ／エンドポイントＩＤ（Ｓｕｂ／Ｅｎｄｐｏｉｎｔ ＩＤ）、およびサービス情報（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）が含まれている。例えば、無線アクセスネットワーク（ｗｉｒｅｌｅｓｓ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ、ＲＡＮ）において、ＳＦＣメタデータには、サービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ、ＱｏＳ）／差別化サービスコードポイント（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｃｏｄｅ Ｐｏｉｎｔ、ＤＳＣＰ）およびアプリケーション（ａｐｐｌｉｃａｔｉｏｎ、Ａｐｐ）ＩＤのうちの少なくとも一方が含まれている。

【0268】

任意選択で、ＶＰＮ ＩＤは１２８ビットのＳＲｖ６ ＶＰＮ ＳＩＤで表される。ＳＲｖ６ ＶＰＮ ＳＩＤはＳＲｖ６ ＳＩＤである。ＳＲｖ６ ＶＰＮ ＳＩＤは、対応するＶＰＮを識別するのに用いられる。具体的には、ＳＲｖ６ ＶＰＮ ＳＩＤの機能情報（Ｆｕｎｃｔｉｏｎ）が、パケットをＶＰＮインスタンスに送信するよう宛先デバイスに指示するのに用いられることで、パケットは宛先デバイスから対応するＶＰＮに入り、テナント分離が実現されるようになる。ＶＰＮ ＳＩＤタイプとしては、限定されることはないが、Ｅｎｄ．ＤＸおよびＥｎｄ．ＤＴが挙げられる。Ｅｎｄ．ＤＸ ＳＩＤに対応するオペレーションとしては、外側ＩＰｖ６パケットヘッダを脱カプセル化すること、およびＥｎｄ．ＤＸ ＳＩＤに結びつけられたアウトバウンドインタフェースを通じて残りのパケットを転送することが挙げられる。Ｅｎｄ．ＤＸとしては、限定されることはないが、Ｅｎｄ．ＤＸ６、Ｅｎｄ．ＤＸ４、Ｅｎｄ．ＤＸ２、またはＥｎｄ．ＤＸ２Ｖが挙げられる。Ｅｎｄ．ＤＴ ＳＩＤに対応するオペレーションとしては、外側ＩＰｖ６パケットヘッダを脱カプセル化すること、および残りのパケットに含まれた宛先アドレスに基づいてＶＰＮインスタンスのルーティングテーブルを検索すること、およびパケットを転送することが挙げられる。Ｅｎｄ．ＤＴとしては、限定されることはないが、Ｅｎｄ．ＤＴ４またはＥｎｄ．ＤＴ６が挙げられる。

【0269】

この段落では、方式１の効果について説明する。サービス処理のために、ＳＦデバイスは、ＳＲＨにカプセル化されているいくつかの情報を認識する必要があり得る。しかしながら、ＳＦデバイスは通常、ＳＲＨを識別できない。その結果、ＳＲＨのサービス情報を取得できないため、ＳＦデバイスはＳＲＨのサービス情報に基づいてサービス処理を行うことができない。しかしながら、方式１を用いると、ＳＦＦがＳＲＨを解析し、ＳＲＨに含まれているサービス情報をＳＦＦがＳＦデバイスに渡すことで、ＳＦデバイスはＳＲＨに含まれているサービス情報を取得できるようになる。さらに、ＳＦデバイスはＳＲＨを解析する必要がない。したがって、方式１は、ＳＦデバイスがＳＲＨのサービス情報に基づいてサービス処理を行うという要件を満たしており、この方式でＳＲｖ６－ｕｎａｗａｒｅのＳＦデバイスがＳＲＨのサービス情報に基づいてサービス処理を行うことができるため、応用範囲が広がる。

【0270】

方式２：ＳＦＦは第１のＳＲｖ６パケットのＳＲＨからサービス情報を取得し、サービス情報に基づいてマッピング関係情報に照会してターゲット情報を取得する。

【0271】

方式２では、第１のＳＲｖ６パケットのＳＲＨに含まれたサービス情報をマッピングすることで、ターゲット情報が取得される。具体的には、ＳＦＦはマッピング関係情報を予め設定する。ＳＦＦが第１のＳＲｖ６パケットのＳＲＨにあるサービス情報を取得した後に、ＳＦＦはマッピング関係情報に基づいてサービス情報をターゲット情報に変換し、次いで変換によって取得したターゲット情報を第２のＳＲｖ６パケットにカプセル化する。マッピング関係情報は、サービス情報とターゲット情報との対応関係を格納する。任意選択で、サービス情報およびターゲット情報は１対１の対応関係にある。任意選択で、サービス情報にはＳＦＣメタデータおよびＶＰＮ ＩＤのうちの少なくとも一方が含まれている。

【0272】

任意選択で、ターゲット情報のフォーマットが、ＳＲＨに含まれたサービス情報のフォーマットと異なる。例えば、ターゲット情報のフォーマットは、ＳＦが識別可能なフォーマットであり、ＳＲＨに含まれたサービス情報のフォーマットは、ＳＦが識別できないフォーマットである。ＳＦＦが方式２を実行することは、ＳＲＨのサービス情報に対してフォーマット変換を行ってターゲット情報を取得することに相当する。例えば、サービス情報はＳＲｖ６ ＶＰＮ ＳＩＤであり、ＳＲｖ６ ＶＰＮ ＳＩＤのフォーマットが１２８ビットのＩＰｖ６アドレスである。ターゲット情報のフォーマットは数値である。マッピング関係情報内の異なるＳＲｖ６ ＶＰＮ ＳＩＤが、異なる数値に対応する。

【0273】

例えば、マッピング関係情報は表２に示されている。表２では、１０：１：：１：０／１２８がＳＲｖ６ ＶＰＮ ＳＩＤの一例であり、ＳＩＤである１０：１：：１：０／１２８に対応するターゲット情報の一例が１である。２０：１：：１：０／１２８がＳＲｖ６ ＶＰＮ ＳＩＤの一例であり、ＳＩＤである２０：１：：１：０／１２８に対応するターゲット情報の一例が２である。３０：１：：１：０／１２８がＳＲｖ６ ＶＰＮ ＳＩＤの一例であり、ＳＩＤである３０：１：：１：０／１２８に対応するターゲット情報の一例が３である。

【表2】

【0274】

この段落では、方式２の効果について説明する。ＳＦＦは、ＳＲＨからサービス情報を解析して取り出し、ＳＲＨのサービス情報をＳＦデバイスが識別可能なターゲット情報にマッピングし、このターゲット情報をＳＦデバイスに送信される第２のＳＲｖ６パケットに含める。これにより、サービス情報はＳＦデバイスに理解される形態でＳＦデバイスに渡されるようになり、ＳＦデバイスはターゲット情報に基づいてサービス処理を行うことができる。これにより、ＳＦデバイスがＳＲＨのサービス情報を識別せず、サービス情報に基づくサービス処理を行うことができないというケースが回避され、ＳＦデバイスがＳＲＨのサービス情報に基づいてサービス処理を行うという要件が満たされる。さらに、ＳＲｖ６－ｕｎａｗａｒｅのＳＦデバイスに方式２を適用できるので、応用範囲が広がる。

【0275】

例えば、第１のＳＲｖ６パケットのＳＲＨにはＳＲｖ６ ＳＩＤが含まれており、ＳＲｖ６ ＳＩＤはサービス情報を示す。ＳＦＦは第１のＳＲｖ６パケットのＳＲＨを解析して、第１のＳＲｖ６パケットのＳＲＨにあるＳＲｖ６ ＳＩＤを取得する。ＳＦＦは、ＳＲｖ６ ＳＩＤに基づいてマッピング関係情報に照会し、ＳＲｖ６ ＳＩＤに対応するターゲット情報を取得する。ＳＲｖ６ ＳＩＤは、例えば、ＶＰＮ ＳＩＤである。前述の方式を用いることで達成される効果には、以下のことが挙げられる。ＶＰＮ ＳＩＤは通常、ＶＰＮ ＩＤとして機能し得るが、ＳＲｖ６－ｕｎａｗａｒｅのＳＦデバイスでは、ＳＦデバイスがＳＲｖ６ ＳＩＤを識別できないため、ＶＰＮ ＳＩＤをＳＦデバイスに直接的に渡すことができない。その結果、ＳＦデバイスがＶＰＮ ＩＤを用いてトラフィックを分離するという要件を満たすのが難しい。しかしながら、ＳＦＦはＳＲＨからＶＰＮ ＳＩＤを解析して取り出し、サービス情報のＶＰＮ ＩＤをＳＲｖ６ ＳＩＤフォーマットからターゲット情報フォーマットに変換し、ターゲット情報をＳＦデバイスに渡す。このように、ＳＦデバイスは、ターゲット情報に基づいてＶＰＮベースのトラフィック分離を実現できる。

【0276】

ＳＦＦは任意選択でターゲット情報をＳＲｖ６パケットに追加することを理解されたい。いくつかの他の実施形態では、ＳＦＦは代替的に、制御フラグをＳＲｖ６パケットに追加してよいが、ターゲット情報を追加しなくてもよい。これにより、第２のＳＲｖ６パケットはターゲット情報を含まなくなる。

【0277】

ＳＦＣメタデータおよびＶＰＮ ＩＤはターゲット情報の例であることを理解されたい。ターゲット情報の具体的なフォーマットおよび内容は、適用シナリオおよびサービス要件に基づいて定義され得る。ターゲット情報の具体的なフォーマットおよび内容は、本願において限定されることはない。

【0278】

前述の方式１および方式２は、ターゲット情報を取得する方式の単なる例にすぎず、ＳＦＦは代替的に、別の方式でターゲット情報を取得してもよいことを理解されたい。ターゲット情報の情報源が本実施形態において限定されることはない。

【0279】

第２のＳＲｖ６パケットで制御フラグおよびターゲット情報を搬送することについては、複数の実装形態がある。以下では、一例を用いて、制御フラグおよびターゲット情報を搬送する方式を説明する。

【0280】

ＳＲｖ６パケットの場合、任意選択の情報を搬送するのに以下の３つのメカニズムを用いることができる。

【0281】

メカニズム１：ホップバイホップオプションヘッダ（Ｈｏｐ－ｂｙ－Ｈｏｐ Ｏｐｔｉｏｎ Ｈｅａｄｅｒ、ＨＢＨ）が、各ホップの制御プレーンにより処理された情報を搬送する。

【0282】

この段落では、ホップバイホップオプションヘッダについて説明する。ホップバイホップオプションヘッダは、ＩＰｖ６拡張ヘッダである。ホップバイホップオプションヘッダは、転送プロセスで通過する通過ノードのそれぞれによって処理されてよい。ＩＰｖ６パケットがホップバイホップオプションヘッダを搬送する場合、ホップバイホップオプションヘッダに先行するヘッダにあるｎｅｘｔ ｈｅａｄｅｒフィールドの値が０である。任意選択で、ホップバイホップオプションヘッダは、ＩＰｖ６ヘッダの後に続く最初のＩＰｖ６拡張ヘッダである。言い換えれば、ホップバイホップオプションヘッダの前のヘッダはＩＰｖ６ヘッダであり、ＩＰｖ６ヘッダのｎｅｘｔ ｈｅａｄｅｒフィールドの値が０である。図１６を参照されたい。図１６は、ホップバイホップオプションヘッダの構造の一例である。ホップバイホップオプションヘッダには、ネクストヘッダのインデックス（Ｎｅｘｔ Ｈｅａｄｅｒ）フィールド、ヘッダ拡張長（ｈｅａｄｅｒ Ｅｘｔｅｎｄｅｄ Ｌｅｎｇｔｈ、略してＨｄｒ Ｅｘｔ Ｌｅｎ）フィールド、および少なくとも１つのオプションが含まれている。ホップバイホップオプションヘッダにあるＮｅｘｔ Ｈｅａｄｅｒフィールドの値が、ホップバイホップオプションヘッダの後に続く最初のヘッダのタイプを示すのに用いられる。ホップバイホップオプションヘッダにあるＨｄｒ Ｅｘｔ Ｌｅｎフィールドの値が、ホップバイホップオプションヘッダの長さを示すのに用いられる。ホップバイホップオプションヘッダのオプションは、ホップバイホップオプションとも呼ばれている。ホップバイホップオプションは通常、ＴＬＶのフォーマットで符号化されている。１つのホップバイホップオプションには、オプションタイプフィールド、オプション長フィールド、および値フィールドが含まれている。

【0283】

メカニズム２：宛先オプションヘッダ（Ｄｅｓｔｉｎａｔｉｏｎ Ｏｐｔｉｏｎ Ｈｅａｄｅｒ）が、ｒｏｕｔｉｎｇ ｈｅａｄｅｒ通過ノードおよび／またはターゲットノードにより処理される情報を搬送する。

【0284】

メカニズム３：ＳＲＨが情報を搬送する。ＳＲＨ自体には１つまたは複数のＴＬＶが含まれており、ＳＲＨのＴＬＶは、ハッシュベースのメッセージ認証コード（Ｈａｓｈ－ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ、ＨＭＡＣ）ダイジェストおよびＳＦＣ ｍｅｔａｄａｔａなどの情報を搬送するのに用いられてよい。

【0285】

本願のいくつかの実施形態では、制御フラグおよびターゲット情報のうちの少なくとも一方を搬送するのに前述のメカニズム１が用いられる。ＳＦＦにより送信される第２のＳＲｖ６パケットにはホップバイホップオプションヘッダが含まれており、ホップバイホップオプションヘッダには制御フラグおよびターゲット情報のうちの少なくとも一方が含まれている。例えば、第２のＳＲｖ６パケットには、ＩＰｖ６標準ヘッダ、制御フラグおよびターゲット情報を含むホップバイホップオプションヘッダ、ＳＲＨおよびホップバイホップオプションヘッダ以外の別のＩＰｖ６拡張ヘッダ、ならびにペイロードが含まれている。ホップバイホップオプションヘッダは、第２のＳＲｖ６パケットにおいて最初のＩＰｖ６拡張ヘッダである。ホップバイホップオプションヘッダは、ＩＰｖ６標準ヘッダの後に且つＳＲＨおよび別のＩＰｖ６拡張ヘッダの前に配置されている。さらに、ＳＲＨおよびホップバイホップオプションヘッダ以外の別のＩＰｖ６拡張ヘッダは、第２のＳＲｖ６パケットの任意選択部分である。いくつかの他の実施形態では、第２のＳＲｖ６パケットには、ＩＰｖ６標準ヘッダ、制御フラグおよびターゲット情報を含むホップバイホップオプションヘッダ、ならびにペイロードが含まれている。

【0286】

ホップバイホップオプションヘッダを用いて制御フラグまたはターゲット情報を搬送することについては、複数の方式がある。例えば、制御フラグまたはターゲット情報を搬送するために、新たなＴＬＶがホップバイホップオプションヘッダに拡張される。このＴＬＶは、符号化フォーマットである。１つのＴＬＶには、タイプ（ｔｙｐｅ）フィールド、長さ（ｌｅｎｇｔｈ）フィールド、および値（ｖａｌｕｅ）フィールドが含まれている。タイプフィールドは、ＴＬＶの意味を示すのに用いられ、値フィールドはＴＬＶの内容を示すのに用いられ、長さフィールドはＴＬＶの長さを示すのに用いられる。具体的には、ホップバイホップオプションヘッダにはＴＬＶが含まれており、ＴＬＶは制御フラグおよびターゲット情報のうちの少なくとも一方を搬送するのに用いられる。

【0287】

制御フラグおよび／またはターゲット情報を搬送するＴＬＶのフォーマットについては、複数のケースがある。任意選択で、制御フラグおよび／またはターゲット情報はＴＬＶの値フィールドに位置しており、ＴＬＶのタイプフィールドは、ＴＬＶが制御フラグおよび／またはターゲット情報を搬送することを示し、ＴＬＶのタイプフィールドの値が、例えば、新たに追加されたタイプ値である。例えば、制御フラグおよび／またはターゲット情報を搬送するＴＬＶは、ホップバイホップオプションヘッダのオプションであり、このオプションにはオプションタイプ（ＯｐｔｉｏｎＴｙｐｅ、ＯｐｔＴｙｐｅ）フィールド、オプション長（Ｏｐｔ Ｌｅｎ）フィールド、および制御フラグが含まれている。オプションタイプフィールドはオプションが制御フラグおよび／またはターゲット情報を搬送することを示し、オプション長フィールドはオプションの長さを示し、ＯｐｔＴｙｐｅフィールドの値が新たに追加されたＯｐｔＴｙｐｅ値である。追加されたＯｐｔＴｙｐｅ値は、特定の状況に基づいて、標準化方式であっても非標準化方式であってもよい。非標準化方式の場合、ＯｐｔＴｙｐｅ値は、インターネット番号割当機関（Ｉｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒｓ Ａｕｔｈｏｒｉｔｙ、ＩＡＮＡ）により予約された複数の実験的オプション値（Ｅｘｐｅｒｉｍｅｎｔａｌ Ｏｐｔｉｏｎ ｖａｌｕｅ）を用いてよい。

【0288】

制御フラグおよび／またはターゲット情報を搬送するＴＬＶのタイプには、複数のケースがある。任意選択で、制御フラグおよび／またはターゲット情報を搬送するＴＬＶは、新たなトップ（ｔｏｐ）ＴＬＶであり、制御フラグおよび／またはターゲット情報を搬送するＴＬＶのタイプ（ｔｙｐｅ）フィールドの値が、未使用のｔｏｐ ＴＬＶタイプを示す。任意選択で、制御フラグおよび／またはターゲット情報を搬送するＴＬＶは、ｔｏｐ ＴＬＶの新たなサブＴＬＶであり、制御フラグおよび／またはターゲット情報を搬送するＴＬＶのｔｙｐｅフィールドの値が、未使用のサブＴＬＶタイプを示す。任意選択で、制御フラグおよび／またはターゲット情報を搬送するＴＬＶは、ｔｏｐ ＴＬＶの新たなサブサブＴＬＶ（ｓｕｂ－ｓｕｂ－ＴＬＶ）であり、制御フラグおよび／またはターゲット情報を搬送するＴＬＶのｔｙｐｅが、未使用のｓｕｂ－ｓｕｂ－ＴＬＶタイプを示す。制御フラグおよび／またはターゲット情報を搬送するＴＬＶがｔｏｐ ＴＬＶ、ｓｕｂ－ＴＬＶ、またはｓｕｂ－ｓｕｂ－ＴＬＶのいずれであるかは、本実施形態において限定されることはない。

【0289】

任意選択で、制御フラグはＴＬＶの値フィールドにおいて１つのビットを占有する。例えば、制御フラグはＴＬＶの値フィールドにおいてビット［ａ］を占有する。ビット［ａ］を設定した場合、ＳＦデバイスは、第２のＳＲｖ６パケットにおいて制御フラグの後に続くＩＰｖ６拡張ヘッダをオフセットするよう指示される。ビット［ａ］を設定しない場合、ＳＦデバイスは、第２のＳＲｖ６パケットにおいて制御フラグの後に続くＩＰｖ６拡張ヘッダをオフセットしないよう指示される。

【0290】

任意選択で、ＳＦＦは、１つのＴＬＶを用いてターゲット情報および制御フラグを搬送する。この方式では、ターゲット情報および制御フラグは、第２のＳＲｖ６パケットの同じＴＬＶに位置している。例えば、第２のＳＲｖ６パケットのホップバイホップオプションヘッダには第１のＴＬＶが含まれており、第１のＴＬＶの値フィールドにはターゲット情報および制御フラグが含まれている。第１のＴＬＶのタイプフィールドは、第１のＴＬＶがターゲット情報および制御フラグを搬送することを示す。ターゲット情報および制御フラグは、第１のＴＬＶの値フィールドにおいて異なるビットを占有する。

【0291】

任意選択で、ＳＦＦは、２つのＴＬＶを用いてターゲット情報および制御フラグを別々に搬送する。この方式では、ターゲット情報および制御フラグは、第２のＳＲｖ６パケットの異なるＴＬＶに位置している。例えば、第２のＳＲｖ６パケットのホップバイホップオプションヘッダには、第１のＴＬＶおよび第２のＴＬＶが含まれている。第１のＴＬＶの値フィールドには制御フラグが含まれており、第１のＴＬＶのタイプフィールドは、第１のＴＬＶが制御フラグを搬送することを示す。第２のＴＬＶの値フィールドにはターゲット情報が含まれており、第２のＴＬＶのタイプフィールドは、第２のＴＬＶがターゲット情報を搬送することを示す。任意選択で、第１のＴＬＶのタイプフィールドの値が、第２のＴＬＶのタイプフィールドの値と異なる。言い換えれば、第１のＴＬＶと第２のＴＬＶとは、異なるＴｙｐｅを用いて区別される。あるいは、第１のＴＬＶおよび第２のＴＬＶには両方ともｆｌａｇフィールドが含まれており、第１のＴＬＶのｆｌａｇフィールドの値が第２のＴＬＶのｆｌａｇフィールドの値と異なる。言い換えれば、第１のＴＬＶと第２のＴＬＶとは、異なるｆｌａｇを用いて区別される。

【0292】

図１７を参照されたい。図１７は、制御フラグおよびターゲット情報を搬送するホップバイホップオプションヘッダの一例である。制御フラグおよびターゲット情報の両方は、オプションタイプフィールドおよびオプション長フィールドの後に位置している。図１７のＶＰＮ ＩＤは、ターゲット情報の一例である。図１７では、フィールドの括弧の後に続く数字がフィールドのバイト長を示している。例えば、Ｎｅｘｔ Ｈｅａｄｅｒ（１）は、Ｎｅｘｔ Ｈｅａｄｅｒフィールドが１つのバイトを占有することを示している。Ｎｅｘｔ ＨｅａｄｅｒフィールドおよびＨｄｒ Ｅｘｔ Ｌｅｎフィールドは、ＲＦＣ８２００において定義されているＩＰｖ６ホップバイホップオプションヘッダの一般的なフィールドである。ＯｐｔＴｙｐｅフィールドおよびＯｐｔＬｅｎフィールドは、ＲＦＣ８２００において定義されているオプションの一般的なフィールドである。図１７に示すＯｐｔＴｙｐｅフィールドの意味とは、例えば、ホップバイホップオプションには制御フラグおよびＶＰＮ ＩＤが含まれているということである。

【0293】

任意選択で、ホップバイホップオプションヘッダを用いて制御フラグを搬送する方式には、以下の方式ａおよび方式ｂが含まれている。

【0294】

方式ａ：ＳＦＦのアップストリームデバイスが、ホップバイホップオプションヘッダを第１のＳＲｖ６パケットにカプセル化する。任意選択で、この場合、ＳＦＦはホップバイホップオプションヘッダをカプセル化する必要はないが、アップストリームデバイスによりカプセル化されるホップバイホップオプションヘッダにオプション（ｏｐｔｉｏｎ、ＨＢＨ ｏｐｔｉｏｎとも呼ばれる）を追加し、追加したオプションに制御フラグを含める。

【0295】

方式ａにおいて、第１のＳＲｖ６パケットにはホップバイホップオプションヘッダが含まれており、第２のＳＲｖ６パケットにもホップバイホップオプションヘッダが含まれている。第２のＳＲｖ６パケットに含まれたホップバイホップオプションヘッダと第１のＳＲｖ６パケットに含まれたホップバイホップオプションヘッダの関係には、以下のことが含まれている。すなわち、第２のＳＲｖ６パケットに含まれたホップバイホップオプションヘッダは、第１のＳＲｖ６パケットに含まれたホップバイホップオプションヘッダより多くのオプションを含んでいる。第１のＳＲｖ６パケットと比較して、第２のＳＲｖ６パケットに追加されたオプションには制御フラグが含まれている。

【0296】

例えば、ＳＦＦのアップストリームデバイスはホップバイホップオプションヘッダを第１のＳＲｖ６パケットにカプセル化する。ホップバイホップオプションヘッダには第１のＴＬＶが含まれている。ＳＦＦは、第１のＳＲｖ６パケットのホップバイホップオプションヘッダに第２のＴＬＶを追加し、第２のＴＬＶには制御フラグが含まれている。第２のＳＲｖ６パケットには、第１のＴＬＶおよび第２のＴＬＶが含まれている。

【0297】

方式ｂ：ＳＦＦにより受信される第１のＳＲｖ６パケットには、ホップバイホップオプションヘッダが含まれていない。この場合、ＳＦＦはホップバイホップオプションヘッダを生成し、このホップバイホップオプションヘッダを第１のＳＲｖ６パケットに追加する。

【0298】

以下では、３つのメカニズムを分析し、（１）～（４）によってメカニズム１の効果について説明する。

【0299】

（１）メカニズム２の場合、標準仕様によれば、宛先オプションヘッダを用いて、通過ノードおよび／またはターゲットノードに情報を渡す。しかしながら、ＳＦデバイスは通常、通過ノードでもターゲットノードでもなく、メカニズム１の選択は標準仕様に適合しない。メカニズム３については、ＳＦデバイスが通常、ＳＲＨの識別をサポートしないため、ＳＲＨを用いて制御フラグを搬送する方式が直接的に排除されてよい。

【0300】

（２）メカニズム１については、ホップバイホップオプションヘッダが制御フラグを搬送するのに用いられる場合、ホップバイホップオプションヘッダがＩＰｖ６パケットの最初のＩＰｖ６拡張ヘッダとして常に用いられるため、ホップバイホップオプションヘッダがＳＦデバイスによって容易に解析される。これにより、ＳＦデバイスはホップバイホップオプションヘッダに基づいて制御フラグとターゲット情報とを識別して、関連する処理を行うことができるようになる。したがって、制御フラグをＳＦデバイスに伝送するのにホップバイホップオプションヘッダを用いるのが、３つのメカニズムの中で最も適切である。

【0301】

（３）ＩＰｖ６ Ｏｐｔｉｏｎ Ｔｙｐｅの最上位ビット２つで、通過ノードが未認識オプションを処理する方式を定義することにより、ＳＦＦおよびＳＦデバイスは、ワンホップＩＰリンク（ｏｎ－ｌｉｎｋ）に展開される必要がなくなる。標準仕様によれば、オプションタイプ識別子が内部で符号化され、オプションタイプ識別子は、オプションタイプを識別できないときに、最上位ビット２つを用いて、ＩＰｖ６パケットを処理するノードにより行われるオペレーションを示す。具体的には、オプションタイプ識別子の最上位ビット２つの値が００である場合、ノードはオプションを省略し、パケットヘッダの処理を続ける。オプションタイプ識別子の最上位ビット２つの値が０１である場合、ノードはパケットを破棄する。オプションタイプ識別子の最上位ビット２つの値が１０である場合、ノードはパケットを破棄する。オプションタイプ識別子の最上位ビット２つの値が１１である場合、ノードはパケットを破棄して、パケットの宛先アドレスがマルチキャストアドレスではないときに、インターネット制御メッセージプロトコル（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ、ＩＣＭＰ）のパラメータ問題メッセージをパケットの送信元アドレスに送信する。

【0302】

（４）下位互換性を保証できる。具体的には、本実施形態では、制御フラグを搬送するのにＩＰｖ６オプション（ＩＰｖ６ ｏｐｔｉｏｎ）が用いられる。これは、ＲＦＣ４７２７で定義されている実験的オプションタイプ（Ｅｘｐｅｒｉｍｅｎｔａｌ Ｏｐｔｉｏｎ ｔｙｐｅ）空間を用いて実現できるため、規格の互換性が確保されるようになる。

【0303】

Ｓ２０４：ＳＦＦは第２のＳＲｖ６パケットをＳＦデバイスに送信する。

【0304】

Ｓ２０５：ＳＦデバイスは第２のＳＲｖ６パケットをＳＦＦから受信する。

【0305】

Ｓ２０６：ＳＦデバイスは第２のＳＲｖ６パケットに含まれた制御フラグを取得し、ＳＦデバイスは、この制御フラグに基づいて、第２のＳＲｖ６パケットにおいて制御フラグの後に続くＩＰｖ６拡張ヘッダをオフセットし、サービス処理を行う。

【0306】

ＳＦＦとＳＦデバイス（ＳＦ ｄｅｖｉｃｅ）との間で転送されるパケットはＳＲｖ６パケットであるが、ＳＦＦおよびＳＦデバイスは転送パケットについて異なる理解をしている。ＳＦＦの観点から見れば、ＳＦＦは転送されるパケットをＳＲｖ６パケットとみなしている。ＳＦデバイスの観点から見れば、ＳＦデバイスはＳＦＦから受信するパケットをＳＲｖ６パケットではなくＩＰｖ６パケットとみなしている。言い換えれば、ＳＦデバイスは、第２のＳＲｖ６パケットを受信した後に、第２のＳＲｖ６パケットを、ＩＰｖ６拡張ヘッダを含むＩＰｖ６パケットとして用いる。ＳＦデバイスが、制御フラグに基づいて、第２のＳＲｖ６パケットはそのＩＰｖ６拡張ヘッダがオフセットされるパケットであるとみなした後に、ＳＦデバイスは第２のＳＲｖ６パケットにおいて制御フラグの後に続くＩＰｖ６拡張ヘッダをオフセットする。具体的には、ＳＦデバイスは、制御フラグの後に続くＩＰｖ６拡張ヘッダを省略し、制御フラグの後に続くＩＰｖ６拡張ヘッダを解析しないで、サービス関連の処理を実施する。第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダにはＳＲＨが含まれているため、ＳＦデバイスは、ＳＲＨを未認識拡張ヘッダとしてオフセットし、ＳＲＨの内容を解析する必要がない。

【0307】

ＳＦデバイスがサービス処理を行うことには、複数の実装形態がある。任意選択で、ＳＦデバイスは、第２のＳＲｖ６パケットのペイロードに基づいてサービス処理を行う。任意選択で、挿入モードに対応して、ＳＦデバイスは、第２のＳＲｖ６パケットにおいてＩＰｖ６標準ヘッダまたはホップバイホップオプションヘッダの後に続くＳＲＨ以外の別のＩＰｖ６拡張ヘッダに基づいて、サービス処理を行う。

【0308】

例えば、図１５を参照されたい。カプセル化モードでは、ＳＦデバイスにより行われるサービス処理は、ペイロード部分の処理を含む。挿入モードでは、ＳＦデバイスにより行われるサービス処理は、ペイロード部分の処理を含み、任意選択で、ＳＦデバイスにより行われるサービス処理はさらに、別の拡張ヘッダＡの処理および別の拡張ヘッダＢの処理を含む。

【0309】

制御フラグに基づいてＳＦデバイスにより行われるオフセットアクションとは、ＳＲｖ６に関連したヘッダカプセル化のオフセットを指す。ＳＦデバイスにより行われるオフセットアクションとしては、少なくともＳＲＨをオフセットするアクションが挙げられる。任意選択で、ＳＦにより行われるオフセットアクションとしてはさらに、ＳＲＨ以外の別のＩＰｖ６拡張ヘッダをオフセットすることが挙げられる。任意選択で、ＳＦにより行われるオフセットアクションとしてはさらに、最外ＩＰｖ６標準ヘッダをオフセットすることが挙げられる。

【0310】

以下では、例として方式Ａおよび方式Ｂを用いて、ＳＦデバイスが制御フラグに基づいてオフセットアクションをどのように行うかを説明する。方式Ａは、Ｓ２０３の方式（１）に対応する。方式Ａに示されていない詳細については、前述の方式（１）を参照されたい。方式Ｂは、Ｓ２０３の方式（２）に対応する。方式Ｂに示されていない詳細については、前述の方式（２）を参照されたい。

【0311】

方式Ａ：この方式は挿入モードに対応する。第２のＳＲｖ６パケットのＳＲＨをオフセットするようＳＦデバイスに指示するのに制御フラグが用いられる場合、ＳＦデバイスは、制御フラグに基づいて第２のＳＲｖ６パケットのＳＲＨをオフセットする。方式Ａでは、制御フラグに基づいて、ＳＦデバイスはＩＰｖ６拡張ヘッダのＳＲＨをオフセットし、制御フラグの後に続くＳＲＨ以外の別のＩＰｖ６拡張ヘッダを解析して処理する。

【0312】

方式Ｂ：この方式はカプセル化モードに対応する。第２のＳＲｖ６パケットのＳＲＨとＳＲＨ以外の別のＩＰｖ６拡張ヘッダとをオフセットするようＳＦデバイスに指示するのに制御フラグが用いられる場合、ＳＦデバイスは、制御フラグに基づいて、第２のＳＲｖ６パケットのＳＲＨとＳＲＨ以外の別のＩＰｖ６拡張ヘッダとをオフセットする。方式Ｂでは、制御フラグに基づいて、ＳＦデバイスはＩＰｖ６拡張ヘッダのＳＲＨをオフセットするだけでなく、制御フラグの後に続くＳＲＨ以外の別のＩＰｖ６拡張ヘッダもオフセットする。したがって、制御フラグを含むＩＰｖ６拡張ヘッダ（例えば、ホップバイホップオプションヘッダ）の後に続く最初のＩＰｖ６拡張ヘッダから最後のＩＰｖ６拡張ヘッダまでは、ＳＦデバイスにより処理されることはない。

【0313】

ＳＦデバイスが制御フラグの後に続くＩＰｖ６拡張ヘッダをオフセットすることは、例えば、ＩＰｖ６拡張ヘッダのＨｄｒ Ｅｘｔ Ｌｅｎフィールドを用いて実現される。具体的には、規格に定義されているように、ＩＰｖ６ Ｒｏｕｔｉｎｇ ｈｅａｄｅｒにはＨｄｒ Ｅｘｔ Ｌｅｎフィールドが含まれている。Ｈｄｒ Ｅｘｔ Ｌｅｎフィールドは、拡張ヘッダの長さを示すのに用いられる。Ｒｏｕｔｉｎｇ ｈｅａｄｅｒを処理しないデバイスは、Ｈｄｒ Ｅｘｔ Ｌｅｎフィールドを用いて、Ｒｏｕｔｉｎｇ ｈｅａｄｅｒ範囲全体を直接的にオフセットしてよい。ＳＲＨは、ＩＰｖ６ Ｒｏｕｔｉｎｇ ｈｅａｄｅｒのサブタイプである。図２に示すように、ＳＲＨにもＨｄｒ Ｅｘｔ Ｌｅｎフィールドが含まれている。ＳＲＨに含まれたＨｄｒ Ｅｘｔ Ｌｅｎフィールドは、ＳＲＨヘッダの長さを示すのに用いられる。したがって、ＳＦデバイスは、ＳＲＨに含まれたＨｄｒ Ｅｘｔ Ｌｅｎフィールドに基づいて、ＳＲｖ６パケットのＳＲＨの終了位置を判定してよく、ＳＦデバイスはＳＲＨの後に続くフィールドから開始するパケットを解析し、ＳＲＨ全体を直接的にオフセットする。Ｈｄｒ Ｅｘｔ Ｌｅｎで示す長さは通常、ＩＰｖ６拡張ヘッダの最初の８バイトを含まない。言い換えれば、Ｈｄｒ Ｅｘｔ Ｌｅｎが示す長さは、ＩＰｖ６拡張ヘッダの９番目のバイトから最後のバイトまでの長さである。Ｈｄｒ Ｅｘｔ Ｌｅｎは、８バイト単位であってよい。

【0314】

第２のＳＲｖ６パケットはそのＩＰｖ６拡張ヘッダをオフセットする必要があるパケットであることをＳＦデバイスが識別することについては、複数の実装形態がある。方法２００は、識別のために制御フラグが用いられる一例を用いて示されている。例えば、ＳＦデバイスが第２のＳＲｖ６パケットを受信した後に、ＳＦデバイスは、第２のＳＲｖ６パケットが制御フラグを含んでいるかどうかを判定する。第２のＳＲｖ６パケットが制御フラグを含んでいることをＳＦデバイスが識別した場合、ＳＦデバイスは、第２のＳＲｖ６パケットにおいて制御フラグの後に続くＩＰｖ６拡張ヘッダを直接的にオフセットする。

【0315】

それに加えて、第２のＳＲｖ６パケットがさらにターゲット情報を含んでいる場合、ＳＦデバイスは、ターゲット情報に基づいて、ペイロードに対してサービス処理を行う。ターゲット情報の意味は、予め設定されてＳＦデバイスに格納されてよい。

【0316】

ＳＦデバイスが第２のＳＲｖ６パケットに基づいてサービス処理を行う段階は、任意選択の段階であることに留意されたい。いくつかの他の実施形態では、ＳＦデバイスはサービス処理の段階を行わない。

【0317】

Ｓ２０７：ＳＦデバイスは、制御フラグに基づいて第３のＳＲｖ６パケットをＳＦＦに送信する。

【0318】

パケットをＳＦＦに戻すプロセスにおいてＩＰｖ６拡張ヘッダを戻すようＳＦデバイスに指示するのに制御フラグがさらに用いられる場合、ＳＦデバイスは、制御フラグの指示に基づいてサービス処理を行うときに、オフセットされたＩＰｖ６拡張ヘッダを常に保持している。ＳＦデバイスが第３のＳＲｖ６パケットをＳＦＦに戻すプロセスでは、ＳＦデバイスはオフセットされたＩＰｖ６拡張ヘッダをＳＦＦに戻す。

【0319】

第３のＳＲｖ６パケットは、ＳＦデバイスがサービス処理を行うことで取得されるパケットであり、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じＳＲＨを有している。任意選択で、第３のＳＲｖ６パケットのペイロードは、第２のＳＲｖ６パケットのペイロードに基づいてサービス処理を行うことで取得される。ＳＦデバイスは、ＳＦＦにより事前にＳＦデバイスに送信されたＳＲＨ（すなわち、第２のＳＲｖ６パケットのＳＲＨ）を元のままＳＦＦに戻すために、第３のＳＲｖ６パケットをＳＦＦに送信する。以下では、ケースＩおよびケースＩＩを用いて、ＳＦデバイスがオフセットされたＩＰｖ６拡張ヘッダを戻す一例を説明する。

【0320】

任意選択で、制御フラグはさらに、パケットをＳＦＦに戻すプロセスにおいて、第２のＳＲｖ６パケットのホップバイホップオプションヘッダを戻すようＳＦデバイスに指示するのに用いられる。

【0321】

ケースＩ：このケースは挿入モードに対応する。制御フラグはさらに、パケットをＳＦＦに戻すプロセスにおいて、第２のＳＲｖ６パケットのＳＲＨを戻すようＳＦデバイスに指示するのに用いられ、ＳＦデバイスは、制御フラグに基づいて第２のＳＲｖ６パケットのＳＲＨを戻す。ケースＩでは、ＳＦデバイスがＳＲＨ以外の別のＩＰｖ６拡張ヘッダを戻すかどうかは任意選択である。

【0322】

ケースＩＩ：このケースはカプセル化モードに対応する。制御フラグはさらに、パケットをＳＦＦに戻すプロセスにおいて、第２のＳＲｖ６パケットのＳＲＨとＳＲＨ以外の別のＩＰｖ６拡張ヘッダとを戻すようＳＦデバイスに指示するのに用いられ、ＳＦデバイスは、制御フラグに基づいて、第２のＳＲｖ６パケットのＳＲＨだけでなく、ＳＲＨ以外の別のオフセットされたＩＰｖ６拡張ヘッダも戻す。例えば、ＳＦデバイスは、第２のＳＲｖ６パケットにおいてホップバイホップオプションヘッダの後に続くそれぞれのＩＰｖ６拡張ヘッダを戻す。任意選択で、ＳＦデバイスは第２のＳＲｖ６パケットのＩＰｖ６標準ヘッダを戻す。

【0323】

例えば、先頭から末尾への順で、第２のＳＲｖ６パケットには、ＩＰｖ６標準ヘッダ、制御フラグを含むホップバイホップオプションヘッダ、別の拡張ヘッダＡ、ＳＲＨ、別の拡張ヘッダＢ、およびＩＰｖ４パケット１が連続的に含まれている。制御フラグは、別の拡張ヘッダＡ、ＳＲＨ、および別の拡張ヘッダＢをオフセットするよう指示するのに用いられる。ＳＦデバイスは、制御フラグに基づいて第３のＳＲｖ６パケットをＳＦＦに戻す。第３のＳＲｖ６パケットには、ＩＰｖ６標準ヘッダ、別の拡張ヘッダＡ、ＳＲＨ、別の拡張ヘッダＢ、およびＩＰｖ４パケット２が連続的に含まれている。ＩＰｖ４パケット１は、第２のＳＲｖ６パケットにおけるペイロードの一例であり、ＩＰｖ４パケット２は第３のＳＲｖ６パケットにおけるペイロードの一例であり、ＩＰｖ４パケット２は、ＳＦデバイスがＩＰｖ４パケット１に対してサービス処理を行った後に取得される。

【0324】

ＳＦデバイスがペイロードに対してサービス処理を行う場合、ＳＦデバイスは、ＳＦＦから事前に受信したＳＲＨを常に保持している。ＳＦデバイスは、サービス処理を完了させた後に、ＳＦＦから事前に受信したＳＲＨを元のままＳＦＦに戻す。したがって、ＳＦデバイスからＳＦＦに戻されるＳＲｖ６パケット（第３のＳＲｖ６パケット）に含まれたＳＲＨは、ＳＦデバイスがＳＦＦから事前に受信したＳＲｖ６パケット（第２のＳＲｖ６パケット）に含まれたＳＲＨと同じである。すなわち、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じＳＲＨを有している。

【0325】

この段落では、第３のＳＲｖ６パケットのホップバイホップオプションヘッダと第２のＳＲｖ６パケットのホップバイホップオプションヘッダとの関係について、一例を用いて説明する。ホップバイホップオプションヘッダを用いて制御フラグを搬送する場合、任意選択で、制御フラグはさらに、パケットをＳＦＦに戻すプロセスにおいて、第２のＳＲｖ６パケットのホップバイホップオプションヘッダを戻すようＳＦデバイスに指示するのに用いられる。ＳＦデバイスは、ＳＦＦから事前に受信したホップバイホップオプションヘッダを保持している。ＳＦデバイスは、サービス処理を完了させた後に、ＳＦＦから事前に受信したホップバイホップオプションヘッダを元のままＳＦＦに戻す。これにより、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じホップバイホップオプションヘッダを有するようになる。任意選択で、ＳＦデバイスは制御フラグを修正し、制御フラグ以外のホップバイホップオプションヘッダの別の部分を元のまま戻す。これにより、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは異なる制御フラグを有するようになる。例えば、ＳＦデバイスは必要に応じて制御フラグに関連情報を追加する。これにより、第３のＳＲｖ６パケットの制御フラグは、第２のＳＲｖ６パケットの制御フラグより多くの内容を有するようになる。任意選択で、ＳＦデバイスは、制御フラグが位置しているオプションを修正し、制御フラグが位置しているオプション以外のホップバイホップオプションヘッダの別の部分を元のまま戻す。これにより、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは異なるオプションを有するようになり、異なるオプションには当該制御フラグが含まれている。任意選択で、ＳＦデバイスは、制御フラグが位置しているオプションを元のまま戻すが、制御フラグが位置しているオプション以外のホップバイホップオプションヘッダの別の部分を修正する。これにより、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じオプションを有するようになり、同じオプションには当該制御フラグが含まれている。

【0326】

この段落では、第３のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒと第２のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒとの関係について、一例を用いて説明する。任意選択で、ＳＦデバイスは最外ＩＰｖ６ ｈｅａｄｅｒを保持する。ＳＦデバイスは、サービス処理を完了させた後に、最外ＩＰｖ６ ｈｅａｄｅｒを元のままＳＦＦに戻す。これにより、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じ最外ＩＰｖ６ ｈｅａｄｅｒを有するようになる。任意選択で、ＳＦデバイスは最外ＩＰｖ６ ｈｅａｄｅｒを修正する。これにより、第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは異なる最外ＩＰｖ６ ｈｅａｄｅｒを有するようになる。例えば、第２のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒには、ＳＦデバイスに渡されるいくつかの情報が含まれており、この情報はＳＦデバイスがサービス処理を行うのに用いられる。ＳＦデバイスは、情報に対してサービス処理を行った後に、この情報を削除する。これにより、第３のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒは第２のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒより少ない内容を有することになる。あるいは、ＳＦデバイスは、サービス処理を行うときに、いくつかの情報を最外ＩＰｖ６ ｈｅａｄｅｒに追加し、最外ＩＰｖ６ ｈｅａｄｅｒを通じてこの情報をＳＦＣの別のデバイスに渡す。したがって、第３のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒは、第２のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒより多くの内容を有している。任意選択で、ＳＦデバイスが最外ＩＰｖ６ ｈｅａｄｅｒを保持するかどうかは、ＳＦＦに設定されているＳＲｖ６パケット生成モードに依存する。例えば、ＳＲｖ６パケット生成モードがＳＦＦにカプセル化モードとして設定されている場合、ＳＦデバイスは最外ＩＰｖ６ ｈｅａｄｅｒを元のまま戻すように構成されている。ＳＲｖ６パケット生成モードがＳＦＦに挿入モードとして設定されている場合、ＳＦデバイスは最外ＩＰｖ６ ｈｅａｄｅｒを元のまま戻すように、または最外ＩＰｖ６ ｈｅａｄｅｒを修正するように構成されている。

【0327】

Ｓ２０８：ＳＦＦはＳＦデバイスから第３のＳＲｖ６パケットを受信する。

【0328】

Ｓ２０９：ＳＦＦは、第３のＳＲｖ６パケットのＳＲＨに基づいて、第３のＳＲｖ６パケットに対して転送処理を行う。

【0329】

ＳＦＦがＳＦデバイスから戻されたパケットを受信すると、ＳＦＦは更新されたＡｃｔｉｖｅ ＳＩＤに基づいて転送処理を続ける。更新されたＡｃｔｉｖｅ ＳＩＤは、例えば、セグメントリストにあるＥｎｄ．ＰＴ．ＳＩＤの次のＳＩＤである。前述のケースＡに対応して、任意選択で、ＳＦＦが最初にＡｃｔｉｖｅ ＳＩＤを更新してからパケットをＳＦデバイスに送信する方式を用いる場合、ＳＦＦは、Ｓ２０３を行うときにＡｃｔｉｖｅ ＳＩＤを更新している。これにより、第２のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒにある宛先アドレスは、更新されたＡｃｔｉｖｅ ＳＩＤになる。ＳＦデバイスは最外ＩＰｖ６ ｈｅａｄｅｒの宛先アドレスを変えないままにしておくので、ＳＦデバイスから戻される第３のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒにある宛先アドレスは、更新されたＡｃｔｉｖｅ ＳＩＤである。ＳＦＦは、第３のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒにある宛先アドレスに基づいてローカルＳＩＤテーブルに照会し、宛先アドレスが一致したローカルＳＩＤテーブルのＳＩＤに基づいて転送処理を行う。前述のケースＢに対応して、任意選択で、ＳＦデバイスがパケットを戻した後にＡｃｔｉｖｅ ＳＩＤを更新する方式をＳＦＦが用いる場合、ＳＦＦはＳ２０３を行うときにＡｃｔｉｖｅ ＳＩＤを更新しない。これにより、第２のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒにある宛先アドレスは依然としてＥｎｄ．ＰＴ．ＳＩＤである。この場合、ＳＦＦから戻される第３のＳＲｖ６パケットの最外ＩＰｖ６ ｈｅａｄｅｒにある宛先アドレスはＥｎｄ．ＰＴ．ＳＩＤである。ＳＦＦは、第３のＳＲｖ６パケットを受信した後に、第３のＳＲｖ６パケットのＡｃｔｉｖｅ ＳＩＤを最初に更新してから、更新されたＡｃｔｉｖｅ ＳＩＤに基づいて転送処理を行う。

【0330】

任意選択で、ＳＦＦが制御フラグをカプセル化するアクションとは異なり、ＳＦＦがＳＦデバイス（ＳＦ ｄｅｖｉｃｅ）から戻されたパケットを受信すると、ＳＦＦは、第３のＳＲｖ６パケットの制御フラグを取り除いて第４のＳＲｖ６パケットを取得し、第４のＳＲｖ６パケットを送信する。第４のＳＲｖ６パケットは、制御フラグを含んでいない。

【0331】

任意選択で、制御フラグがホップバイホップオプションヘッダを用いて搬送される場合、ＳＦＦがＳＦから戻されたパケットから取り除く部分が、ＳＦＦが事前にカプセル化する部分と同じである。

【0332】

例えば、第３のＳＲｖ６パケットのホップバイホップオプションヘッダがＳＦＦのアップストリームデバイスによりカプセル化され、且つＳＦＦがホップバイホップオプションヘッダを追加するのではなく、制御フラグを搬送するオプションをホップバイホップオプションヘッダに追加する場合、ＳＦＦは制御フラグを搬送するオプションを取り除き、制御フラグを搬送するオプション以外の、ホップバイホップオプションヘッダの別のオプションを保持する。このように、第４のＳＲｖ６パケットには、制御フラグを搬送するオプションが含まれているのではなく、ホップバイホップオプションヘッダの別のオプションが含まれている。これにより、アップストリームデバイスによって事前にカプセル化されたホップバイホップオプションヘッダの別のオプションは、ネクストノードに渡されるようになる。

【0333】

例えば、第３のＳＲｖ６パケットのホップバイホップオプションヘッダには、ＳＦＦのアップストリームネットワークエレメントにより追加された第１のＴＬＶと、ＳＦＦにより追加された第２のＴＬＶとが含まれており、第２のＴＬＶには制御フラグが含まれている。ＳＦＦは第３のＳＲｖ６パケットでは第２のＴＬＶを取り除くが、第１のＴＬＶを取り除くことはない。このため、第４のＳＲｖ６パケットにはホップバイホップオプションヘッダが含まれており、第４のＳＲｖ６パケットのホップバイホップオプションヘッダには第１のＴＬＶが含まれているが、第２のＴＬＶは含まれていない。

【0334】

第３のＳＲｖ６パケットのホップバイホップオプションヘッダがＳＦＦによりカプセル化されている場合、ＳＦＦはホップバイホップオプションヘッダを取り除く。この場合、第４のＳＲｖ６パケットはホップバイホップオプションヘッダを含まない。例えば、図１５を参照されたい。ＳＦＦにより受信され且つＳＦデバイスにより送信されるＳＲｖ６パケットには、ＳＲＨ、ＨＢＨ、およびＩＰｖ４パケットが含まれており、後でＳＦＦにより送信されるＳＲｖ６パケットには、ＳＲＨおよびＩＰｖ４パケットが含まれている。この２つのパケットを比較すると、ＳＦＦにより送信されるＳＲｖ６パケットにはＨＢＨが含まれておらず、このＨＢＨはＳＦＦにより取り除かれている。

【0335】

本実施形態は、ＳＲｖ６サービス機能チェーンを実装する方法を提供する。Ｅｎｄ．ＰＴ．ＳＩＤを提供して用いるのは、ＳＦＦがＳＲＨを取り除くことなくＳＲｖ６パケットをＳＦデバイスに転送するのを識別するためである。Ｅｎｄ．ＰＴ．ＳＩＤに基づいて、ＳＦＦは、ＳＲｖ６パケットのＳＲＨを取り除くのではなく、このＳＲｖ６パケットをＳＦデバイスに送信する。さらに、ＳＦＦが制御フラグをＳＲｖ６パケットに含めることで、制御フラグはＩＰｖ６拡張ヘッダをオフセットする必要があるシナリオを識別するのに用いられるようになる。ＳＦデバイスは、ＳＲｖ６パケットを受信した後に、制御フラグに基づいてＳＲｖ６パケットのＩＰｖ６拡張ヘッダを直接的にオフセットし、ＳＲＨを省略して、ＳＲＨの後に続くペイロードに対してサービス処理を行う。この方法を用いると、ＳＦＦはＳＲｖ６ ＳＦＣプロキシ機能をサポートする必要がない。具体的には、パケット転送プロセスにおいて、ＳＦＦはＳＲＨを取り除いてＳＲＨを復元するという段階を行う必要がないため、ＳＦＦを転送プレーンに実装するのが大幅に簡略化される。さらに、ＳＦＦはｃａｃｈｅの生成または維持を必要としないので、ｓｔａｔｅｌｅｓｓ転送プレーンが実装され得る。ＳＦデバイスでは、ＳＦデバイスはＳＲｖ６およびＥｎｄ．ＡＮ ＳＩＤ機能を実装することなく、ＳＲｖ６のＳＦＣ機能を実装できる。

【0336】

前述の方法２００では、制御フラグを用いて、パケットがそのＩＰｖ６拡張ヘッダをオフセットすべきパケットであることを識別する。本願のいくつかの他の実施形態では、制御フラグ以外の別の方式を用いて、パケットがそのＩＰｖ６拡張ヘッダをオフセットする必要があるパケットであることを識別してよい。例えば、ＳＦデバイスは、パケットがそのＩＰｖ６拡張ヘッダをオフセットすべきパケットであるかどうかを、ローカル設定を用いて識別する。以下では、方法３００および方法４００を例として用い、パケットがそのＩＰｖ６拡張ヘッダをオフセットすべきパケットであるかどうかを、ローカル設定を用いてどのように識別するかについて説明する。

【0337】

いくつかの実施形態では、ＳＦデバイスは、指定されたインバウンドインタフェースを用いて、パケットがそのＩＰｖ６拡張ヘッダをオフセットする必要があるパケットであることを識別する。以下では、説明のための一例として方法３００を用いる。方法２００の段階と同様の方法３００の段階については、方法２００を参照するものと理解されたい。方法３００では、詳細について再度説明しない。

【0338】

図１８を参照されたい。図１８は、本願の一実施形態による、ＳＲｖ６サービス機能チェーンでパケットを転送する方法３００のフローチャートである。例えば、方法３００にはＳ３００～Ｓ３０９が含まれている。

【0339】

Ｓ３００：ＳＦＦにＥｎｄ．ＰＴ．ＳＩＤを設定する。

【0340】

Ｓ３０１では、Ｅｎｄ．ＰＴ．ＳＩＤは、ＳＲＨを取り除くことなく、受信したＳＲｖ６パケットをＳＦデバイスに転送するようＳＦＦに指示するのに用いられる。任意選択で、Ｅｎｄ．ＰＴ．ＳＩＤはさらに、受信したＳＲｖ６パケットを指定されたインタフェース（すなわち、以下の第２のインタフェース）を通じて転送するようＳＦＦに指示するのに用いられる。

【0341】

Ｓ３０１：第１のインタフェースを通じて受信したパケットのＩＰｖ６拡張ヘッダをオフセットして、ＩＰｖ６拡張ヘッダの後に続くペイロードに対してサービス処理を行うようにＳＦデバイスを構成する。

【0342】

第１のインタフェースは、ＳＦデバイスの１つまたは複数のインバウンドインタフェースである。

【0343】

Ｓ３０２：ＳＦＦは第１のＳＲｖ６パケットを受信する。第１のＳＲｖ６パケットの宛先アドレスにはＥｎｄ．ＰＴ．ＳＩＤが含まれている。

【0344】

Ｓ３０３：ＳＦＦは、Ｅｎｄ．ＰＴ．ＳＩＤおよび第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成する。第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダにはＳＲＨが含まれており、第２のＳＲｖ６パケットおよび第１のＳＲｖ６パケットは同じペイロードを有している。

【0345】

Ｓ３０４：ＳＦＦは第２のＳＲｖ６パケットをＳＦデバイスの第１のインタフェースに送信する。

【0346】

Ｓ３０５：ＳＦデバイスは第１のインタフェースを通じてＳＦＦから第２のＳＲｖ６パケットを受信する。

【0347】

任意選択で、ＳＦＦは第２のインタフェースを通じて第２のＳＲｖ６パケットを送信する。第２のインタフェースはＳＦＦのアウトバウンドインタフェースである。第２のインタフェースとＥｎｄ．ＰＴ．ＳＩＤとの間に結合関係が事前に確立されている。

【0348】

方法２００と異なり、方法３００では、ＳＦデバイスは、パケットがそのＩＰｖ６拡張ヘッダをオフセットすべきパケットであるかどうかを制御フラグに基づいて識別するのではなく、パケットがそのＩＰｖ６拡張ヘッダをオフセットすべきパケットであるかどうかを、指定されたインタフェースに基づいて識別する。指定されたインタフェースを通じて受信したパケットに対して、ＳＦデバイスは、このパケットがＩＰｖ６拡張ヘッダをオフセットすべきパケットであると判定する。例えば、ＳＦＦの第２のインタフェースは、ＳＦデバイスに接続するのに用いられる専用インタフェースとして予め構成されており、ＳＦＦは、Ａｃｔｉｖｅ ＳＩＤがＥｎｄ．ＰＴであるＳＲｖ６パケットを受信した場合、ＳＲＨを取り除くことなくＳＲｖ６パケットを第２のインタフェースを通じて転送するように構成されている。さらに、ＳＦデバイスの第１のインタフェースは、ＳＦＦに接続される専用インタフェースとして予め構成されており、ＳＦデバイスは、第１のインタフェースを通じて受信したパケットのＩＰｖ６拡張ヘッダをオフセットして、ＩＰｖ６拡張ヘッダの後に続くペイロードに対してサービス処理を行うように構成されている。このように、ＳＦＦが第１のＳＲｖ６パケットを受信した後に、ＳＦＦは、ＳＦＦの構成情報に基づいて第１のＳＲｖ６パケットのＳＲＨを取り除くことはせず、第２のＳＲｖ６パケットを第２のインタフェースを通じてＳＦデバイスに送信する。これにより、第２のＳＲｖ６パケットはＳＦデバイスの第１のインタフェースに到着するようになる。ＳＦデバイスは、第２のＳＲｖ６パケットを受信した後に、第２のＳＲｖ６パケットが第１のインタフェースを通じて受信されたと判定し、ＳＦデバイスの構成情報に基づいて、ＳＦデバイスは、第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダをオフセットして、第２のＳＲｖ６パケットにおいてＩＰｖ６拡張ヘッダの後に続くペイロードに対してサービス処理を行う。

【0349】

任意選択で、第２のＳＲｖ６パケットにはさらに、ターゲット情報が含まれている。ターゲット情報の説明については、方法２００の関連する説明を参照されたい。

【0350】

Ｓ３０６：ローカル設定に基づいて、ＳＦデバイスは、第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダをオフセットし、第２のＳＲｖ６パケットにおいてＩＰｖ６拡張ヘッダの後に続くペイロードに対してサービス処理を行い、第３のＳＲｖ６パケットを取得する。第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じＳＲＨを有している。

【0351】

Ｓ３０７：ＳＦデバイスは第３のＳＲｖ６パケットをＳＦＦに送信する。

【0352】

Ｓ３０８：ＳＦＦはＳＦデバイスから第３のＳＲｖ６パケットを受信する。第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じＳＲＨを有している。

【0353】

Ｓ３０９：ＳＦＦは、第３のＳＲｖ６パケットのＳＲＨに基づいて、第３のＳＲｖ６パケットに対して転送処理を行う。

【0354】

本実施形態は、ＳＲｖ６サービス機能チェーンを実装する方法を提供する。Ｅｎｄ．ＰＴ．ＳＩＤを提供して用いるのは、ＳＦＦがＳＲＨを取り除くことなくＳＲｖ６パケットをＳＦデバイスに転送するのを識別するためである。Ｅｎｄ．ＰＴ．ＳＩＤに基づいて、ＳＦＦは、ＳＲｖ６パケットのＳＲＨを取り除くのではなく、このＳＲｖ６パケットをＳＦデバイスに送信する。さらに、ＳＦデバイスに対して指定されたインバウンドインタフェースが、ＩＰｖ６拡張ヘッダをオフセットする必要があるシナリオを識別するのに用いられる。ＳＦＦは、ＳＦデバイスに対して指定されたインバウンドインタフェースにＳＲｖ６パケットを送信する。ＳＦデバイスは、指定されたインバウンドインタフェースを通じてＳＲｖ６パケットを受信した後に、ＳＲｖ６パケットのＩＰｖ６拡張ヘッダを直接的にオフセットし、ＳＲＨを省略してＳＲＨの後に続くペイロードに対してサービス処理を行う。この方法を用いると、ＳＦＦはＳＲｖ６ ＳＦＣプロキシ機能をサポートする必要がない。具体的には、パケット転送プロセスにおいて、ＳＦＦはＳＲＨを取り除いてＳＲＨを復元するという段階を行う必要がないため、ＳＦＦを転送プレーンに実装するのが大幅に簡略化される。さらに、ＳＦＦはｃａｃｈｅの生成または維持を必要としないので、ｓｔａｔｅｌｅｓｓ転送プレーンが実装され得る。ＳＦデバイスでは、ＳＦデバイスはＳＲｖ６およびＥｎｄ．ＡＮ ＳＩＤ機能を実装することなく、ＳＲｖ６のＳＦＣ機能を実装できる。

【0355】

いくつかの実施形態では、ＳＦデバイスは、アクセス制御リスト（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ、ＡＣＬ）に基づいて、パケットがそのＩＰｖ６拡張ヘッダをオフセットする必要があるパケットであることを識別する。以下では、説明のための一例として方法４００を用いる。方法２００の段階と同様の方法４００の段階については、方法２００を参照するものと理解されたい。方法４００では、詳細について再度説明しない。

【0356】

図１９を参照されたい。図１９は、本願の一実施形態による、ＳＲｖ６サービス機能チェーンでパケットを転送する方法４００のフローチャートである。例えば、方法４００にはＳ４００～Ｓ４１０が含まれている。

【0357】

Ｓ４００：ＳＦＦにＥｎｄ．ＰＴ．ＳＩＤを設定する。

【0358】

Ｓ４０１では、Ｅｎｄ．ＰＴ．ＳＩＤは、ＳＲＨを取り除くことなく、受信したＳＲｖ６パケットをＳＦデバイスに転送するようＳＦＦに指示するのに用いられる。

【0359】

Ｓ４０１：ＡＣＬのマッチング条件を満たしているパケットのＩＰｖ６拡張ヘッダをオフセットして、ＩＰｖ６拡張ヘッダの後に続くペイロードに対してサービス処理を行うようＳＦデバイスを構成する。

【0360】

ＡＣＬには、マッチング条件およびアクションが含まれている。パケットがマッチング条件を満たしている場合、ＳＦデバイスはマッチング条件に対応するアクションを行う。方法３００では、マッチング条件に対応するアクションは、ＩＰｖ６拡張ヘッダをオフセットして、ＩＰｖ６拡張ヘッダの後に続くペイロードに対してサービス処理を行うことである。

【0361】

マッチング条件には以下の条件のうちの少なくとも１つが含まれている。すなわち、パケットの送信元ＩＰアドレスがＡＣＬのＩＰアドレスと一致すること、パケットの宛先ＩＰアドレスがＡＣＬのＩＰアドレスと一致すること、パケットの送信元ポート番号がＡＣＬのポート番号と一致すること、およびパケットの宛先ポート番号がＡＣＬのポート番号と一致することである。ポート番号は、例えば、ＴＣＰポート番号またはＵＤＰポート番号である。

【0362】

Ｓ４０２：ＳＦＦは第１のＳＲｖ６パケットを受信する。第１のＳＲｖ６パケットの宛先アドレスにはＥｎｄ．ＰＴ．ＳＩＤが含まれている。

【0363】

Ｓ４０３：ＳＦＦは、Ｅｎｄ．ＰＴ．ＳＩＤおよび第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成する。第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダにはＳＲＨが含まれており、第２のＳＲｖ６パケットおよび第１のＳＲｖ６パケットは同じペイロードを有している。

【0364】

Ｓ４０４：ＳＦＦは第２のＳＲｖ６パケットをＳＦデバイスに送信する。

【0365】

Ｓ４０５：ＳＦデバイスは第２のＳＲｖ６パケットをＳＦＦから受信する。

【0366】

Ｓ４０６：ＳＦデバイスは、第２のＳＲｖ６パケットがＡＣＬのマッチング条件を満たしていると判定する。

【0367】

ＳＦデバイスは、第２のＳＲｖ６パケットがＡＣＬのマッチング条件を満たしているかどうかを判定する。第２のＳＲｖ６パケットがＡＣＬのマッチング条件を満たしている場合、ＳＦデバイスは以下のＳ４０７を行う。

【0368】

Ｓ４０７：ＳＦデバイスは、第２のＳＲｖ６パケットのＩＰｖ６拡張ヘッダをオフセットし、第２のＳＲｖ６パケットにおいてＩＰｖ６拡張ヘッダの後に続くペイロードに対してサービス処理を行い、第３のＳＲｖ６パケットを取得する。第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じＳＲＨを有している。

【0369】

任意選択で、第２のＳＲｖ６パケットにはさらに、ターゲット情報が含まれている。ターゲット情報の説明については、方法２００の関連する説明を参照されたい。

【0370】

Ｓ４０８：ＳＦデバイスは第３のＳＲｖ６パケットをＳＦＦに送信する。

【0371】

Ｓ４０９：ＳＦＦはＳＦデバイスから第３のＳＲｖ６パケットを受信する。第３のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは同じＳＲＨを有している。

【0372】

Ｓ４１０：ＳＦＦは、第３のＳＲｖ６パケットのＳＲＨに基づいて、第３のＳＲｖ６パケットに対して転送処理を行う。

【0373】

本実施形態は、ＳＲｖ６サービス機能チェーンを実装する方法を提供する。Ｅｎｄ．ＰＴ．ＳＩＤを提供して用いるのは、ＳＦＦがＳＲＨを取り除くことなくＳＲｖ６パケットをＳＦデバイスに転送するのを識別するためである。Ｅｎｄ．ＰＴ．ＳＩＤに基づいて、ＳＦＦは、ＳＲｖ６パケットのＳＲＨを取り除くのではなく、このＳＲｖ６パケットをＳＦデバイスに送信する。さらに、ＳＦデバイスに設定されるＡＣＬは、ＩＰｖ６拡張ヘッダをオフセットする必要があるシナリオを識別するのに用いられる。ＳＦデバイスがＳＲｖ６パケットを受信した後に、ＳＲｖ６パケットがＡＣＬのマッチング条件を満たしているとＳＦデバイスが判定した場合、ＳＦデバイスは、ＳＲｖ６パケットのＩＰｖ６拡張ヘッダを直接的にオフセットし、ＳＲＨを省略してサービス処理を行う。この方法を用いると、ＳＦＦはＳＲｖ６のＳＦＣプロキシ機能をサポートする必要がない。具体的には、パケット転送プロセスにおいて、ＳＦＦはＳＲＨを取り除いてＳＲＨを復元するという段階を行う必要がないため、ＳＦＦを転送プレーンに実装するのが大幅に簡略化される。さらに、ＳＦＦはｃａｃｈｅの生成または維持を必要としないので、ｓｔａｔｅｌｅｓｓ転送プレーンが実装され得る。ＳＦデバイスでは、ＳＦデバイスはＳＲｖ６およびＥｎｄ．ＡＮ ＳＩＤ機能を実装することなく、ＳＲｖ６のＳＦＣ機能を実装できる。

【0374】

方法２００、方法３００、および方法４００では、ＳＦデバイスがＳＦＦに第３のＳＲｖ６パケットを戻す段階は任意選択であることを理解されたい。いくつかの他の実施形態では、ＳＦデバイスは、ＳＦＦから第２のＳＲｖ６パケットを受信した後に、ＳＦＦに第３のＳＲｖ６パケットを戻すことはしない。例えば、ＳＦデバイスはネットワークセキュリティデバイス、例えば、ファイアウォールであり、ＳＦデバイスにより行われるサービス処理アクションとは、パケットを破棄することである。したがって、ＳＦデバイスは、第２のＳＲｖ６パケットがパケット破棄条件を満たしていると判定した場合、第２のＳＲｖ６パケットを破棄する。

【0375】

以上では、本願の実施形態における方法２００、方法３００、および方法４００を説明している。以下では、本願の実施形態におけるＳＦＦおよびＳＦデバイスについて説明する。後述するＳＦＦは、方法２００、方法３００、および方法４００におけるＳＦＦのいずれかの機能を有していることを理解されたい。後述するＳＦデバイスは、方法２００、方法３００、および方法４００におけるＳＦデバイスのいずれかの機能を有している。

【0376】

図２０は、本願の一実施形態によるＳＦＦの構造概略図である。図２０に示すように、ＳＦＦ５００には、Ｓ２０２、Ｓ３０２、またはＳ４０２を行うように構成された受信モジュール５０１と、Ｓ２０３、Ｓ３０３、またはＳ４０４を行うように構成された生成モジュール５０２と、Ｓ２０４、Ｓ３０４、またはＳ４０４を行うように構成された送信モジュール５０３とが含まれている。

【0377】

ＳＦＦ５００は前述した方法の実施形態におけるＳＦＦに対応しており、ＳＦＦ５００における各モジュールならびに前述した他のオペレーションおよび／または機能はそれぞれ、方法２００、方法３００、および方法４００におけるＳＦＦにより行われる様々な段階および方法を実現するのに用いられることを理解されたい。具体的な詳細については、方法２００、方法３００、および方法４００を参照されたい。簡潔にするために、詳細については再度ここで説明しない。

【0378】

前述の機能モジュールの分割は、ＳＦＦ５００がＳＲｖ６サービス機能チェーンでパケットをどのように転送するかを説明するための一例として用いられていることを理解されたい。実際に適用する際には、必要に応じて前述の機能を異なる機能モジュールに割り当ててもよい。言い換えれば、ＳＦＦ５００の内部構造は、上述した機能の全部または一部を実装するために様々な機能モジュールに分割される。さらに、前述の実施形態において提供されたＳＦＦ５００は、方法２００、方法３００、および方法４００と同じ考えに属している。具体的な実装プロセスについては、方法２００、方法３００、および方法４００を参照されたい。詳細については、再度ここで説明しない。

【0379】

図２１は、本願の一実施形態によるＳＦデバイスの構造概略図である。図２１に示すように、ＳＦデバイス６００には、Ｓ２０５、Ｓ３０５、またはＳ４０５を行うように構成された受信モジュール６０１と、Ｓ２０６、Ｓ３０６、Ｓ４０６、またはＳ４０７を行うように構成された処理モジュール６０２とが含まれている。

【0380】

任意選択で、ＳＦデバイス６００はさらに送信モジュールを含み、送信モジュールはＳ２０７、Ｓ３０７、またはＳ４０８を行うように構成されている。

【0381】

ＳＦデバイス６００は前述した方法の実施形態におけるＳＦデバイスに対応しており、ＳＦデバイス６００における各モジュールならびに前述した他のオペレーションおよび／または機能はそれぞれ、方法２００、方法３００、および方法４００におけるＳＦデバイスにより行われる様々な段階および方法を実現するのに用いられることを理解されたい。具体的な詳細については、方法２００、方法３００、および方法４００を参照されたい。簡潔にするために、詳細については再度ここで説明しない。

【0382】

前述の機能モジュールの分割は、ＳＦデバイス６００がＳＲｖ６サービス機能チェーンでパケットをどのように転送するかを説明するための一例として用いられていることを理解されたい。実際に適用する際には、必要に応じて前述の機能を異なる機能モジュールに割り当ててもよい。言い換えれば、ＳＦデバイス６００の内部構造は、上述した機能の全部または一部を実装するために様々な機能モジュールに分割される。さらに、前述の実施形態において提供されたＳＦデバイス６００は、方法２００、方法３００、および方法４００と同じ考えに属している。具体的な実装プロセスについては、方法２００、方法３００、および方法４００を参照されたい。詳細については、再度ここで説明しない。

【0383】

本願において提供された方法の実施形態および仮想装置の実施形態に対応して、本願の本実施形態はさらに、ＳＦＦおよびＳＦデバイスを提供する。以下では、ＳＦＦおよびＳＦデバイスのハードウェア構造について説明する。

【0384】

後述するＳＦＦ７００およびＳＦデバイス８００はそれぞれ、方法２００、方法３００、および方法４００におけるＳＦＦおよびＳＦデバイスに対応する。ＳＦＦ７００およびＳＦデバイス８００におけるハードウェア、モジュール、ならびに前述した他のオペレーションおよび／または機能がそれぞれ、方法の実施形態におけるＳＦＦおよびＳＦデバイスにより行われる様々な段階および方法を実現するのに用いられる。ＳＦＦ７００およびＳＦデバイス８００がＳＲｖ６サービス機能チェーンでパケットをどのように転送するかという詳細なプロセスに関して、具体的な詳細については、方法２００、方法３００、および方法４００を参照されたい。簡潔にするために、詳細については再度ここで説明しない。方法２００、方法３００、および方法４００の各段階は、ハードウェアの集積ロジック回路またはＳＦＦ７００およびＳＦデバイス８００のプロセッサにおいてソフトウェアの形態にある命令を用いて完了する。本願の実施形態に関連して開示された方法の各段階は、ハードウェアプロセッサにより直接的に行われてもよく、プロセッサのハードウェアとソフトウェアモジュールとの組み合わせを用いて行われてもよい。ソフトウェアモジュールは、当該技術分野において成熟した記憶媒体、例えば、ランダムアクセスメモリ、フラッシュメモリ、読み出し専用メモリ、プログラム可能型読み出し専用メモリ、電気的消去可能プログラム可能型メモリ、またはレジスタなどに配置されてよい。記憶媒体はメモリに配置されており、プロセッサは、メモリにある情報を読み出し、プロセッサのハードウェアと組み合わせて前述した方法における各段階を完了させる。繰り返しを避けるために、詳細については再度ここで説明しない。

【0385】

ＳＦＦ７００は、図２０に示すＳＦＦ５００に対応する。ＳＦＦ５００の機能モジュールが、ＳＦＦ７００のソフトウェアを用いて実装されている。言い換えれば、ＳＦＦ５００に含まれている機能モジュールは、ＳＦＦ７００のプロセッサがメモリに格納されたプログラムコードを読み出した後に生成される。

【0386】

ＳＦデバイス８００は、図２１に示すＳＦデバイス６００に対応する。ＳＦデバイス６００の機能モジュールが、ＳＦデバイス８００のソフトウェアを用いて実装される。言い換えれば、ＳＦデバイス６００に含まれている機能モジュールは、ＳＦデバイス８００のプロセッサがメモリに格納されたプログラムコードを読み出した後に生成される。

【0387】

図２２を参照されたい。図２２は、本願の例示的実施形態によるＳＦＦの構造概略図である。ＳＦＦ７００は、例えば、ネットワークデバイスである。ＳＦＦ７００には、メイン制御ボード７１０およびインタフェースボード７３０が含まれている。

【0388】

メイン制御ボードは、メイン処理ユニット（ｍａｉｎ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＭＰＵ）またはルートプロセッサカード（ｒｏｕｔｅ ｐｒｏｃｅｓｓｏｒ ｃａｒｄ）とも呼ばれている。メイン制御ボード７１０は、ルート計算、デバイス管理、デバイス保守、およびプロトコル処理の機能を含むＳＦＦ７００の各コンポーネントの制御および管理を行うように構成されている。メイン制御ボード７１０には、中央演算処理装置７１１およびメモリ７１２が含まれている。

【0389】

インタフェースボード７３０は、ラインインタフェースユニット（ｌｉｎｅ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＬＰＵ）、ラインカード（ｌｉｎｅ ｃａｒｄ）、またはサービスボードとも呼ばれている。インタフェースボード７３０は、様々なサービスインタフェースを提供して、データパケット転送を実現するように構成されている。サービスインタフェースとしては、限定されることはないが、イーサネットインタフェースおよびＰＯＳ（Ｐａｃｋｅｔ ｏｖｅｒ ＳＯＮＥＴ／ＳＤＨ）インタフェースなどが挙げられる。イーサネットインタフェースは、例えば、フレキシブルイーサネットサービスインタフェース（Ｆｌｅｘｉｂｌｅ Ｅｔｈｅｒｎｅｔ Ｃｌｉｅｎｔ、ＦｌｅｘＥ Ｃｌｉｅｎｔ）である。インタフェースボード７３０には、中央演算処理装置７３１、ネットワークプロセッサ７３２、転送エントリメモリ７３４、および物理インタフェース（ｐｈｙｓｉｃａｌ ｉｎｔｅｒｆａｃｅ ｃａｒｄ、ＰＩＣ）７３３が含まれている。

【0390】

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

【0391】

ネットワークプロセッサ７３２は、パケット転送処理を実現するように構成されている。ネットワークプロセッサ７３２の形態が転送チップであってよい。具体的には、ネットワークプロセッサ７３２は、転送エントリメモリ７３４に格納された転送テーブルに基づいて、受信したパケットを転送するように構成されている。パケットの宛先アドレスがＳＦＦ７００のアドレスである場合、ネットワークプロセッサ７３２はパケットを処理のためにＣＰＵ（例えば、中央演算処理装置７１１）に送信する。パケットの宛先アドレスがＳＦＦ７００のアドレスではない場合、ネットワークプロセッサ７３２は、宛先アドレスに基づいて宛先アドレスに対応するネクストホップおよびアウトバウンドインタフェースを求めて転送テーブルを検索し、宛先アドレスに対応するアウトバウンドインタフェースにパケットを転送する。アップリンクパケットの処理としては、パケットのインバウンドインタフェースを処理すること、および転送テーブルを検索することが挙げられる。ダウンリンクパケットの処理としては、転送テーブルを検索することなどが挙げられる。

【0392】

物理インタフェース７３３は、物理層相互接続機能を実装するように構成されている。元のトラフィックが物理インタフェース７３３からインタフェースボード７３０に入り、処理されたパケットが物理インタフェース７３３から送信される。物理インタフェース７３３は、サブカードとも呼ばれており、インタフェースボード７３０に搭載されてよく、光／電気信号をパケットに変換し、パケットに対して有効性チェックを行い、次いでパケットを処理のためにネットワークプロセッサ７３２に転送する役割がある。いくつかの実施形態では、中央演算処理装置はネットワークプロセッサ７３２の機能も行うことができ、例えば、汎用ＣＰＵに基づくソフトウェア転送を実装できる。したがって、ネットワークプロセッサ７３２は、物理インタフェース７３３において必要とされない。

【0393】

任意選択で、ＳＦＦ７００には複数のインタフェースボードが含まれている。例えば、ＳＦＦ７００にはさらにインタフェースボード７４０が含まれている。インタフェースボード７４０には、中央演算処理装置７４１、ネットワークプロセッサ７４２、転送エントリメモリ７４４、および物理インタフェース７４３が含まれている。

【0394】

任意選択で、ＳＦＦ７００にはさらにスイッチングボード７２０が含まれている。スイッチングボード７２０は、スイッチファブリックユニット（ｓｗｉｔｃｈ ｆａｂｒｉｃ ｕｎｉｔ、ＳＦＵ）とも呼ばれることがある。ネットワークデバイスが複数のインタフェースボード７３０を有している場合、スイッチングボード７２０は、インタフェースボード同士のデータ交換を完了させるように構成されている。例えば、インタフェースボード７３０およびインタフェースボード７４０は、スイッチングボード７２０を用いて互いに通信することができる。

【0395】

メイン制御ボード７１０はインタフェースボード７３０に結合されている。例えば、メイン制御ボード７１０、インタフェースボード７３０、インタフェースボード７４０、およびスイッチングボード７２０は、システムバスを通じてシステムバックプレーンに接続されて、インターワーキングを実現する。実現可能な一実装形態では、メイン制御ボード７１０とインタフェースボード７３０との間に、プロセス間通信プロトコル（ｉｎｔｅｒ－ｐｒｏｃｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎ、ＩＰＣ）チャネルが確立されており、メイン制御ボード７１０とインタフェースボード７３０との間でＩＰＣを用いて通信が行われる。

【0396】

論理的に、ＳＦＦ７００には制御プレーンおよび転送プレーンが含まれている。制御プレーンには、メイン制御ボード７１０および中央演算処理装置７３１が含まれている。転送プレーンには、転送を行う様々なコンポーネント、例えば、転送エントリメモリ７３４、物理インタフェース７３３、およびネットワークプロセッサ７３２が含まれている。制御プレーンは、ルーティング、転送テーブルの生成、シグナリングおよびプロトコルパケットの処理、ならびにデバイス状態の設定および維持などの機能を行う。制御プレーンは、生成された転送テーブルを転送プレーンに伝える。転送プレーンにおいて、ネットワークプロセッサ７３２は、制御プレーンから伝えられた転送テーブルを検索して、物理インタフェース７３３で受信したパケットを転送する。制御プレーンから伝えられた転送テーブルは、転送エントリメモリ７３４に格納されてよい。いくつかの実施形態では、制御プレーンおよび転送プレーンは完全に分離されてよく、同じデバイス上にはない。

【0397】

例えば、方法２００、方法３００、または方法４００は、インタフェースボード７３０で行われる。物理インタフェース７３３は第１のＳＲｖ６パケットを受信し、第１のＳＲｖ６パケットをネットワークプロセッサ７３２に送信する。ネットワークプロセッサ７３２は、Ｅｎｄ．ＰＴ．ＳＩＤおよび第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成し、リンク層のカプセル化を完了させた後にアウトバウンドインタフェースなどの情報に基づいて、物理インタフェース７３３を通じて第２のパケットを送信する。これにより、第２のパケットはＳＦデバイスに伝送されるようになる。方法２００、方法３００、または方法４００をインタフェースボード７４０で実行するプロセスも同様である。

【0398】

ＳＦＦ５００の受信モジュール５０１および送信モジュール５０３はＳＦＦ７００の物理インタフェース７３３に相当し、ＳＦＦ５００の生成モジュール５０２はネットワークプロセッサ７３２または中央演算処理装置７１１に相当し得ることを理解されたい。

【0399】

本願の本実施形態では、インタフェースボード７４０でのオペレーションがインタフェースボード７３０でのオペレーションと一致していることを理解されたい。簡潔にするために、詳細については再度説明しない。本実施形態におけるＳＦＦ７００は、前述した方法の実施形態におけるＳＦＦに対応し得ることを理解されたい。ＳＦＦ７００のメイン制御ボード７１０ならびにインタフェースボード７３０および／または７４０は、ＳＦＦの諸機能および／または前述した方法の実施形態におけるＳＦＦにより行われる様々な段階を実現し得る。簡潔にするために、詳細については再度ここで説明しない。

【0400】

１つまたは複数のメイン制御ボードがあり得ることに留意されたい。複数のメイン制御ボードがある場合、メイン制御ボードには、アクティブメイン制御ボードおよびスタンバイメイン制御ボードが含まれてよい。１つまたは複数のインタフェースボードがあってよく、より大きいデータ処理能力を有するネットワークデバイスによって、より多くのインタフェースボードが提供される。インタフェースボードには、１つまたは複数の物理インタフェースがあってよい。スイッチングボードがなくてもよく、１つまたは複数のスイッチングボードがあってもよい。複数のスイッチングボードがある場合、負荷共有および冗長バックアップが一緒に実装されてよい。集中型転送アーキテクチャでは、ネットワークデバイスはスイッチングボードを必要としないことがあり、インタフェースボードによって、システム全体のサービスデータを処理する機能が提供される。分散型転送アーキテクチャでは、ネットワークデバイスは少なくとも１つのスイッチングボードを有してよく、複数のインタフェースボード間のデータ交換が、スイッチングボードを使用して実現され、大容量のデータ交換および処理能力が提供される。したがって、分散型アーキテクチャにおけるネットワークデバイスのデータアクセスおよび処理能力は、集中型アーキテクチャにおけるデバイスより良い。任意選択で、ネットワークデバイスは代替的に、カードが１つしかない形態であってもよい。具体的には、スイッチングボードがなく、インタフェースボードおよびメイン制御ボードの機能はこのカードに統合される。この場合、インタフェースボード上の中央演算処理装置およびメイン制御ボード上の中央演算処理装置は、カード上の１つの中央演算処理装置に組み合わされて、２つの中央演算処理装置が組み合わされた後に取得される機能を行ってよい。この形態のデバイス（例えば、低性能のスイッチまたはルータなどのネットワークデバイス）は、比較的不十分なデータ交換および処理能力しか有していない。用いられる具体的なアーキテクチャは、具体的なネットワーキング展開シナリオに依存する。これについては、ここで限定しない。

【0401】

図２３を参照されたい。図２３は、本願の例示的実施形態によるＳＦデバイス８００の構造概略図である。例えば、ＳＦデバイス８００はコンピューティングデバイス、例えば、ホスト、サーバ、またはパーソナルコンピュータであってよい。ＳＦデバイス８００は、汎用バスアーキテクチャで実装されてよい。

【0402】

ＳＦデバイス８００は、方法の実施形態において説明された内容の全部または一部に関わる任意のデバイス、例えば８８８８であってよい。ＳＦデバイス８００には、少なくとも１つのプロセッサ８０１、通信バス８０２、メモリ８０３、および少なくとも１つの物理インタフェース８０４が含まれている。

【0403】

プロセッサ８０１は、汎用の中央演算処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ、ＣＰＵ）、ネットワークプロセッサ（ｎｅｔｗｏｒｋ ｐｒｏｃｅｓｓｏｒ、ＮＰ）、またはマイクロプロセッサであってもよく、本願の解決手段を実現するように構成された１つまたは複数の集積回路、例えば、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ、ＡＳＩＣ）、プログラム可能型ロジックデバイス（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＰＬＤ）、またはその組み合わせであってもよい。ＰＬＤは、複雑なプログラム可能型ロジックデバイス（ｃｏｍｐｌｅｘ ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅ、ＣＰＬＤ）、フィールドプログラマブルロジックゲートアレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ、ＦＰＧＡ）、汎用アレイロジック（ｇｅｎｅｒｉｃ ａｒｒａｙ ｌｏｇｉｃ、ＧＡＬ）、またはその任意の組み合わせであってもよい。

【0404】

通信バス８０２は、前述のコンポーネント間で情報を伝送するのに用いられる。通信バス８０２は、アドレスバス、データバス、または制御バスなどに分類されてよい。表現しやすくするために、図２３では１本の太線だけを用いてバスを表しているが、これは、バスが１つしかない、またはバスのタイプが１つしかないことを意味するものではない。

【0405】

メモリ８０３は、読み出し専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）または静的情報および命令を格納できる別のタイプの静的ストレージデバイスであってもよく、ランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）または情報および命令を格納できる別のタイプの動的ストレージデバイスであってもよく、電気的消去可能プログラム可能型読み出し専用メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ Ｍｅｍｏｒｙ、ＥＥＰＲＯＭ）、コンパクトディスク読み出し専用メモリ（ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＣＤ－ＲＯＭ）もしくは他のコンパクトディスクストレージ、光ディスクストレージ（圧縮光ディスク、レーザディスク、光ディスク、デジタル多用途光ディスク、またはブルーレイ光ディスクなどを含む）、磁気ディスク記憶媒体もしくは別の磁気ストレージデバイス、または期待されるプログラムコードを命令もしくはデータ構造体の形態で搬送もしくは格納でき且つコンピュータがアクセスできる任意の他の媒体であってもよい。これについては、上記に限定されるものではない。メモリ８０３は独立して存在してよく、通信バス８０２を通じてプロセッサ８０１に接続されている。あるいは、メモリ８０３はプロセッサ８０１と統合されてもよい。

【0406】

物理インタフェース８０４は、別のデバイスまたは通信ネットワークと通信する送受信機のような任意のデバイスを用いる。物理インタフェース８０４には、有線による物理インタフェースが含まれ、代替的に無線による物理インタフェースが含まれてよい。有線による物理インタフェースは、例えば、イーサネットインタフェースであってよい。イーサネットインタフェースは、光インタフェース、電気的インタフェース、またはその組み合わせであってもよい。無線による物理インタフェースは、無線ローカルエリアネットワーク（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ、ＷＬＡＮ）インタフェース、セルラネットワーク物理インタフェース、またはその組み合わせであってもよい。

【0407】

具体的な実装の際に、一実施形態では、プロセッサ８０１には、１つまたは複数のＣＰＵ、例えば、図２３に示すＣＰＵ０およびＣＰＵ１が含まれてよい。

【0408】

具体的な実装の際に、一実施形態では、ＳＦデバイス８００には複数のプロセッサ、例えば、図２３に示すプロセッサ８０１およびプロセッサ８０５が含まれてよい。各プロセッサはシングルコア（ｓｉｎｇｌｅ－ＣＰＵ）プロセッサであってもよく、マルチコア（ｍｕｌｔｉ－ＣＰＵ）プロセッサであってもよい。ここでのプロセッサは、データ（コンピュータプログラム命令など）を処理するように構成された１つまたは複数のデバイス、回路、および／または処理コアを指し得る。

【0409】

具体的な実装の際に、一実施形態では、ＳＦデバイス８００には出力デバイス８０６および入力デバイス８０７が含まれてよい。出力デバイス８０６はプロセッサ８０１と通信し、複数の方式で情報を表示できる。例えば、出力デバイス８０６は、液晶ディスプレイ（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ、ＬＣＤ）、発光ダイオード（ｌｉｇｈｔ－ｅｍｉｔｔｉｎｇ ｄｉｏｄｅ、ＬＥＤ）ディスプレイデバイス、陰極線管（ｃａｔｈｏｄｅ ｒａｙ ｔｕｂｅ、ＣＲＴ）ディスプレイデバイス、またはプロジェクタ（ｐｒｏｊｅｃｔｏｒ）などであってもよい。入力デバイス８０７はプロセッサ８０１と通信し、複数の方式でユーザの入力を受信できる。例えば、入力デバイス８０７は、マウス、キーボード、タッチスクリーンデバイス、またはセンサデバイスなどであってよい。

【0410】

いくつかの実施形態では、メモリ８０３は、本願の解決手段を実行するためのプログラムコード８１０を格納するように構成されており、プロセッサ８０１はメモリ８０３に格納されたプログラムコード８１０を実行できる。言い換えれば、ＳＦデバイス８００は、プロセッサ８０１とメモリ８０３にあるプログラムコード８１０とを用いて、方法の実施形態において提供された方法２００、方法３００、または方法４００を実現できる。

【0411】

本願の本実施形態におけるＳＦデバイス８００は、前述した方法の実施形態におけるＳＦデバイスに対応し得ることを理解されたい。ＳＦデバイス８００のプロセッサ８０１および物理インタフェース８０４などにより、ＳＦデバイスの諸機能および／または前述した方法の実施形態においてＳＦデバイスにより行われる様々な段階および方法が実現され得る。簡潔にするために、詳細についてはここで説明しない。

【0412】

ＳＦデバイス６００の受信モジュール６０１および送信モジュールはＳＦデバイス８００の物理インタフェース８０４に相当し、ＳＦデバイス６００の処理モジュール６０２はＳＦデバイス８００のプロセッサ８０１に相当し得ることを理解されたい。

【0413】

図２４を参照されたい。本願の一実施形態がネットワークシステム９００を提供する。システム９００には、ＳＦＦ９０１およびＳＦデバイス９０２が含まれている。任意選択で、ＳＦＦ９０１はＳＦＦ５００またはＳＦＦ７００であり、ＳＦデバイス９０２はＳＦデバイス６００またはＳＦデバイス８００である。

【0414】

当業者であれば、本明細書に開示された実施形態を参照して説明されている方法の段階およびユニットは、電子的ハードウェア、コンピュータソフトウェア、またはその組み合わせによって実現され得ることを認識しているであろう。ハードウェアとソフトウェアとの間の互換性を明確に説明するために、以上では、各実施形態の段階および構成を機能に基づいて大まかに説明した。これらの機能がハードウェアまたはソフトウェアのいずれで行われるかは、技術的解決手段の具体的な用途および設計上の制約で決まる。当業者であれば、異なる方法を用いて、説明された機能を具体的な用途ごとに実現するかもしれないが、その実装形態が本願の範囲を超えるものとみなされるべきではない。

【0415】

当業者であれば、簡便且つ簡潔な説明のために、前述のシステム、装置、およびモジュールの詳細な動作プロセスについては、前述した方法の実施形態における対応する処理を参照することを明確に理解するであろう。詳細については、再度ここで説明しない。

【0416】

本願で提供されているいくつかの実施形態では、開示されたシステム、装置、および方法が他の方式で実現され得ることを理解されたい。例えば、説明された装置の実施形態は単なる一例にすぎない。例えば、モジュール分割は単なる論理的な機能分割にすぎず、実際の実装では他の分割であってもよい。例えば、複数のモジュールまたはコンポーネントが組み合わされるか、または統合されて別のシステムになってもよく、一部の機能が無視されても、行われなくてもよい。さらに、表示されたり説明されたりした相互結合または直接的結合または通信接続は、いくつかのインタフェース、装置同士もしくはモジュール同士の間接的結合もしくは通信接続、または電気的接続、機械的接続、もしくは他の形態の接続を用いて実現されてよい。

【0417】

別個の部分として説明されているモジュールは、物理的に分かれていてもいなくてもよく、モジュールとして表示されている部分が、物理モジュールであってもなくてもよく、同じ位置に配置されてもよく、複数のネットワークモジュールに分散されてもよい。本願の実施形態の解決手段が持つ目的を達成するために、これらのモジュールの一部または全部が実際の必要性に従って選択されてよい。

【0418】

さらに、本願の実施形態における各機能モジュールが１つの処理モジュールに統合されてもよく、これらのモジュールのそれぞれが物理的に単独で存在してもよく、２つまたはそれより多くのモジュールが１つのモジュールに統合されてもよい。統合されたモジュールは、ハードウェアの形態で実現されてもよく、ソフトウェア機能モジュールの形態で実現されてもよい。

【0419】

統合されたモジュールがソフトウェア機能モジュールの形態で実現されて、独立した製品として販売または使用される場合、統合されたモジュールはコンピュータ可読記憶媒体に格納されてよい。そのような理解に基づいて、本願における技術的解決手段は本質的になるが、従来技術に寄与する部分、またはその技術的解決手段の全部もしくは一部も、ソフトウェア製品の形態で実現されてよい。コンピュータソフトウェア製品は記憶媒体に格納されており、本願の実施形態において説明された方法の段階の全部または一部を行うようコンピュータデバイス（これはパーソナルコンピュータ、サーバ、またはネットワークデバイスなどであってよい）に指示するための命令をいくつか含んでいる。前述の記憶媒体としては、プログラムコードを格納できる任意の媒体、例えば、ＵＳＢフラッシュドライブ、着脱式ハードディスク、読み出し専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＲＯＭ）、ランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ、ＲＡＭ）、磁気ディスク、または光ディスクなどが挙げられる。

【0420】

本願では、「第１」および「第２」などの用語を用いて、基本的に同じ目的または機能を有する同じ項目同士または類似した項目同士を区別している。「第１」と「第２」との間には論理的依存性も時系列的依存性もなく、数および実行順序が限定されることはないものと理解されたい。以下の説明では様々な要素を説明するために「第１」および「第２」などの用語が用いられているが、こうした用語によって、これらの要素が限定されるべきではないことも理解されたい。これらの用語は単に、ある要素を別の要素と区別するのに用いられている。例えば、様々な例の範囲から逸脱することなく、第１のＳＲｖ６パケットが第２のＳＲｖ６パケットと呼ばれてもよく、同様に第２のＳＲｖ６パケットが第１のＳＲｖ６パケットと呼ばれてもよい。第１のＳＲｖ６パケットおよび第２のＳＲｖ６パケットは両方ともＳＲｖ６パケットであってもよく、いくつかのケースでは別々の異なるＳＲｖ６パケットであってもよい。

【0421】

本願では、「少なくとも１つ」という用語は、１つまたは複数を意味する。

【0422】

「～の場合（ｉｆ）」という用語は、「～のとき」（「ｗｈｅｎ」または「ｕｐｏｎ」）、「～の判定に応答して」、または「～の検出に応答して」という意味として解釈されてよいことをさらに理解されたい。同様に、文脈に従って、「～と判定された場合」または「（定められた条件またはイベント）が検出された場合」という表現は、「～と判定されたとき」「～の判定に応答して」、「（定められた条件またはイベント）が検出されたとき」、または「（定められた条件またはイベント）の検出に応答して」という意味に解釈されてよい。

【0423】

前述の説明は単なる本願の特定の実施形態にすぎず、本願の保護範囲を限定することを意図するものではない。本願において開示された技術的範囲内で当業者が容易に考え出すあらゆる均等な修正または置換は、本願の保護範囲に含まれるものとする。したがって、本願の保護範囲は特許請求の範囲の保護範囲に従うものとする。

【0424】

前述の実施形態の全部または一部は、ソフトウェア、ハードウェア、ファームウェア、またはその任意の組み合わせを用いることにより実現されてよい。ソフトウェアを用いて実現する場合、実施形態の全部または一部がコンピュータプログラム製品の形態で実現されてよい。コンピュータプログラム製品には、１つまたは複数のコンピュータプログラム命令が含まれている。このコンピュータプログラム命令がコンピュータにロードされて、ここで実行される場合、本願の実施形態による手順または機能は、全てまたは部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラム可能型装置であってもよい。コンピュータ命令は、コンピュータ可読記憶媒体に格納されてもよく、あるコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に伝送されてもよい。例えば、コンピュータプログラム命令は、有線方式または無線方式で、あるウェブサイト、コンピュータ、サーバ、またはデータセンタから、別のウェブサイト、コンピュータ、サーバ、またはデータセンタへ伝送されてよい。コンピュータ可読記憶媒体は、コンピュータがアクセス可能な任意の使用可能な媒体であっても、１つまたは複数の使用可能な媒体を統合した、サーバまたはデータセンタなどのデータストレージデバイスであってもよい。使用可能な媒体は、磁気媒体（例えば、フロッピディスク、ハードディスク、または磁気テープ）、光媒体（例えば、デジタルビデオディスク（ｄｉｇｉｔａｌ ｖｉｄｅｏ ｄｉｓｃ、ＤＶＤ））、または半導体媒体（例えば、ソリッドステートドライブ）などであってもよい。

【0425】

当業者であれば、実施形態の段階の全部または一部が、ハードウェア、または関連するハードウェアに指示を与えるプログラムにより実現され得ることを理解するであろう。プログラムは、コンピュータ可読記憶媒体に格納されてよい。記憶媒体には、読み出し専用メモリ、磁気ディスク、または光ディスクが含まれてよい。

【0426】

前述の説明は、単なる本願の任意選択の実施形態にすぎず、本願を限定することを意図するものではない。本願の趣旨および原理から逸脱することなく行われるあらゆる修正、均等な置換、または改良は、本願の保護範囲に含まれるはずである。
［他の可能な項目］
［項目１］
ＳＲｖ６サービス機能チェーンでパケットを転送する方法であって、前記方法が、
サービス機能転送器ＳＦＦが第１のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットを受信する段階であって、前記第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ Ｅｎｄ．ＰＴ．ＳＩＤが含まれており、前記Ｅｎｄ．ＰＴ．ＳＩＤが、セグメントルーティングヘッダＳＲＨを取り除くことなく前記第１のＳＲｖ６パケットをサービス機能ＳＦデバイスに転送するよう前記ＳＦＦに指示するのに用いられる、受信する段階と、
前記ＳＦＦが前記Ｅｎｄ．ＰＴ．ＳＩＤおよび前記第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成する段階であって、前記第２のＳＲｖ６パケットには制御フラグが含まれており、前記制御フラグが、前記第２のＳＲｖ６パケットにおいて前記制御フラグの後に続くインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはＳＲＨが含まれている、生成する段階と、
前記ＳＦＦが前記第２のＳＲｖ６パケットを前記ＳＦデバイスに送信する段階と
を備えている、方法。
［項目２］
前記制御フラグがさらに、前記ＳＦＦにパケットを戻すプロセスにおいて、前記ＩＰｖ６拡張ヘッダを戻すよう前記ＳＦデバイスに指示するのに用いられ、前記ＳＦＦが前記第２のＳＲｖ６パケットを前記ＳＦデバイスに送信する前記段階の後に、前記方法がさらに、
前記ＳＦＦが前記ＳＦデバイスから第３のＳＲｖ６パケットを受信する段階であって、前記第３のＳＲｖ６パケットには前記ＩＰｖ６拡張ヘッダが含まれており、前記第３のＳＲｖ６パケットおよび前記第２のＳＲｖ６パケットが同じＳＲＨを有している、受信する段階と、
前記ＳＦＦが前記第３のＳＲｖ６パケットの前記ＳＲＨに基づいて前記第３のＳＲｖ６パケットに対して転送処理を行う段階と
を備えている、項目１に記載の方法。
［項目３］
前記第２のＳＲｖ６パケットにはホップバイホップオプションヘッダが含まれており、前記ホップバイホップオプションヘッダには前記制御フラグが含まれている、項目１または２に記載の方法。
［項目４］
前記ホップバイホップオプションヘッダにはタイプ－長さ－値ＴＬＶが含まれており、前記ＴＬＶが前記制御フラグを搬送するのに用いられる、項目３に記載の方法。
［項目５］
前記制御フラグが、前記第２のＳＲｖ６パケットの前記ＳＲＨをオフセットするよう前記ＳＦデバイスに指示するのに用いられる、または
前記制御フラグが、前記第２のＳＲｖ６パケットの前記ＳＲＨと前記ＳＲＨ以外の別のＩＰｖ６拡張ヘッダとをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットにおいて前記別のＩＰｖ６拡張ヘッダが前記制御フラグの後に続く、項目１から４のいずれか一項に記載の方法。
［項目６］
前記第２のＳＲｖ６パケットにはさらにターゲット情報が含まれており、前記ターゲット情報とは、前記ＳＦデバイスがサービス処理を行うときに用いる必要がある情報であり、前記ターゲット情報が、
前記ＳＦＦが前記第１のＳＲｖ６パケットの前記ＳＲＨから前記ターゲット情報を取得する方式、または
前記ＳＦＦが前記第１のＳＲｖ６パケットの前記ＳＲＨからサービス情報を取得し、前記サービス情報に基づいてマッピング関係情報に照会して前記ターゲット情報を取得する方式であって、前記マッピング関係情報が前記サービス情報と前記ターゲット情報との対応関係を格納している、取得する方式
で取得される、項目１に記載の方法。
［項目７］
前記ターゲット情報にはサービス機能チェーンＳＦＣメタデータおよび仮想プライベートネットワークＩＤ ＶＰＮ ＩＤのうちの少なくとも一方が含まれている、または
前記サービス情報にはＳＦＣメタデータおよびＶＰＮ ＩＤのうちの少なくとも一方が含まれている、項目６に記載の方法。
［項目８］
前記ターゲット情報および前記制御情報が前記第２のＳＲｖ６パケットの同じＴＬＶに位置している、項目６または７に記載の方法。
［項目９］
ＳＲｖ６サービス機能チェーンでパケットを処理する方法であって、前記方法が、
サービス機能ＳＦデバイスが第２のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットをサービス機能転送器ＳＦＦから受信する段階であって、前記第２のＳＲｖ６パケットには制御フラグが含まれており、前記制御フラグが、前記第２のＳＲｖ６パケットにおいて前記制御フラグの後に続くインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダＳＲＨが含まれている、受信する段階と、
前記ＳＦデバイスが前記制御フラグに基づいて前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットする段階と
を備えている、方法。
［項目１０］
前記制御フラグがさらに、前記ＳＦＦにパケットを戻すプロセスにおいて、前記ＩＰｖ６拡張ヘッダを戻すよう前記ＳＦデバイスに指示するのに用いられ、前記方法がさらに、
前記ＳＦデバイスが前記制御フラグに基づいて前記ＳＦＦに第３のＳＲｖ６パケットを送信する段階を備えており、前記第３のＳＲｖ６パケットには前記ＩＰｖ６拡張ヘッダが含まれており、前記第３のＳＲｖ６パケットおよび前記第２のＳＲｖ６パケットが同じＳＲＨを有している、項目９に記載の方法。
［項目１１］
前記第２のＳＲｖ６パケットにはホップバイホップオプションヘッダが含まれており、前記ホップバイホップオプションヘッダには前記制御フラグが含まれている、項目９または１０に記載の方法。
［項目１２］
前記ホップバイホップオプションヘッダにはタイプ－長さ－値ＴＬＶが含まれており、前記ＴＬＶが前記制御フラグを搬送するのに用いられる、項目１１に記載の方法。
［項目１３］
前記制御フラグが、前記第２のＳＲｖ６パケットの前記ＳＲＨをオフセットするよう前記ＳＦデバイスに指示するのに用いられる、または
前記制御フラグが、前記第２のＳＲｖ６パケットの前記ＳＲＨと前記ＳＲＨ以外の別のＩＰｖ６拡張ヘッダとをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットにおいて前記別のＩＰｖ６拡張ヘッダが前記制御フラグの後に続く、項目９から１２のいずれか一項に記載の方法。
［項目１４］
前記ＳＦデバイスが前記制御フラグに基づいて前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットする前記段階の後に、前記方法がさらに、
前記ＳＦデバイスがサービス処理を行う段階を備えている、項目９に記載の方法。
［項目１５］
前記第２のＳＲｖ６パケットにはさらにターゲット情報が含まれており、前記ターゲット情報とは、前記ＳＦデバイスが前記サービス処理を行うときに用いる必要がある情報であり、サービス処理を行う前記段階が、
前記ターゲット情報に基づいて前記サービス処理を行う段階を含んでいる、項目１４に記載の方法。
［項目１６］
前記ターゲット情報にはサービス機能チェーンＳＦＣメタデータおよび仮想プライベートネットワークＩＤ ＶＰＮ ＩＤのうちの少なくとも一方が含まれている、項目１５に記載の方法。
［項目１７］
前記ターゲット情報および前記制御情報が前記第２のＳＲｖ６パケットの同じＴＬＶに位置している、項目１５または１６に記載の方法。
［項目１８］
ＳＲｖ６サービス機能チェーンでパケットを転送する方法であって、前記方法が、
サービス機能転送器ＳＦＦが第１のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットを受信する段階であって、前記第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ Ｅｎｄ．ＰＴ．ＳＩＤが含まれており、前記Ｅｎｄ．ＰＴ．ＳＩＤが、セグメントルーティングヘッダＳＲＨを取り除くことなく前記第１のＳＲｖ６パケットをサービス機能ＳＦデバイスに転送するよう前記ＳＦＦに指示するのに用いられる、受信する段階と、
前記ＳＦＦが前記Ｅｎｄ．ＰＴ．ＳＩＤおよび前記第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成する段階であって、前記第２のＳＲｖ６パケットのインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダにはＳＲＨが含まれている、生成する段階と、
前記ＳＦＦが前記第２のＳＲｖ６パケットを前記ＳＦデバイスの第１のインタフェースに送信する段階であって、前記ＳＦデバイスが、前記第１のインタフェースを通じて受信したパケットのＩＰｖ６拡張ヘッダをオフセットするように構成されている、送信する段階と
を備えている、方法。
［項目１９］
ＳＲｖ６サービス機能チェーンでパケットを処理する方法であって、前記方法が、
サービス機能ＳＦデバイスが第２のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットを第１のインタフェースを通じてサービス機能転送器ＳＦＦから受信する段階であって、前記ＳＦデバイスが、前記第１のインタフェースを通じて受信したパケットのインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダをオフセットするように構成されており、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダＳＲＨが含まれている、受信する段階と、
前記ＳＦデバイスが前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットする段階と
を備えている、方法。
［項目２０］
ＳＲｖ６サービス機能チェーンでパケットを転送する方法であって、前記方法が、
サービス機能転送器ＳＦＦが第１のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットを受信する段階であって、前記第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ Ｅｎｄ．ＰＴ．ＳＩＤが含まれており、前記Ｅｎｄ．ＰＴ．ＳＩＤが、セグメントルーティングヘッダＳＲＨを取り除くことなく前記第１のＳＲｖ６パケットをサービス機能ＳＦデバイスに転送するよう前記ＳＦＦに指示するのに用いられる、受信する段階と、
前記ＳＦＦが前記Ｅｎｄ．ＰＴ．ＳＩＤおよび前記第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成する段階であって、前記第２のＳＲｖ６パケットのインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダにはＳＲＨが含まれている、生成する段階と、
前記ＳＦＦが前記第２のＳＲｖ６パケットを前記ＳＦデバイスに送信する段階であって、前記ＳＦデバイスが、アクセス制御リストＡＣＬのマッチング条件を満たしているパケットのＩＰｖ６拡張ヘッダをオフセットするように構成されている、送信する段階と
を備えている、方法。
［項目２１］
ＳＲｖ６サービス機能チェーンでパケットを処理する方法であって、前記方法が、
サービス機能ＳＦデバイスが第２のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットをサービス機能転送器ＳＦＦから受信する段階であって、前記ＳＦデバイスが、アクセス制御リストＡＣＬのマッチング条件を満たしているパケットのインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダをオフセットするように構成されており、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダＳＲＨが含まれている、受信する段階と、
前記ＳＦデバイスが、前記第２のＳＲｖ６パケットが前記ＡＣＬの前記マッチング条件を満たしていると判定する段階と、
前記ＳＦデバイスが前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットする段階と
を備える、方法。
［項目２２］
サービス機能転送器ＳＦＦであって、前記ＳＦＦが、
第１のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットを受信するように構成された受信モジュールであって、前記第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ Ｅｎｄ．ＰＴ．ＳＩＤが含まれており、前記Ｅｎｄ．ＰＴ．ＳＩＤが、セグメントルーティングヘッダＳＲＨを取り除くことなく前記第１のＳＲｖ６パケットをサービス機能ＳＦデバイスに転送するよう前記ＳＦＦに指示するのに用いられる、受信モジュールと、
前記Ｅｎｄ．ＰＴ．ＳＩＤおよび前記第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成するように構成された生成モジュールであって、前記第２のＳＲｖ６パケットには制御フラグが含まれており、前記制御フラグが、前記第２のＳＲｖ６パケットにおいて前記制御フラグの後に続くインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはＳＲＨが含まれている、生成モジュールと、
前記第２のＳＲｖ６パケットを前記ＳＦデバイスに送信するように構成された送信モジュールと
を備えている、ＳＦＦ。
［項目２３］
サービス機能ＳＦデバイスであって、前記ＳＦデバイスが、
第２のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットをサービス機能転送器ＳＦＦから受信するように構成された受信モジュールであって、前記第２のＳＲｖ６パケットには制御フラグが含まれており、前記制御フラグが、前記第２のＳＲｖ６パケットにおいて前記制御フラグの後に続くインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダをオフセットするよう前記ＳＦデバイスに指示するのに用いられ、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダＳＲＨが含まれている、受信モジュールと、
前記制御フラグに基づいて前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットするように構成された処理モジュールと
を備えている、ＳＦデバイス。
［項目２４］
サービス機能転送器ＳＦＦであって、前記ＳＦＦが、
第１のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットを受信するように構成された受信モジュールであって、前記第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ Ｅｎｄ．ＰＴ．ＳＩＤが含まれており、前記Ｅｎｄ．ＰＴ．ＳＩＤが、セグメントルーティングヘッダＳＲＨを取り除くことなく前記第１のＳＲｖ６パケットをサービス機能ＳＦデバイスに転送するよう前記ＳＦＦに指示するのに用いられる、受信モジュールと、
前記Ｅｎｄ．ＰＴ．ＳＩＤおよび前記第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成するように構成された生成モジュールであって、前記第２のＳＲｖ６パケットのインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダにはＳＲＨが含まれている、生成モジュールと、
前記第２のＳＲｖ６パケットを前記ＳＦデバイスの第１のインタフェースに送信するように構成された送信モジュールであって、前記ＳＦデバイスが前記第１のインタフェースを通じて受信したパケットのＩＰｖ６拡張ヘッダをオフセットするように構成されている、送信モジュールと
を備えている、ＳＦＦ。
［項目２５］
サービス機能ＳＦデバイスであって、前記ＳＦデバイスが、
第２のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットをサービス機能転送器ＳＦＦから第１のインタフェースを通じて受信するように構成された受信モジュールであって、前記ＳＦデバイスが、前記第１のインタフェースを通じて受信したパケットのインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダをオフセットするように構成されており、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダＳＲＨが含まれている、受信モジュールと、
前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットするように構成された処理モジュールと
を備えている、ＳＦデバイス。
［項目２６］
サービス機能転送器ＳＦＦであって、前記ＳＦＦが、
第１のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットを受信するように構成された受信モジュールであって、前記第１のＳＲｖ６パケットの宛先アドレスにはエンドポイント貫通セグメントＩＤ Ｅｎｄ．ＰＴ．ＳＩＤが含まれており、前記Ｅｎｄ．ＰＴ．ＳＩＤが、セグメントルーティングヘッダＳＲＨを取り除くことなく前記第１のＳＲｖ６パケットをサービス機能ＳＦデバイスに転送するよう前記ＳＦＦに指示するのに用いられる、受信モジュールと、
前記Ｅｎｄ．ＰＴ．ＳＩＤおよび前記第１のＳＲｖ６パケットに基づいて第２のＳＲｖ６パケットを生成するように構成された生成モジュールであって、前記第２のＳＲｖ６パケットのインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダにはＳＲＨが含まれている、生成モジュールと、
前記第２のＳＲｖ６パケットを前記ＳＦデバイスに送信するように構成された送信モジュールであって、前記ＳＦデバイスが、アクセス制御リストＡＣＬのマッチング条件を満たしているパケットのＩＰｖ６拡張ヘッダをオフセットするように構成されている、送信モジュールと
を備えている、ＳＦＦ。
［項目２７］
サービス機能ＳＦデバイスであって、前記ＳＦデバイスが、
第２のインターネットプロトコルバージョン６を介したセグメントルーティングＳＲｖ６パケットをサービス機能転送器ＳＦＦから受信するように構成された受信モジュールであって、前記ＳＦデバイスが、アクセス制御リストＡＣＬのマッチング条件を満たしているパケットのインターネットプロトコルバージョン６ ＩＰｖ６拡張ヘッダをオフセットするように構成されており、前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダにはセグメントルーティングヘッダＳＲＨが含まれている、受信モジュールと、
前記第２のＳＲｖ６パケットが前記ＡＣＬの前記マッチング条件を満たしていると判定するように構成された判定モジュールと、
前記第２のＳＲｖ６パケットの前記ＩＰｖ６拡張ヘッダをオフセットするように構成された処理モジュールと
を備えている、ＳＦデバイス。
［項目２８］
サービス機能転送器ＳＦＦであって、前記ＳＦＦがプロセッサと物理インタフェースとを備えており、前記プロセッサが、前記ＳＦＦが項目１から８、項目１８、および項目２０のいずれか一項に記載の方法を行うのを可能にする命令を実行するように構成されており、前記物理インタフェースがパケットを受信するまたは送信するように構成されている、ＳＦＦ。
［項目２９］
サービス機能ＳＦデバイスであって、前記ＳＦデバイスがプロセッサと物理インタフェースとを備えており、前記プロセッサが、前記ＳＦデバイスが項目９から１７、項目１９、および項目２１のいずれか一項に記載の方法を行うのを可能にする命令を実行するように構成されており、前記物理インタフェースがパケットを受信するまたは送信するように構成されている、ＳＦデバイス。
［項目３０］
ネットワークシステムであって、前記システムがサービス機能転送器ＳＦＦとサービス機能ＳＦデバイスとを備えており、前記ＳＦＦが項目１から８、項目１８、および項目２０のいずれか一項に記載の方法を行うように構成されており、前記ＳＦデバイスが項目９から１７、項目１９、および項目２１のいずれか一項に記載の方法を行うように構成されている、ネットワークシステム。
［項目３１］
コンピュータ可読記憶媒体であって、前記記憶媒体が少なくとも１つの命令を格納しており、前記命令がプロセッサにより読み出されると、サービス機能転送器ＳＦＦが項目１から８、項目１８、および項目２０のいずれか一項に記載の方法を行う、コンピュータ可読記憶媒体。
［項目３２］
コンピュータ可読記憶媒体であって、前記記憶媒体が少なくとも１つの命令を格納しており、前記命令がプロセッサにより読み出されると、サービス機能ＳＦデバイスが項目９から１７、項目１９、および項目２１のいずれか一項に記載の方法を行う、コンピュータ可読記憶媒体。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】