JP6534625B2 - 通信装置および通信方法 - Google Patents

Description

本発明は、通信装置および通信方法に関する。

異なるサービス処理を行う複数のＳＦ（Service Function、サービス機能）を自由に組み合わせてサービスを提供するため、ユーザのパケットを任意のＳＦへ順に転送するサービスチェイニングと呼ばれる技術が知られている。サービスチェイニングでは、ネットワークの接続形態やＳＦの位置情報を収集し管理して、ユーザ毎にパケットが適切なＳＦを経由するように、転送経路が制御される。

現在、ＩＥＴＦ（Internet Engineering Task Force）では、ＳＦＣ（Service Function Chaining）としてサービスチェイニングの標準化が進められている。ＳＦＣにおいては、識別機能（以下、Ｃｌａｓｓｉｆｉｅｒと称する）がパケットを識別してサービス種別、経路情報、またはメタデータ等を含む適切なＳＦＣヘッダを付与する。ＳＦＣヘッダが付与されたパケットを受信した転送機能（以下、ＳＦＦ（Service Function Forwarder）と称する）が、ＳＦＣヘッダを読み取って次の転送先となるＳＦを判定し、例えば、アンダーレイネットワークに応じたＧＲＥ，ＶｘＬＡＮ等の転送ヘッダを利用して転送する。

なお、ＳＦＣヘッダの仕様に対応していないＳＦに対してパケットが転送される場合には、ＳＦＦとＳＦとの間に介在するヘッダプロキシ機能（以下、ＳＦＣプロキシと称する）がＳＦＣヘッダを除去して当該ＳＦにパケットを挿入し、当該ＳＦから返送されるパケットに再びＳＦＣヘッダを付与している（非特許文献１参照）。

ここで、パケットフローの各パケットに付与されるＳＦＣヘッダは、パケット毎に異なる場合があるため、ＳＦＣプロキシはパケット毎にＳＦＣヘッダの情報を保持する必要がある。ＳＦＣプロキシがＳＦＣパケットの情報を保持する方式として、タグ変換方式とフロー情報保存方式との２方式が考えられる。タグ変換方式では、ＳＦＣヘッダのタグが転送先のＳＦが対応しているＶＬＡＮ等の他のタグに変換される。フロー情報保存方式では、フローの識別に必要な５−ｔｕｐｌｅ等の情報とＳＦＣヘッダの情報とが併せて保持される。

"SFC Header Mapping for Legacy SF"、2015年8月19日、IETF、[online]、[2015年12月18日検索]、インターネット＜URL:https://datatracker.ietf.org/doc/draft-song-sfc-legacy-sf-mapping/＞

しかしながら、タグ変換方式では、転送先のＳＦが対応していないタグには変換できないため、転送先のＳＦの特性に応じて変換に使用できるタグが制限される場合がある。したがって、転送先となる全てのＳＦを考慮してタグ変換方式の仕様を統一するためには、変換に使用するタグに制限があった。

また、通常、インラインに設置されるＳＦを通過する同一セッションのパケットフローは、双方向で同一のＶＬＡＮに属する。したがって、異なるＶＬＡＮのタグが付与されているパケットフローを別のセッションと認識する一部のＳＦに対しては、タグ変換方式を適用することができなかった。

また、キャリアのネットワーク等の膨大かつ多様な５−ｔｕｐｌｅのフローが流通するネットワークにおいては、フロー情報保存方式では、５−ｔｕｐｌｅ等のフローを識別する情報を保持するために必要なテーブルの更新の処理が高負荷になるという問題があった。また、パケット内のフローを識別する情報を変更するＮＡＴ（ネットワークアドレス変換）等のＳＦに対しては、フロー情報保存方式は適用できないという課題もあった。

本発明は、上記に鑑みてなされたものであって、パケットに付与されたヘッダの仕様に対応していない非対応装置に対して、他のヘッダへの変換や膨大なパケットフローのステートの保持を必要とせずに、非対応装置の仕様に応じてパケットを変換して送信し、当該非対応装置から返送されたパケットに適切なヘッダを付与することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る通信装置は、パケットに付与されているヘッダの仕様に対応していない非対応装置に該パケットを送信した後、該非対応装置から返送された該パケットを、前記ヘッダの仕様に対応している対応装置に送信する通信装置であって、受信したパケットに付与されている前記ヘッダを、該パケットから除去するとともに、該ヘッダの情報を該パケット内の所定のフィールドに格納する格納部と、前記非対応装置から返送された前記パケット内の前記フィールドに格納されている前記ヘッダの情報を、該フィールドから除去するとともに、該ヘッダの情報を用いて前記ヘッダを復元して該パケットに付与する付与部と、を備えることを特徴とする。

本発明によれば、パケットに付与されたヘッダの仕様に対応していない非対応装置に対して、他のヘッダへの変換や膨大なパケットフローのステートの保持を必要とせずに、非対応装置の仕様に応じてパケットを変換して送信し、当該非対応装置から返送されたパケットに適切なヘッダを付与することができる。

図１は、第１の実施形態に係るＳＦＣプロキシを含むシステム構成を例示する模式図である。 図２は、第１の実施形態のＳＦＣプロキシの処理の概要を説明するための説明図である。 図３は、本発明の第１の実施形態に係るＳＦＣプロキシの概略構成を示す模式図である。 図４は、第１の実施形態の通信処理の概要を説明するための説明図である。 図５は、第１の実施形態の変換処理手順を示すフローチャートである。 図６は、第１の実施形態の復元処理手順を示すフローチャートである。 図７は、第２の実施形態のＳＦＣプロキシの概略構成を示す模式図である。 図８は、第２の実施形態の通信処理の概要を説明するための説明図である。 図９は、第２の実施形態の変換処理手順を示すフローチャートである。 図１０は、第２の実施形態の復元処理手順を示すフローチャートである。

［第１の実施形態］
以下、図面を参照して、本発明の第１の実施形態を詳細に説明する。本実施形態において、本発明の通信装置には、ＳＦＣプロキシが適用されている。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

［システム構成］
まず、図１および図２を参照して、本実施形態の通信装置としてのＳＦＣプロキシを含むシステム構成について説明する。図１に示すように、ユーザ端末１から送信されたパケットフローｆの各パケットを、Ｃｌａｓｓｉｆｉｅｒ２が識別し、サービス種別、経路情報、またはメタデータ等を含む適切なＳＦＣヘッダを付与する。

ＳＦＦ３は、ＳＦＣヘッダが付与されたパケットをネットワークを介して受信すると、ＳＦＣヘッダを読み取って、次の転送先となるＳＦ４を判定して転送する。ＳＦＣヘッダの仕様に対応しているＳＦ４ａは、ＳＦＣヘッダの情報を参照してサービス処理を実施する。

一方、ＳＦＣヘッダ２０の仕様に対応していない非対応装置としてのＳＦ４ｂに対しては、ＳＦＣプロキシ５を介して、ＳＦＣヘッダが除去されたパケットが転送され、ＳＦ４ｂがサービス処理を実施する。

ここで、図２に例示するように、ＳＦＣプロキシ５は、ＳＦＦ３とＳＦ４ｂとの間に介在し、パケット１０に付与されているＳＦＣヘッダ２０の仕様に対応していないＳＦ４ｂに該パケット１０を送信した後、該ＳＦ４ｂから返送された該パケット１０を、ＳＦＣヘッダ２０の仕様に対応しているＳＦＦ３に送信する。

その際、ＳＦＣプロキシ５は、後述する通信処理を行って、ＳＦＣヘッダ２０を除去して当該ＳＦ４ｂにパケット１０を挿入する。このＳＦＣプロキシ５は、当該ＳＦ４ｂからパケット１０が返送されると、返送されたパケット１０に再びＳＦＣヘッダ２０を付与して、対応装置としてのＳＦＦ３に送信する。

このようにしてパケットフローｆが、適切な順にＳＦ４を通過して、コンテンツサーバやウェブサーバ等のサーバ装置７に転送される。なお、Ｃｏｎｔｒｏｌｌｅｒ６は、ＳＦＦ３やＳＦ４等の各コンポーネントや、各ＳＦ４へのパケットフローｆの転送順すなわちサービスチェインを管理している。

［ＳＦＣプロキシの構成］
次に、図３を参照して、本実施形態に係るＳＦＣプロキシ５の概略構成を説明する。本実施形態のＳＦＣプロキシ５は、ワークステーションやパソコン等の汎用コンピュータで実現され、ＩＦ（インタフェース）５１、ヘッダ変換部５２、ヘッダ復元部５３、および転送処理部５４を有する。

ＩＦ５１は、例えばＮＩＣ（Network Interface Card）等で実現され、ＳＦＦ３やＳＦ４ｂとの通信を制御する。また、処理プログラムを実行するＣＰＵ（Central Processing Unit）等を用いて実現される制御部が、ヘッダ変換部５２、ヘッダ復元部５３、および転送処理部５４として機能する。

ヘッダ変換部５２は、格納部として、受信したパケット１０に付与されているＳＦＣヘッダ２０を、該パケット１０から除去するとともに、該ＳＦＣヘッダ２０の情報を該パケット１０内の所定のフィールドに格納する。

具体的に、図４を参照してヘッダ変換部５２の処理を説明する。ここで、パケット１０は、ＩＰヘッダ１１とペイロード１２とで構成される。図４に矢印Ａで示すように、ヘッダ変換部５２は、ＳＦＦ３から受信した、ＳＦＣヘッダ２０、ＩＰヘッダ１１およびペイロード１２を含むパケットから、ＳＦＣヘッダ２０の情報を読み取った後、ＳＦＣヘッダ２０を除去する。そして、ヘッダ変換部５２は、読み取ったＳＦＣヘッダ２０の情報をＩＰヘッダ１１内の例えばオプションフィールド等に格納する変換を行う。その後、ＳＦＣプロキシ５は、変換されたパケットをＳＦ４ｂに挿入する。

ヘッダ復元部５３は、付与部として、ＳＦ４ｂから返送されたパケット１０内の所定のフィールドに格納されているＳＦＣヘッダ２０の情報を、該フィールドから除去するとともに、該ＳＦＣヘッダ２０の情報を用いてＳＦＣヘッダ２０を復元して該パケット１０に付与する。

具体的に、図４に矢印Ｂで示すように、ヘッダ復元部５３は、サービス処理の後にＳＦ４ｂから返送されたパケットから、ＩＰヘッダ１１内のオプションフィールド等に格納されているＳＦＣヘッダ２０の情報を除去し、パケットにＳＦＣヘッダ２０として復元する変換を行う。その後、ＳＦＣプロキシ５は、変換されたパケットをＳＦＦ３に送信する。

転送処理部５４は、ＳＦ４ｂにパケットを挿入する際、あるいはＳＦＦ３にパケットを返送する際に、宛先を指定する情報を含むイーサネット（登録商標）ヘッダ等を付与する。なお、ＳＦＦ３とＳＦ４ｂとの間の通信において、ＳＦＣプロキシ５の経由が明示的に指定されない透過型である場合には、転送処理部５４は不要である。

［通信処理］
次に、図５および図６を参照して、ＳＦＣプロキシ５による通信処理について説明する。通信処理は、変換処理と復元処理とを含む。まず、図５に例示する変換処理のフローチャートは、例えば、ＳＦＣプロキシ５がＩＦ５１を介してＳＦＦ３からパケット１０を受信したタイミングで開始される。

まず、ヘッダ変換部５２が、ＳＦＦ３から受信したパケット１０に付加されているＳＦＣヘッダ２０の情報を取得し、取得したＳＦＣヘッダ２０の情報をＩＰヘッダ１１内のオプションフィールド等に格納する（ステップＳ１）。

次に、ヘッダ変換部５２が、ＳＦＣヘッダ２０を除去する（ステップＳ２）。その後、ＳＦＣヘッダ２０が除去されたパケット１０は、ＩＦ５１を介してＳＦ４ｂへ挿入される。

また、図６に例示する復元処理のフローチャートは、例えば、ＳＦＣプロキシ５がＩＦ５１を介してＳＦ４ｂからパケット１０を受信したタイミングで開始される。

ヘッダ復元部５３は、サービス処理の後にＳＦ４ｂから返送されたパケット１０から、ＩＰヘッダ１１内のオプションフィールド等に格納されているＳＦＣヘッダ２０の情報を取得し、ＳＦＣヘッダ２０を復元し、パケット１０に付与する（ステップＳ４）。

次に、ヘッダ復元部５３は、ＩＰヘッダ１１内のオプションフィールドからＳＦＣヘッダ２０の情報を除去する（ステップＳ５）。その後、ＳＦＣヘッダ２０が付与されたパケット１０は、ＩＦ５１を介してＳＦＦ３へ返送される。

以上、説明したように、本実施形態のＳＦＣプロキシ５では、ヘッダ変換部５２が、受信したパケット１０に付与されているＳＦＣヘッダ２０を、該パケット１０から除去するとともに、該ＳＦＣヘッダ２０の情報を該パケット１０内のオプションフィールド等の所定のフィールドに格納する。また、ヘッダ復元部５３が、ＳＦ４ｂから返送されたパケット１０内の所定のフィールドに格納されているＳＦＣヘッダ２０の情報を、該フィールドから除去するとともに、ＳＦＣヘッダ２０として該パケット１０に付与する。

これにより、本実施形態のＳＦＣプロキシ５による通信処理によれば、ＳＦＣヘッダ２０が付与されたパケットを、ＳＦＣヘッダ２０の仕様に対応していないＳＦ４ｂを介して、ＳＦＣヘッダ２０の仕様に対応しているＳＦＦ３に送信することができる。またイレギュラーなヘッダが付与されないため、仕様として統一しても、多数のＳＦ４ｂに対して適用できる。また、フローを識別する情報を参照しないため、パケット内のフローを識別する情報を変更するＮＡＴ等のＳＦに対しても、適用できる。このように、本実施形態の通信装置の通信処理によれば、パケットに付与されたヘッダの仕様に対応していない非対応装置に対して、他のヘッダへの変換や膨大なパケットフローのステートの保持を必要とせずに、非対応装置の仕様に応じてパケットを変換して送信し、当該非対応装置から返送されたパケットに適切なヘッダを付与することができる。

特に、本実施形態によれば、パケットフローのステートをメモリ等を使用して管理する必要がない。したがって、スケーラビリティの観点で優れ、キャリアのネットワーク等の大規模なネットワークへの適用が期待できる。

［第２の実施形態］
メタデータを含む場合等のようにＳＦＣヘッダ２０のサイズが大きい場合に、ＳＦＣヘッダ２０の情報を圧縮して圧縮情報を算出し、この圧縮情報をＩＰヘッダ１１内に挿入してもよい。この場合、ＳＦＣプロキシ５がＳＦＣヘッダ２０の情報と圧縮情報との対応付けを管理する。

図７は、このような第２の実施形態のＳＦＣプロキシ５の概略構成を例示する模式図である。図７に例示するように、本実施形態は、上記の第１の実施形態とは、ヘッダ変換ＤＢ５５を備える点と、ヘッダ変換部５２およびヘッダ復元部５３の処理内容とが異なる。以下の説明では、第１の実施形態と異なる点についてのみ記載する。

ヘッダ変換ＤＢ５５は、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、記憶部として、後述する変換対応表を記憶する。

ヘッダ変換部５２は、格納部として、受信したパケット１０に付与されているＳＦＣヘッダ２０を、該パケット１０から除去するとともに、該ＳＦＣヘッダ２０の情報を圧縮した圧縮情報を、該パケット１０内の所定のフィールドに格納する。

具体的に、図８を参照してヘッダ変換部５２の処理を説明する。本実施形態のヘッダ変換部５２は、ヘッダ圧縮部５２ａ、圧縮データ格納部５２ｂ、およびヘッダ除去部５２ｃを有する。

ヘッダ圧縮部５２ａは、ＳＦＦ３から受信した、ＳＦＣヘッダ２０、ＩＰヘッダ１１およびペイロード１２を含むパケットから、ＳＦＣヘッダ２０の情報を読み取って、ナンバリングやハッシュ等を使って圧縮し、ハッシュ値等の圧縮情報２１を算出する。

また、ヘッダ圧縮部５２ａは、ＳＦＣヘッダ２０の情報と算出された圧縮情報２１とを対応付けし、変換対応表５５ａとしてヘッダ変換ＤＢ５５に格納する。図８に示す変換対応表５５ａには、例えば、ＳＦＣヘッダ２０の情報が＃１である場合に、圧縮情報２１としてＡが算出されたことが示されている。

また、図８に矢印Ａで示すように、圧縮データ格納部５２ｂが算出された圧縮情報２１をＩＰヘッダ１１内の例えばオプションフィールド等に格納し、ヘッダ除去部５２ｃがＳＦＣヘッダ２０を除去する変換を行う。その後、ＳＦＣプロキシ５は、変換されたパケットをＳＦ４ｂに挿入する。

ヘッダ復元部５３は、付与部として、ＳＦ４ｂから返送されたパケット１０内のフィールドに格納されている圧縮情報２１を該フィールドから除去するとともに、該圧縮情報２１に対応するＳＦＣヘッダ２０の情報をＳＦＣヘッダ２０として該パケットに付与する。

具体的には、本実施形態のヘッダ復元部５３は、格納データ読取部５３ａ、ヘッダ作成部５３ｂ、および格納データ除去部５３ｃを有する。

格納データ読取部５３ａは、サービス処理の後にＳＦ４ｂから返送されたパケットから、ＩＰヘッダ１１内のオプションフィールド等に格納されている圧縮情報２１を取得して、これを用いてヘッダ変換ＤＢ５５の変換対応表５５ａを参照し、ＳＦＣヘッダ２０の情報を取得する。

また、図８に矢印Ｂで示すように、ヘッダ作成部５３ｂが、取得されたＳＦＣヘッダ２０の情報をパケット１０に付与してＳＦＣヘッダ２０として復元し、格納データ除去部５３ｃがＩＰヘッダ１１内に格納されていた圧縮情報２１を除去する変換を行う。その後、ＳＦＣプロキシ５は、変換されたパケットをＳＦＦ３に送信する。

次に、図９および図１０を参照して、本実施形態のＳＦＣプロキシ５による通信処理について説明する。上記した第１の実施形態と同様に、通信処理は、変換処理と復元処理とを含む。まず、図９に例示する変換処理のフローチャートは、例えば、ＳＦＣプロキシ５がＩＦ５１を介してＳＦＦ３からパケット１０を受信したタイミングで開始される。

まず、ヘッダ圧縮部５２ａが、ＳＦＦ３から受信したパケット１０に付加されているＳＦＣヘッダ２０の情報を取得する。次に、ヘッダ圧縮部５２ａが、取得したＳＦＣヘッダ２０の情報を圧縮して算出した圧縮情報２１を、ＩＰヘッダ１１内のオプションフィールド等に格納する（ステップＳ１１）。

次に、圧縮データ格納部５２ｂは、ＳＦＣヘッダ２０の情報と圧縮情報２１とを対応付けして、変換対応表５５ａとしてヘッダ変換ＤＢ５５に格納する（ステップＳ１２）。また、ヘッダ除去部５２ｃがＳＦＣヘッダ２０を除去する（ステップＳ１３）。その後、ＳＦＣヘッダ２０が除去されたパケット１０は、ＩＦ５１を介してＳＦ４ｂへ挿入される。

また、図１０に例示する復元処理のフローチャートは、例えば、ＳＦＣプロキシ５がＩＦ５１を介してＳＦ４ｂからパケット１０を受信したタイミングで開始される。

まず、格納データ読取部５３ａが、サービス処理の後にＳＦ４ｂから返送されたパケット１０から、ＩＰヘッダ１１内のオプションフィールド等に格納されている圧縮情報２１を取得する。また、圧縮情報２１を用いてヘッダ変換ＤＢ５５の変換対応表５５ａを参照してＳＦＣヘッダ２０の情報を取得する。また、ヘッダ作成部５３ｂが、取得されたＳＦＣヘッダ２０の情報を用いてＳＦＣヘッダ２０を復元し、パケット１０に付与する（ステップＳ１４）。

次に、格納データ除去部５３ｃは、ＩＰヘッダ１１内のオプションフィールドから圧縮情報２１を除去する（ステップＳ１５）。その後、ＳＦＣヘッダ２０が付与されたパケット１０は、ＩＦ５１を介してＳＦＦ３へ返送される。

以上、説明したように、本実施形態のＳＦＣプロキシ５の通信処理によれば、上記第１の実施形態と同様に、イレギュラーなヘッダが付与されないため、統一化された仕様として、多数のＳＦ４ｂに適用できる。また、フローを識別する情報を参照しないため、パケット内のフローを識別する情報を変更するＮＡＴ等のＳＦに対しても、適用できる。

特に本実施形態によれば、メタデータを含む場合等のようにＳＦＣヘッダ２０のサイズが大きい場合にも、ＭＴＵ（Max Transmission Unit）による制限を受けたりＳＦ４ｂの負荷を増加させたりする恐れが少ない。

また、パケットフローのステートの代わりにヘッダのステートを管理するので、５−ｔｕｐｌｅ等のフロー識別情報の種別より少ないヘッダの種別の管理で足り、処理負荷を抑制することができる。したがって、規模の大きいネットワークに適用することも可能である。

以上、本発明者によってなされた発明を適用した実施形態について説明したが、本実施形態による本発明の開示の一部をなす記述および図面により本発明は限定されることはない。すなわち、本実施形態に基づいて当業者等によりなされる他の実施形態、実施例および運用技術等は全て本発明の範疇に含まれる。

１ ユーザ端末
２ Ｃｌａｓｓｉｆｉｅｒ
３ ＳＦＦ
４，４ａ，４ｂ ＳＦ
５ ＳＦＣプロキシ
５１ ＩＦ
５２ ヘッダ変換部
５２ａ ヘッダ圧縮部
５２ｂ 圧縮データ格納部
５２ｃ ヘッダ除去部
５３ ヘッダ復元部
５３ａ 格納データ読取部
５３ｂ ヘッダ作成部
５３ｃ 格納データ除去部
５４ 転送処理部
５５ ヘッダ変換ＤＢ
６ Ｃｏｎｔｒｏｌｌｅｒ
７ サーバ装置
１０ パケット
１１ ＩＰヘッダ
１２ ペイロード
２０ ＳＦＣヘッダ
２１ 圧縮情報

Claims (3)

1. パケットに付与されているヘッダの仕様に対応していない非対応装置に該パケットを送信した後、該非対応装置から返送された該パケットを、前記ヘッダの仕様に対応している対応装置に送信する通信装置であって、
   受信したパケットに付与されている前記ヘッダを、該パケットから除去するとともに、該ヘッダの情報を該パケット内の所定のフィールドに格納する格納部と、
   前記非対応装置から返送された前記パケット内の前記フィールドに格納されている前記ヘッダの情報を、該フィールドから除去するとともに、該ヘッダの情報を用いて前記ヘッダを復元して該パケットに付与する付与部と、
   を備えることを特徴とする通信装置。
2. 前記非対応装置はサービス機能を備え、前記対応装置はパケットの次の転送先を判定する転送機能を備え、前記ヘッダはパケットを識別する識別機能により付与されたヘッダであることを特徴とする請求項１に記載の通信装置。
3. パケットに付与されているヘッダの仕様に対応していない非対応装置に該パケットを送信した後、該非対応装置から返送された該パケットを、前記ヘッダの仕様に対応している対応装置に送信する通信装置で実行される通信方法であって、
   受信したパケットに付与されている前記ヘッダを、該パケットから除去するとともに、該ヘッダの情報を該パケット内の所定のフィールドに格納する格納工程と、
   前記非対応装置から返送された前記パケット内の前記フィールドに格納されている前記ヘッダの情報を、該フィールドから除去するとともに、該ヘッダの情報を用いて前記ヘッダを復元して該パケットに付与する付与工程と、
   を含んだことを特徴とする通信方法。
   

Images