特許 6240158 ソフトウェア定義型ネットワーキングを用いたインラインサービスの連鎖化

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

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

(11)【特許番号】6240158

(24)【登録日】2017年11月10日

(45)【発行日】2017年11月29日

(54)【発明の名称】ソフトウェア定義型ネットワーキングを用いたインラインサービスの連鎖化

(51)【国際特許分類】

   H04L 12/721 20130101AFI20171120BHJP

   H04L 12/741 20130101ALI20171120BHJP

【ＦＩ】

   H04L12/721 Z

   H04L12/741

【請求項の数】25

【全頁数】26

(21)【出願番号】特願2015-506339(P2015-506339)

(86)(22)【出願日】2013年4月16日

(65)【公表番号】特表2015-517272(P2015-517272A)

(43)【公表日】2015年6月18日

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

(87)【国際公開番号】WO2013156931

(87)【国際公開日】20131024

【審査請求日】2016年3月16日

(31)【優先権主張番号】61/624,823

(32)【優先日】2012年4月16日

(33)【優先権主張国】US

(31)【優先権主張番号】13/556,456

(32)【優先日】2012年7月24日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】598036300

【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）

(74)【代理人】

【識別番号】100095957

【弁理士】

【氏名又は名称】亀谷 美明

(74)【代理人】

【識別番号】100096389

【弁理士】

【氏名又は名称】金本 哲男

(74)【代理人】

【識別番号】100101557

【弁理士】

【氏名又は名称】萩原 康司

(74)【代理人】

【識別番号】100128587

【弁理士】

【氏名又は名称】松本 一騎

(72)【発明者】

【氏名】ルフェーヴル、ジェフリー

(72)【発明者】

【氏名】ルボウ、エリク

(72)【発明者】

【氏名】マンギルマラニ、ラヴィ

【審査官】 野元 久道

(56)【参考文献】

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

【文献】 特開２００３−２５６３９１（ＪＰ，Ａ）

【文献】 特表２００４−５３２４７２（ＪＰ，Ａ）

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

Ｈ０４Ｌ １２／７２１

Ｈ０４Ｌ １２／７４１

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

【請求項1】

スイッチングエレメントによりネットワークのパケットトラフィックを誘導するための方法であって、
パケットを受信することと、
アップストリーム又はダウンストリームである、受信された前記パケットが伝播している方向を判定することと、
受信された前記パケットをサービスセットに関連付けることと、
前記サービスセット内のどのサービスが前記パケットに適用されたかを判定することにより、関連付けられた前記サービスセット内の前記パケットの位置を判定することと、
判定された方向と前記パケットの位置とに従って、関連付けられた前記サービスセット内の次のサービスを選択することと、
選択された前記次のサービスに従って、前記パケットに新たな宛て先を割り当てることと、
を含む方法。

【請求項2】

受信された前記パケットが伝播している前記方向は、前記パケットが受信された入口ポートに従って判定される、請求項１の方法。

【請求項3】

受信された前記パケットを前記サービスセットに関連付けるステップは、受信された前記パケットに適用されるべきサービスの順序付きリストを割り当てることを含む、請求項１の方法。

【請求項4】

受信された前記パケットは、判定された前記方向及び前記パケットの第１のヘッダフィールドに従って、前記サービスセットに関連付けられる、請求項１の方法。

【請求項5】

前記第１のヘッダフィールドは、送信元アドレス、宛て先アドレス、送信元ポート、宛て先ポート及びプロトコルを含む群から選択される、請求項４の方法。

【請求項6】

受信された前記パケットを前記サービスセットに関連付けるステップは、加入者に関連付けられるアドレスに従って、デフォルトのサービスを受信された前記パケットに割り当てることを含む、請求項１の方法。

【請求項7】

前記加入者に関連付けられる前記アドレスは、判定された前記方向に従って、受信された前記パケットの送信元アドレス又は宛て先アドレスから選択される、請求項６の方法。

【請求項8】

受信された前記パケットの第２のヘッダフィールドに従って、前記デフォルトのサービスセットを修正するステップをさらに含む、請求項６の方法。

【請求項9】

前記第２のヘッダフィールドは、送信元アドレス、宛て先アドレス、送信元ポート、宛て先ポート及びプロトコルを含む群から選択される、請求項８の方法。

【請求項10】

関連付けられた前記サービスセット内の前記パケットの前記位置は、前記パケットが受信された入口ポートに従って判定される、請求項１の方法。

【請求項11】

受信された前記パケットに既に適用されたサービスを除去するために、判定された方向及び前記パケットの位置に従って、関連付けられた前記サービスセットを修正するステップをさらに含む、請求項１の方法。

【請求項12】

前記パケットに新たな宛て先を割り当てるステップは、前記パケットの宛て先アドレスを書き換えることを含む、請求項１の方法。

【請求項13】

割り当てられた前記新たな宛て先に前記パケットを転送するステップをさらに含む、請求項１の方法。

【請求項14】

転送する前記ステップは、割り当てられた前記新たな宛て先アドレスに関連付けられるポートを選択することと、選択された前記ポート上で前記パケットを送信することと、を含む、請求項１３の方法。

【請求項15】

各々がネットワークのパケットトラフィックを受信及び送信するための複数のポートと、
前記複数のポートに動作可能に接続されるプロセッサであって、アップストリーム又はダウンストリームである第１のポートで受信されたパケットが伝播している方向を判定し、前記パケットをサービスセットに関連付け、前記サービスセット内のどのサービスが前記パケットに適用されたかを判定することにより、関連付けられた前記サービスセット上の受信された前記パケットの位置を検出し、判定された前記方向と検出された前記位置とに従って、関連付けられた前記サービスセット上の次のサービスを判定し、前記複数のポートから第２のポートを選択し、及び選択された前記第２のポート上で、判定された前記次のサービスに前記パケットを送信するための前記プロセッサと、
を含むスイッチ。

【請求項16】

選択された前記第２のポートは、判定された前記次のサービスに関連付けられる、請求項１５のスイッチ。

【請求項17】

複数のポートは、サービスノードからダウンストリームに伝播するパケットを受信するための及びサービスノードに対しアップストリームに伝播するパケットを送信するためのアップストリーム対向ポートと、サービスノードからアップストリームに伝播するパケットを受信するための及びサービスノードに対しダウンストリームに伝播するパケットを送信するためのダウンストリーム対向ポートと、を含む、請求項１５のスイッチ。

【請求項18】

前記プロセッサは、受信された前記パケットが伝播している前記方向を、前記第１のポートに従って判定するように構成される、請求項１５のスイッチ。

【請求項19】

前記プロセッサは、判定された前記方向及び受信された前記パケットの第１のヘッダフィールドに従って、受信された前記パケットを前記サービスセットに関連付ける、請求項１８のスイッチ。

【請求項20】

前記プロセッサは、加入者に関連付けられたアドレスに従って、デフォルトのサービスセットを受信された前記パケットに割り当てるように構成される、請求項１５のスイッチ。

【請求項21】

前記加入者に関連付けられた前記アドレスは、受信された前記パケットの送信元アドレス又は宛て先アドレスのうちの１つである、請求項２０のスイッチ。

【請求項22】

前記プロセッサは、受信された前記パケットの第２のヘッダフィールドに従って、前記デフォルトのサービスセットを修正するように構成される、請求項２０のスイッチ。

【請求項23】

前記プロセッサは、前記第１のポートに従って、関連付けられた前記サービスセット上の受信された前記パケットの前記位置を判定するように構成される、請求項１５のスイッチ。

【請求項24】

前記プロセッサは、判定された前記次のサービスに従って、受信された前記パケットに新たな宛て先を割り当てるように構成される、請求項１５のスイッチ。

【請求項25】

関連付けられた方向を有しないパケットを受信するためのトランジットポートをさらに含み、
前記プロセッサは、専らその宛て先アドレスに従って、関連付けられた方向を有しない前記パケットを転送する、請求項１５のスイッチ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般に、ソフトウェア定義型ネットワーキング（Software Defined Networking）を用いたインラインサービスのチェーンを通じてトラフィックを誘導するためのシステム及び方法に関する。

【背景技術】

【0002】

モバイル及び固定のネットワーク事業者は、彼らのネットワークを横断するネットワークトラフィックを検査し及び改変するために、多様なタイプのミドルボックス又はインラインサービスを使用する。本文書においてサービスとして言及されることになるそれらミドルボックスは、エンドユーザにとっては透過的であり、透過的キャッシング（transparent caching）、ウィルススキャン、及びディープパケットインスペクションといった機能性を提供する。これらサービスは、通常はパッケージ化され、（物理的又は仮想的のいずれかの）専用の製品として販売され、しばしば高価である。

【0003】

事業者は、トラフィック需要における急激な増加に直面しており、彼らのネットワークを収益化する新たな手法を検討している。サービス製品の高コストに起因して、事業者は、それらサービスのキャパシティをその成長に一致させることを回避しようと望む。事業者は、むしろ、全てのトラフィックにあらゆるサービスを通過させる代わりに、トラフィックを特定のサービスのセットへと選択的に方向付ける能力を有するであろう。この能力は、近年のトラフィックの激増の源であるビデオトラフィックを、事業者がディープトラフィックインスペクションといった高価なサービスから離して誘導することを可能とし、よって、新たなサービス製品に投資する必要性が低減される。

【0004】

特定のクラスのトラフィックを予め定義されるサービスのセットを通過するように誘導する能力は、事業者のための収益の新たなストリームを可能にするためにも使用されることができる。事業者は、ウィルススキャン又はコンテンツフィルタリングといったサービスを、そうしたサービスに支払いをすることを選択する顧客にオファーし得る。

【0005】

サービスチェーン又はパスは、順序付きのサービスのセットである。トラフィックの誘導（traffic steering）は、トラフィックを分類し、様々なクラスのトラフィックを特定のサービスチェーンを通過するように方向付けるアクションである。大まかな３つのクラスの解決策が、今日、何らかの形態のトラフィックの誘導及びサービスの連鎖化（chaining）を実装するために使用されている。

【0006】

第１のアプローチは、拡張可能なルータ又はゲートウェイの一部としてサービスを統合することである。事業者は、追加のサービスカードをそのルータ又はゲートウェイに追加することにより、新たなサービスを追加することができる。

【0007】

第２のアプローチは、各サービスがそのチェーン内の次のサービスにトラフィックを送信するように構成される、１つ以上の静的サービスチェーンを構成することである。ポリシーベースルーティング（ＰＢＲ）を使用するルータは、着信（incoming）トラフィックを分類し、分類結果に基づいて各チェーンの先頭にあるサービスにそれを転送する。

【0008】

第３のアプローチは、ＰＢＲを使用するルータを使用し、各サービスがトラフィックの処理後ルータにトラフィックを返すように構成されることである。ルータは、各サービスホップの後でトラフィックを分類し、分類結果に基づいて適当なサービスにそれを転送する。

【0009】

３つのクラスの解決策全てが、欠点を有する。第１のアプローチは、既存のサードパーティサービス製品の統合をサポートしない。この解決策は、プロプライエタリであり、サービスベンダーは、ルータ又はゲートウェイによりサポートされるソフトウェア及びハードウェア構成にそれらのアプリケーションを移植しなければならない。この解決策は、サービスの数として拡張性の問題を潜在的に抱えており、合計の帯域幅がルータのキャパシティにより制限される。

【0010】

第２のアプローチは、一元的な方法でのポリシーの定義をサポートせず、代わりに各サービスがトラフィックを分類し適当な次のサービスに誘導するように構成されることを必要とする。このアプローチは、大量のサービス固有の構成を必要とし、エラーを起こしやすい可能性がある。また、第２のアプローチは、加入者一人毎のトラフィックの誘導をサポートせず、構成され得る様々なサービスチェーンを制限するため、柔軟性にも欠ける。これらの制限を避けて通ることは、トラフィックを分類し誘導するための各サービスにおける追加的な構成、及びネットワークに接続する加入者として動的にこれらの構成をプッシュするための自動化された方法を必要とするであろう。

【0011】

第３のアプローチも、全てのサービスを経てトラフィックにルータを通過させるため、拡張性の問題を抱える。Ｎ−１個のサービスを有するチェーンをサポートするために、ルータは、Ｎ倍の着信トラフィックライン速度をハンドリングすることが可能でなければならない。

【0012】

したがって、上述した問題を未然に防ぎ、又は軽減するシステム及び方法を提供することが望ましいであろう。

【発明の概要】

【発明が解決しようとする課題】

【0013】

本発明の目的は、少なくとも１つの従来技術の欠点を未然に防ぎ、又は軽減することである。

【課題を解決するための手段】

【0014】

本発明の第１の態様では、パケットを受信すること及び受信されたパケットが伝播している方向を判定することを含む、パケットトラフィックを誘導するための方法が提供される。受信されたパケットは、サービスセットに関連付けられ、関連付けられたサービスセット上のパケットの位置が判定される。関連付けられたサービスセット上の次のサービスは、判定された方向及びパケットの位置に従って選択される。選択された次のサービスに従って、新たな宛て先がパケットに割り当てられる。

【0015】

本発明の第１の態様の実施形態では、受信されたパケットが伝播している方向は、パケットが受信された入口ポートに従って判定され得る。当該方向は、アップストリーム又はダウンストリームであると判定され得る。

【0016】

別の実施形態では、受信されたパケットをサービスセットに関連付けるステップは、受信されたパケットに適用されるサービスの順序付きリストを割り当てることを含み得る。必要に応じて、受信されたパケットは、判定された方向及びパケットの第１のヘッダフィールドに従って、サービスセットに関連付けられ得る。第１のヘッダフィールドは、送信元アドレス、宛て先アドレス、送信元ポート、宛て先ポート及びプロトコルを含む群から選択され得る。

【0017】

別の実施形態では、受信されたパケットをサービスセットに関連付けるステップは、加入者に関連付けられるアドレスに従って、デフォルトのサービスを受信されたパケットに割り当てることを含み得る。加入者に関連付けられるアドレスは、判定された方向に従って、受信されたパケットの送信元アドレス又は宛て先アドレスから選択され得る。必要に応じて、デフォルトのサービスセットは、受信されたパケットの第２のヘッダフィールドに従って修正され得る。第２のヘッダフィールドは、送信元アドレス、宛て先アドレス、送信元ポート、宛て先ポート及びプロトコルを含む群から選択され得る。

【0018】

別の実施形態では、関連付けられたサービスセット上のパケットの位置は、パケットが受信された入口ポートに従って判定され得る。必要に応じて、上記方法は、受信されたパケットに既に適用されたサービスを除去するために、判定された方向及びパケットの位置に従って、関連付けられたサービスセットを修正するステップを含み得る。

【0019】

別の実施形態では、パケットに新たな宛て先を割り当てるステップは、パケットの宛て先アドレスを書き換えることを含み得る。上記方法は、必要に応じて、割り当てられた新たな宛て先にパケットを転送するステップを含み得る。転送するステップは、割り当てられた新たな宛て先アドレスに関連付けられるポートを選択することと、選択されたポート上でパケットを送信することと、を含み得る。

【0020】

本発明の第２の態様では、プロセッサに動作可能に接続される複数のポートを含むスイッチが提供される。複数のポートの各々は、パケットを受信及び送信するためのものである。プロセッサは、第１のポートで受信されたパケットをサービスセットに関連付けるための、関連付けられたサービスセット上の受信されたパケットの位置を検出するための、検出された位置に従って、関連付けられたサービスセット上の次のサービスを判定するための、複数のポートから第２のポートを選択するための、及び選択された第２のポートで、判定された次のサービスにパケットを送信するためのものである。

【0021】

本発明の第２の態様の実施形態では、選択された第２のポートは、判定された次のサービスに関連付けられ得る。必要に応じて、複数のポートは、サービスノードからダウンストリームに伝播するパケットを受信するための及びサービスノードに対しアップストリームに伝播するパケットを送信するためのアップストリーム対向ポートと、サービスノードからアップストリームに伝播するパケットを受信するための及びサービスノードに対しダウンストリームに伝播するパケットを送信するためのダウンストリーム対向ポートと、を含み得る。

【0022】

別の実施形態では、プロセッサは、受信されたパケットが伝播している方向を第１のポートに従って判定し得る。必要に応じて、プロセッサは、判定された方向及び受信されたパケットの第１のヘッダフィールドに従って、受信されたパケットをサービスセットに関連付け得る。

【0023】

別の実施形態では、プロセッサは、加入者に関連付けられたアドレスに従って、デフォルトのサービスセットを受信されたパケットに割り当て得る。加入者に関連付けられたアドレスは、受信されたパケットの送信元アドレス又は宛て先アドレスのうちの１つであり得る。必要に応じて、プロセッサは、受信されたパケットの第２のヘッダフィールドに従って、デフォルトのサービスセットを修正し得る。

【0024】

別の実施形態では、プロセッサは、第１のポートに従って、関連付けられたサービスセット上の受信されたパケットの位置を判定し得る。

【0025】

別の実施形態では、プロセッサは、判定された次のサービスに従って、受信されたパケットに新たな宛て先を割り当て得る。

【0026】

別の実施形態では、上記スイッチは、関連付けられた方向を有しないパケットを受信するためのトランジットポートをさらに含むことができる。プロセッサは、専らその宛て先アドレスに従って、関連付けられた方向を有しないパケットを転送し得る。

【0027】

本発明の他の態様及び特徴は、添付図面と共に以下の本発明の特定の実施形態の説明を検討することにより、当業者に明らかとなるであろう。

【図面の簡単な説明】

【0028】

添付図面を参照して、ほんの一例として本発明の実施形態がここで説明されるであろう。

【図1】サービスネットワークの実施形態のブロック図であろう。

【図2】例示的なデータパス方法のフローチャートである。

【図3】構成データの例である。

【図4a】例示的な方向テーブルである。

【図4b】例示的なＭＡＣテーブルである。

【図4c】例示的な加入者テーブルである。

【図4d】例示的なアプリケーションテーブルである。

【図4e】例示的なパス状態テーブルである。

【図4f】例示的な次の宛て先テーブルである。

【図5】本発明の実施形態を示すフローチャートである。

【図6】本発明の別の実施形態を示すフローチャートである。

【図7】例としてのスイッチのブロック図である。

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

【0029】

本発明は、サービスのセットを通じてトラフィックを誘導するためのシステム及び方法を対象とする。

【0030】

参照が添付図面に従って付番された、以下の特定の要素に対してなされ得る。以下の議論は、本発明の範囲を限定するものとしてではなく、本来例示的であるものとして取られるべきである。本発明の範囲は、特許請求の範囲において定義され、当業者が理解するように、同等の機能的要素を有する要素を置換することによって修正されることができ、以下に述べる実装の詳細によって限定されるものと考えられるべきではない。

【0031】

本開示のいくつかの実施形態は、OpenFlowプロトコルを使用するものとして議論されるであろうが、他の種類のソフトウェア定義型ネットワーキング（ＳＤＮ：Software Defined Networking）を用いて実装されてもよい。OpenFlowは、ネットワークを介してネットワークスイッチ又はルータの転送プレーンにアクセスできるようにする、通信プロトコルである。OpenFlow1.1は、複数のテーブル及びテーブル間で情報を交換するためのメタデータフィールドをサポートする。本開示は、これらの特徴を利用して、複数ステップでの分類をフラット化する場合に起こる組合せ積（cross-products）を回避することによって、ルールの数を減少させる。

【0032】

サービスネットワークにおいて、事業者は、トラフィッククラスを特定するサービスポリシー、及び各クラスが横断すべきサービスのチェーンを定義することができる。これらのポリシーは、コントローラによってサービスネットワーク内のスイッチ上にプログラムされたルールに変換される。これらのルールは、ポリシーにより特定されたものとして、順序付きのサービスのチェーンを通じてネットワークトラフィックを誘導する。

【0033】

本発明の実施形態は、修正なしで既存の及びサードパーティのサービスの統合をサポートするため、柔軟性を提供する。サービスインスタンスは、事業者によって任意の方法でその位置が特定され（located）、及び連鎖化されることができ、各サービスインスタンスは、複数のサービスチェーンの一部であり得る。加入者及びトラフィックの種類の粒度においてトラフィックを誘導する能力もまた、提供される。

【0034】

ここで議論されるアプローチは、３つの異なる方法で拡張性を提供する。第１に、それは、ルールの組合せ積を回避し、替わりにメタデータと組み合わされる複数のテーブルを用いてテーブル間の情報を通信することによって、スイッチ内に格納されることを要するルールの数を減少させる。第２に、依然として集中制御を維持しつつも、単一の集中型ルータ又はロードバランサを使用する替わりに、スイッチのネットワークに負荷を分散させる。第３に、分類及びヘッダ書き換えといったコストのかかる転送動作が、サービスネットワークの境界（perimeter）にプッシュされ、これは様々な意味で有益であり得る。これらの動作は、サービス間のスイッチホップの数に関わらず、サービス間で一度だけしか実行される必要がない。さらに、ネットワークにおいてトラフィックが複数のスイッチ上に分散され、合計のスループットに対する要求は、ネットワークの境界においてより少ないことが多い。商品（commodity）サーバ上で動作する仮想製品の使用と組み合わされる本発明は、仮想マシンモニタ（virtual machine monitor）上で動作するソフトウェアスイッチの上に全てのコストのかかる動作をプッシュすることを可能とする。

【0035】

転送プレーンは、所与のサービスポリシーのセットをサポートするために必要とされるルールの総数を減少させるために、複数のテーブルを使用するように設計され得る。

【0036】

メタデータフィールド内のサービスパスの符号化は、多数のサービスチェーンをサポートし、サービス毎に複数のインスタンスをサポートするように設計され得る。符号化は、柔軟であることができ、各サービスが独立して拡大縮小されることを可能にする。

【0037】

サービス間のスイッチホップの数に関わらず、分類及びヘッダ書き換えといったコストの掛かる動作がサービス間で一度だけしか行われる必要がないように、ネットワークの組織化が提供され得る。

【0038】

ここに記載されるトラフィック誘導メカニズムは、ネットワークの構成及びそれを横断するトラフィックの種類に関して、以下を前提とする。１）あらゆるサービスは、２つのポートを使用するスイッチに接続される。ルータ及びブリッジと同様に、インラインサービスは定義によってトラフィックにより横断されるので、これは当然の要件である。サービスは、アップストリーム及びダウンストリームトラフィックのはっきりとした概念（notion）を有する必要があり、２つのポートの使用を必要とする。２）サービスネットワークは、各端で単一のゲートウェイにより境界される（bounded）。単一のルータがアクセスネットワークをサービスネットワークに接続し、単一のルータがサービスネットワークをインターネットに接続する。３）全てのサービスがイーサネットレイヤでアドレス可能である。いくつかのサービスはブリッジのように振る舞い、この前提に違反するかもしれない。４）サービスネットワークを通過する全てのトラフィックが加入者トラフィックである。５）ＩＰＳｅｃ（Internet Protocol Security）ゲートウェイ及びＣＤＮ（Content Delivery Network）サーバといった、通信エンドポイントである終端サービスが、ゲートウェイノードの１つに接続される別個のサブネット上に位置される。

【0039】

ここで図１を参照して、例としてのサービスネットワーク１００は、ネットワークの境界における境界スイッチＰＳ１ １０２、ＰＳ２ １０４及びＰＳ３ １０６、並びにネットワークの内部における内部スイッチＳＷ１ １０８を含む。境界スイッチ１０２、１０４、１０６は、OpenFlowスイッチで実装されることができ、一方、内部スイッチ１０８は、OpenFlowスイッチ又は単純なイーサネットスイッチのいずれかで実装されることができる。（サービスノードＳ１ １０９、Ｓ２ １１０、Ｓ３ １１２、Ｓ４ １１４といった）サービス及び（Ｒ１ １１６、Ｒ２ １１８といった）ルータは全てサービスネットワーク１００の境界に接続されている。誘導ネットワーク全体が単一のレイヤ２ドメインである。サービスの複数のインスタンスが存在することができ、各サービスインスタンスは、（潜在的に異なるスイッチ上にあり、）サービスネットワーク１００に接続される、各トラフィック方向のための２つの通信インタフェースを有する。２つより多くのインタフェースを有するサービスもまた、提案されるトラフィック誘導メカニズムによりサポートされる。

【0040】

境界スイッチ１０２、１０４、１０６は、２種類の入力／出力ポート：ノードポート及びトランジットポートを有することができる。サービス及びルータは、ノードポートに接続される。トランジットポートは、他の境界スイッチ又は内部スイッチに接続する。例示的なサービスネットワーク１００では、各境界スイッチ１０２、１０４、１０６は、少なくとも１つのアップストリーム対向ノードポート、少なくとも１つのダウンストリーム対向ノードポート及び少なくとも１つのトランジットポートを有する。各サービスノードＳ１ １０９、Ｓ２ １１０、Ｓ３ １１２及びＳ４ １１４は、境界スイッチに接続される。境界スイッチ１０２、１０４、１０６は、内部スイッチ１０８を介して接続される。

【0041】

１０８のような内部スイッチは、専らトランジットポートで構成され、単純にそれらの宛て先ＭＡＣ（Media Access Control）アドレスに基づいてトラフィックを転送する。したがって、これらのスイッチは、単純なイーサネットスイッチで実装され得る。必要に応じて、内部サービスネットワーク１００においてOpenFlowスイッチを使用してマルチパスサポートといった特徴を有効にすることに利点がある可能性がある。

【0042】

（ルータＲ１ １１６及びＲ２ １１８といった）ゲートウェイノードから入ってくるもの、又はサービスから戻ってくるもののいずれかの着信トラフィックは、常に、境界スイッチを介しノードポートを通過してサービスネットワーク１００に入る。ノードポートを通過して到着するパケットは、それらの割り当てられたサービスパスにおいて、（サービス又はゲートウェイであり得る）次のノードに向けて処理され誘導される。トランジットポートに到着するパケットは、それらの宛て先ＭＡＣアドレスを用いて単に転送される。

【0043】

ルータ１１６は、サービスネットワーク１００をユーザ機器１２０及び１２２に接続することができる。ルータ１１８は、サービスネットワーク１００を内部ネットワーク１２４及び／又はインターネット１２６に接続することができる。

【0044】

高いレベルにおいて、トラフィック誘導は、２つのステップ処理で記述されることができる。第１のステップは、着信パケットを分類し、予め定義されたポリシーに基づいて着信パケットをサービスパスに割り当てる。第２のステップは、その割り当てられたサービスパスに沿った現在の位置に基づいて“次の”サービスにパケットを転送する。この２つのステップのトラフィック誘導処理は、パケットがノードポートに到着するときに任意の２つのノード（サービス又はルータ）間のスイッチの数に関わらず、２つのノード間で１度だけしか実行される必要がない。

【0045】

ここで述べるトラフィック誘導処理は、加入者ベースのポリシー、アプリケーションベースのポリシー、及びフローベースのポリシーの３種類のサービスポリシーをサポートする。これらのポリシーは、事業者により特定されることができ、集中型コントローラ（図１に示さず）により関連するスイッチにプッシュされ得る。

【0046】

加入者ベースのポリシーは、加入者毎に定義されているポリシーである。これらのポリシーは、加入者のＩＰアドレス及び特定の加入者のトラフィック各々が横断すべきサービスのセットを特定する。

【0047】

アプリケーションは、ＹｏｕＴｕｂｅ（登録商標）等のエンドユーザインターネットアプリケーション、ＨＴＴＰ（Hypertext Transfer Protocol）等のトラフィックの種類、又は両者の組み合わせを表す。これらの種類のポリシーは、ＩＰアドレスブロック及び／又はＵＤＰ（User Datagram Protocol）／ＴＣＰ（Transmission Control Protocol）ポートのいずれかの観点で定義される。それらは、アプリケーションごとに特定され、全ての加入者に適用する。アプリケーションベースのポリシーは、加入者ベースのポリシーにおいて指定されたサービスのセットからサービスを追加又は除去することにより、加入者ベースのポリシーを精細化する。

【0048】

フローベースのポリシーは、単一のフロー又はＩＰ５タプル（即ち、送信元ＩＰアドレス、宛て先ＩＰアドレス、プロトコル、送信元ポート、宛て先ポート）に特有のポリシーである。それらは、特定のフローについて加入者及びアプリケーションポリシーを動的に覆すために使用される。これらのポリシーから派生する転送ルールは、コントローラにより動的にプッシュされ、フローの中間でさえ、異なるサービスのセットに向けてフローを効果的に再誘導し得る。

【0049】

さらに、サービスを順序付けするポリシーがサポートされることができる。サービスを順序付けするポリシーは、上述した３つの種類のサービスポリシーとは異なる。それらは、トラフィックとサービスとのマッピングを指定しないが、代わりに、各トラフィックの方向（アップストリーム及びダウンストリーム）に対するサービス間の相対的な順序付けを指定する。コントローラは、これらの相対的な順序付けを全体的な順序付けに変形することができ、この順序付けを用いてサービスポリシーにおいて指定されるサービスのセットを順序付けされたサービスチェーンに変換することができる。

【0050】

本発明の実施形態の誘導メカニズムを実装するデータパスが、テーブル探索の数に関与する。転送の決定は、パケットが受信された入口ポートと同様に、パケットのレイヤ２−レイヤ４コンテンツに基づいてなされることができる。一実施形態では、テーブルのような単一のＴＣＡＭ（Ternary Content Addressable Memory）が、ポリシーベースのルーティングでのように、必要とされる機能を特定するのに用いられ得る。しかしながら、これは、同一テーブル内の加入者、アプリケーション及びポートの組合せ積を伴うであろうから、拡張可能な解決策ではないであろう。パケット方向及び複数のテーブルを用いて、これを複数のステップに分離することが可能であり、それにより各テーブルの線形的な拡張（scaling）という結果がもたらされる。テーブルにわたって機能を分離するための複数の方法がある。それが拡張性の問題を導入しないならば、いくつかのテーブルが結合されてもよい。

【0051】

１つのテーブルからの中間結果は、メタデータを用いて他のテーブルに通信されることができる。メタデータは、後続の探索キーの一部として用いられ、又はさらに修正されることができる。メタデータの１つの重要な部分は、トラフィックの方向である。サービスネットワークを横断する全てのパケットは、アップストリーム又はダウンストリームのいずれかに伝播していると考えられる。誘導ネットワークにおける各ノードポートは、アップストリーム又はダウンストリームのいずれかに対向している。図１に戻って参照すると、ダウンストリーム対向ポート及びアップストリーム対向ポートの両方を有する境界スイッチ１０２、１０４、１０６の例が示されている。ダウンストリーム対向ポートに到着する全てのパケットは、アップストリームに伝播し、その逆もまた同様である。トランジットポートに到着するパケットは、いずれの方向にも伝播し得る。それらの方向は宛て先ＭＡＣアドレスに基づいて知られ、宛て先ＭＡＣアドレスはアップストリーム対向又はダウンストリーム対向サービス及び／又はルータポートのいずれかに相当するであろう。

【0052】

メタデータの別の部分は、適用されるインラインサービスのセットである。このメタデータは、１ビットが可能性のある各サービスに対応する、ビットベクターとして符号化されることができる。より洗練された符号化は、複数のサービスインスタンス上のロードバランシングのような、より高度な特徴を有効にするために用いられることができる。データパスにおいて、このメタデータは、セットされその後修正されることができ、適用されるべき次のサービスを選択するのに最終的に用いられ得る。

【0053】

図２は、本発明の実施形態に係るデータパス機能のハイレベルなフローチャートである。図２は、マルチテーブル探索アプローチを使用して、境界スイッチにより受信されるパケットを処理及び分類するための例としての方法論を示す。パケットに関連付けられるサービスセット及び方向の情報は、セットされ、各テーブル探索の結果に基づいて修正されることができる。

【0054】

パケットはスイッチにより受信され、調べられるべき最初のテーブルは、方向テーブル２０２である。それは、テーブル探索のためのキーとしてパケットが受信された入口ポートを使用し、２つの目的を果たす。第１に、パケットがノードポート又はトランジットポートに到着したかを判定することである。第２に、パケットがノードポートに到着した場合、パケットがどの方向に向かっているかを判定することである。パケットがダウンストリーム対向ポートに到着した場合、それはアップストリームに伝播するものと判定される。パケットがアップストリーム対向ポートに到着した場合、それはダウンストリームに伝播するものと判定される。方向ビットは、ステップ２０４でそれに応じてセットされる。パケットがトランジットポートに到着した場合、それは、方向テーブルに“不一致（miss）”となり、処理は、ＭＡＣテーブル２０６に進むであろう。

【0055】

ＭＡＣテーブル２０６についての探索キーは、パケットの宛て先ＭＡＣアドレスである。このテーブルのコンテンツに基づき、パケットは、別のトランジット若しくはノードポートのいずれかに直接転送２０８され、又は破棄２１０される。

【0056】

方向テーブル２０２において一致、即ち“ヒット”があった場合、調べられるべき次のテーブルは、マイクロフローテーブル２１２である。このテーブル探索のためのキーは、パケットの５タプル（送信元及び宛て先ＩＰアドレス、ＩＰプロトコルフィールド、並びにＴＣＰ／ＵＤＰ送信元及び宛て先ポート）と共に方向ビットである。マイクロフローテーブル２１２は、特定のＴＣＰ／ＵＤＰフローの選択的な動的誘導のために用いられる完全に一致するエントリを含む。マイクロフローテーブル２１２にヒットがある場合、サービスセットは、ステップ２１４でそれに応じてセットされる。

【0057】

マイクロフローテーブル２１２に完全な一致がない場合、調べられるべき次のテーブルは、加入者テーブル２１６である。加入者テーブル２１６は、現在の方向に対する加入者のデフォルトのサービスセットを取得するために使用される。このテーブルに対するキーは、加入者のＩＰアドレスと共に方向ビットである。加入者のＩＰアドレスは、パケットの方向に依存して、送信元又は宛て先ＩＰアドレスフィールドのいずれか１つから生じる。例えば、パケットの方向が“アップストリーム”である場合、加入者のＩＰアドレスは、パケットの送信元ＩＰアドレスであると判定される。このテーブルは、最長プレフィックス一致（ＬＰＭ：longest-prefix match）探索テーブルであり得る。加入者テーブル２１６で“不一致”であれば、デフォルトのアクションは、ステップ２１８でパケットを破棄することである。加入者テーブル２１６に一致がある場合、サービスセットのメタデータが、２２０において加入者のデフォルトのサービスにセットされる。

【0058】

加入者テーブル２１６に続くのはアプリケーションテーブル２２２である。このコンテキストでは、“アプリケーション”は、遠隔通信エンドポイントをＩＰアドレス並びに／又はプロトコル及び／若しくはポート番号により識別されるものとして言及する。それは、任意の静的レイヤ３−レイヤ４のアプリケーションポリシーに従って、加入者のデフォルトのサービスセットを修正するために使用される。加入者テーブル２１６について述べられるのと同様に、アプリケーションＩＰアドレスは、パケットの方向に依存して、パケットの送信元又は宛て先ＩＰアドレスであり得る。ワイルドカード、プレフィックス、及び範囲がこのテーブル探索において許容され得る。この情報に基づいて、特定のサービスが、ステップ２２４でサービスセットから除外され、又は追加され得る。アプリケーションテーブル２２２において不一致である場合、パケットは破棄されず、サービスセットは修正されない。

【0059】

パス状態テーブル２２６が、アプリケーションテーブル２２２又はマイクロフローテーブル２１２の後に続く。パステーブル２２６の目的は、サービスセット内のどのサービスが既にパケットに適用されたか、ひいてはサービスパス上のパケットの位置、を判定することである。パケットは同一の境界スイッチを複数回横断する可能性があるため、これは重要であり、パケットは毎回異なった扱いを受けるべきである。パケットが受信された入口ポートは、この情報を提供するには十分である。パス状態テーブル２２６に達する場合、パケットがサービス又はルータに直接接続されるノードポートに到着したことを意味する。入口ポートは、どのサービスがちょうど適用されたか、及び、もしあれば方向についての情報を提供する。サービスセットの各方向（互いに正反対であるかもしれず、又はそうでないかもしれない）において、サービスの全体的な順序付けが存在する。方向及び前のサービスに基づいて、サービスセットフィールドは、前のサービス及びそれに先行する全ての他のサービスを除外するために２２８で修正される。

【0060】

ノードポートパスに沿った最後のテーブルは、次の宛て先テーブル２３０である。それは、キーとして方向ビット及びサービスセットフィールドを使用する。次の宛て先テーブル２３０は、任意のビットマスク及びルール優先順位を有する、ＴＣＡＭのようなテーブルであり得る。方向ビットに基づいて、その方向における全体的なサービス順序付けに従って、サービスセット内のビットをスキャンすることができる。それが発見する最初の又は最も優先順位が高いサービスが次の宛て先となるであろう。サービスセットが空の場合、方向ビットに依存して、次の宛て先はアップストリーム又はダウンストリームいずれかのルータとなるであろう。次の宛て先は、現在のスイッチ又は別のスイッチに接続され得る。宛て先が異なるスイッチに接続される場合、宛て先ＭＡＣアドレスは、そのサービス又はルータに対応する値にセットされ、パケットは、適当なトランジットポートに送出２３２される。宛て先が直接接続される場合、ＭＡＣアドレスは、必要に応じて更新され、パケットは、対応するノードポートに送出２３２される。

【0061】

表１は、各々に導入されるルールの種類を特定する、上述したテーブルの概要である。

【0062】

【表1】

【0063】

ＭＡＣアドレスは、必要に応じて標準のイーサネットＬＡＮにわたって、遠隔の境界スイッチ上の特定のノードポートにパケットを方向付ける手段として論じられた。インラインサービスボックスと同様、イーサネットコア（存在する場合）と相互運用し、効果的に使用するために、ＭＡＣアドレスを扱うのに特別な注意を払うべきである。

【0064】

その転送タスクに使用する必要があるであろう全てのＭＡＣアドレスを知るために、メカニズムがイーサネットコアネットワークに提供され得る。これを達成する１つの方法は、誘導ネットワークコントローラが、イーサネットコアに接続される境界スイッチのトランジットポートから、全てのサービス及びこれらのトランジットポートを通して到達されるべきルータポートのMACアドレスに対応する送信元ＭＡＣアドレスと共に、特別に作られたイーサネットフレームを定期的に送信させることである。イーサネットスイッチと境界スイッチとの間に複数のリンクを有し、各リンクが異なるサービスに向かうトラフィックを運ぶことが可能である。

【0065】

トランジットポートに送信される他のパケット（即ち、ユーザトラフィック）は、コアイーサネットスイッチのブリッジテーブルを混乱させるべきではない。これは、イーサネットコアに接続される各トランジットポートが、ユーザトラフィックに対し異なる送信元ＭＡＣアドレスを使用するべきであるということを意味する。これは、宛て先として使用されない一意のＭＡＣアドレスであり得る。又は、それが、そのトランジットポートに対応するサービスのうち１つのＭＡＣアドレスであり得る。これは、事実上標準のイーサネットコアがあると仮定する。境界スイッチは、また、互いに直接接続されてもよい。イーサネットコアがない場合、トランジットポートにわたる送信元ＭＡＣアドレスは重要とならないであろう。

【0066】

サービスそれ自体がＭＡＣアドレスについて特別な要求を有するかもしれない。例えば、サービスインタフェースは、ＭＡＣアドレスで構成されることができ、サービスは、それに向かうパケットが正確な宛て先ＭＡＣアドレスを有することを期待できる。この場合、送信元及び宛て先ＭＡＣアドレスは、これに適応するためにセットされなければならない。他方、サービスは、イーサネットレイヤにおいて透過的であることができる。この場合、サービスは、単に１つのポートから他のポートにトラフィックを通過させるかもしれず、あるいは、サービスは一種のＭＡＣラーニングを採用するかもしれない。サービスがＭＡＣラーニングを実行する場合、誘導ネットワークは、アップストリームパケットを１つの送信元ＭＡＣアドレスと共に、ダウンストリームパケットを別の送信元ＭＡＣアドレスと共に送信することにより、それに適応しなければならない。宛て先ＭＡＣアドレスは、望ましくは反対方向において送信元であるであろう。

【0067】

図２に記載されたデータパスは、簡単化の目的のため、加入者データトラフィックに着目されていた。同様に、様々な種類の制御トラフィックを扱う必要があるかもしれない。最低でも、アドレス解決プロトコル（ＡＲＰ：Address Resolution Protocol）がルータポートにおいて、及び恐らく同様にサービスポートにおいてもサポートされるべきである。これらの制御プロトコルをサポートするために、第１のテーブルが、イーサタイプ、ＩＰプロトコルといった様々なレイヤ２−レイヤ４フィールドにおける一致、及びコントローラに対しパケットを捕捉する能力を許容するために強化されることができる。

【0068】

代替的なシナリオでは、２人の加入者が互いに通信することができる。この場合、特にセキュリティ関連のサービスが存在する場合、各加入者のトラフィックの全ての関連サービスを適用することが依然として必要である。ダウンストリームルータは、この状況で誘導するネットワークを迂回するべきではない。これが起こる場合、トラフィックは、２つのエンドポイント間で２回、１度はアップストリーム、１度はダウンストリームに誘導ネットワークを横断するであろう。アップストリーム方向で、ある加入者のサービスが適用されるであろう。ダウンストリーム方向で、他の加入者のサービスが適用されるであろう。これは、ここで述べるメカニズムにおいて説明される。アップストリームルータは、トラフィックを誘導ネットワークに戻すことを期待され得る。

【0069】

いくつかのサービスノードが、同一のパケットを２回見る必要はないかもしれない。さらに、（例えば、サービスがルーティングを実行する場合、）サービスの両側で加入者ＩＰアドレスを見ることに関連する問題がある恐れがある。アプリケーションテーブルにおけるルールは、加入者間のトラフィックについてサービスを１方向に迂回させるために、実装されることができる。

【0070】

OpenFlow1.1プロトコル転送モデルを使用する図２の例示的なデータバスの実装は、当業者により容易に理解されるであろう。メタデータの項目（方向及びサービスセット）は、OpenFlowの６４ビットのメタデータフィールド内に符号化される。これは、方向について１ビットを必要とし、最大で６３の異なるサービスを許容するサービスセットを符号化するために６３ビットまで残す。OpenFlow1.1は、次の等式に基づき、任意のマスクを使用してメタデータフィールド上の一致をサポートし、メタデータフィールドの更新をサポートする：meta＝（meta＆〜mask）｜（value＆mask）。この値（value）及びマスク（mask）は、任意の６４ビットの数であり得る。

【0071】

表２は、上述した例としてのOpenFlow1.1スイッチテーブルアクションの概要である。

【0072】

【表2】

【0073】

図２のフローチャートの加入者テーブルは、パケットの方向に基づいて加入者のＩＰアドレスを抽出したことに留意すべきである。表２のOpenFlow実装例では、送信元ＩＰアドレス及び宛て先ＩＰアドレスの両方が、方向ビットを有するメタデータフィールドと共に、照合フィールドとして代わりに含まれる。このテーブルに導入されるルールは、メタデータフィールド内の方向ビットに対応して、ワイルドカードとして送信元又は宛て先ＩＰアドレスのいずれか、及び全てのマスクされた他のメタデータビットを有するであろう。

【0074】

加入者テーブル内に記載されている同一のコンセプトが、アプリケーションテーブルにも同様に適用される。OpenFlow1.1は、ポートの範囲又はマスクをサポートしないため、誘導メカニズムの現在の実装は、送信元及び／又は宛て先ポートについては完全一致に限定される。

【0075】

本開示の実施形態をさらに示すために、図１のトポロジーに基づく例について説明する。図３は、境界スイッチＰＳ２ １０４のデータパスについてのテーブル全体を導き出すために、図１のトポロジーと組み合わせて使用される構成情報を含む構成データ３００の例を示す。構成データ３００は、加入者情報、サービス情報、ルータ情報、アプリケーション情報及び全体的なサービス順序付けを含む。テーブルの大部分が、構成が変わる場合にのみ変化するという意味で、ほとんど固定である。

【0076】

図４ａ−４ｆは、図３の構成情報に従って、図１のトポロジー内の境界スイッチ１０４に投入され格納されるであろうテーブルエントリの例を示す。この例で明確に示されていない１つのテーブルは、マイクロフローテーブルである。これは、マイクロフロー情報が、静的な構成からではなくむしろ動的なフロー分析から得られるものだからである。特定のマイクロフローが再誘導されるべきであると、動的ポリシー（即ち、レイヤ５−レイヤ７の情報に基づく）が決定づける場合、対応するマイクロフロールールを関連するスイッチに導入するであろう。例では、メタデータフィールドが各テーブルについてどのように照合され又は更新されるかが提示されるであろう。これらの例は、方向を表す最も重要なビットを有する５ビットのメタデータフィールド（１方向ビット、４サービスビット）に基づく。

【0077】

図４ａは、方向テーブル４１０の例を示す。方向テーブル４１０は列４１２を含み、列４１２は各々入口ポート４１２ａ及び関連付けられたアクション４１２ｂを含む。パケットの方向（アップストリーム又はダウンストリーム）は、パケットが到着する入口ポートにより判定される。例えば、入口ポート１で受信されるパケットについて、方向メタデータは、列４１２’に示されるように“ダウンストリーム”にセットされる。この実施形態では、値１がアップストリーム方向を表し、値０がダウンストリーム方向を表す。２番目のルールでは、列４１２”において、メタデータフィールドは以下のように更新されるであろう。

【0078】

【数1】

【0079】

図４ｂは、ＭＡＣテーブル４２０の例を示す。ＭＡＣテーブル４２０は、列４２２を含み、列４２２は各々宛て先ＭＡＣアドレス４２２ａ及び関連付けられたアクション４２２ｂを含む。ＭＡＣテーブル４２０についてのアクションは、対応する宛て先ＭＡＣアドレスに基づいて、送信元ＭＡＣアドレス（smac）をセットすること、及びパケットを送信するポートを選択することである。

【0080】

図４ｃは、加入者テーブル４３０の例である。加入者テーブル４３０は、列４３２を含み、列４３２は各々方向４３２ａ、ＩＰアドレス４３２ｂ、及びアクション４３２ｃを含む。加入者テーブルについてのアクションは、方向ビットは修正されないままで、加入者のＩＰアドレスに対し適切なサービスセットに基づいて、メタデータフィールド内のサービスビットをセットする。１番目のルールについて、Ｓ１及びＳ３についてのサービスビットは、以下のようにセットされる。

【0081】

【数2】

【0082】

図４ｄは、アプリケーションテーブル４４０の例である。アプリケーションテーブル４４０は、列４４２を含み、列４４２は各々方向４４２ａ、ＩＰアドレス４４２ｂ、プロトコル４４２ｃ、ポート４４２ｄ、及び関連付けられたアクション４４２ｅを含む。アプリケーションテーブルについてのアクションは、このテーブルで一致がある場合、サービスビットを更新又は修正することである。サービスビットのサブセットは、セットされているか又はクリアされているかのいずれかである。方向ビットは修正されない。１番目のルールについて、Ｓ２についてのビットはセットされ、Ｓ３についてのビットはクリアされる。追加又は除去されているサービスに対応するビットは、マスクフィールド内でセットされる。値フィールドは、これらのサービスについて新たな状態（存在する又はしない）を含む。

【0083】

【数3】

【0084】

図４ｅは、パス状態テーブル４５０の例である。パス状態テーブル４５０は、列４５２を含み、列４５２は各々入口ポート４５２ａ及び関連付けられたアクション４５２ｂを含む。パス状態テーブルについてのアクションは、割り当てられたサービスセット内の前のサービス及びそれに先行する全てのサービスに対応するビットをクリアすることである。３番目のルールについて、メタデータフィールドは、以下のように更新されるであろう。

【0085】

【数4】

【0086】

図４ｆは、次の宛て先テーブル４６０である。次の宛て先テーブル４６０は、列４６２を含み、列４６２は各々方向４６２ａ、サービスセット４６２ｂ及び関連付けられたアクション４６２ｃを含む。いずれの前のサービスに対応するビットもパス状態テーブルにおいてクリアされており、次の宛て先テーブルにおける探索では、チェーン内の次のサービスを判定するために最上位の残りのビットを見つける。例として、最初の３つのルールについてのメタデータフィールドにおける一致は、次のようになるであろう（Ｘにセットされたビットは、マッチングの間マスクされている）。

【0087】

【数5】

【0088】

上記例に対するいくつかの可能性のある拡張についてここで論じる。単一の物理サービスミドルボックスが、必要とされるスループットを供給するのに不十分である場合、そのサービスの複数のインスタンスが、誘導ネットワークに接続されることができ、別個のロードバランサの必要性なしで誘導ネットワークがそれらの間でトラフィックを分散させることができる。これは、説明した転送プレーンのメカニズムを修正することなく行われ得る。

【0089】

加入者テーブル４３０及びマイクロフローテーブル（図示せず）は、サービスセットのメタデータをコントローラ指定の値にセットする能力を有し得る。アプリケーションテーブル４４０及びパス状態テーブル４５０は、サービスセットのメタデータ中の選択コントローラ指定のビットを修正する能力を有し得る。次の宛て先テーブル４６０は、サービスセットのメタデータ内の選択コントローラ指定のビットをマスクし、照合する能力を有し得る。したがって、コントローラは、これらのビットのフォーマットをいじることができる。簡単な場合では、説明したように、１ビットが（それが適用されるべきか否かを示す）サービスを表し、各サービスのインスタンスが１つだけ存在する。この符号化は、選択サービスがメタデータに含まれるインスタンス識別子を追加的に有することができるように拡張されることができる。ｎビットがそのような識別子に割り当てられる場合、２^ｎまでのサービスインスタンスが表され得る。利用可能な固定数のビットで、これはサービスの最大数とサービスごとのインスタンスの数との間のトレードオフである。各サービスは、インスタンス識別子のために異なるビット数を使用することができる。

【0090】

例示的な符号化スキームでは、メタデータフィールドは６４ビット幅である。１ビットは、アップストリーム又はダウンストリームトラフィックを示す方向ビットである。３ビットは未使用である。サービスチェーンは、１３の異なるサービスのセットからなる。サービスのうち２つは、８ビット（１適用ビット、７ビットはインスタンス識別子として使用される）を使用して表され、サービス毎に１２８個までのインスタンスを許容する。残りの１１個のサービスは、４ビット（１適用ビット、３インスタンス識別子ビット）を使用して表され、サービス毎に８個までのインスタンスを許容する。

【0091】

インスタンス識別子は、加入者テーブル４３０内のデフォルトのサービスセットと共にセットされることができる。一度セットされると、インスタンス識別子ビットは、後続のアプリケーションテーブル４４０によって修正されない。アプリケーションテーブル４４０は、サービスが適用されるべきかを示すフラグビットを修正するだけである。これは、サービスが加入者のデフォルトのサービスセットの一部でない場合でも、加入者の粒度においてロードバランシングを可能にする。多数の加入者を仮定すると、このロードバランシングの粒度は十分であろうことが期待される。

【0092】

ここで述べたようなサービスパスの符号化は、２つの潜在的な制限に対処するために拡大され得る。第１に、サービスの順序付けは、各方向（アップストリーム対ダウンストリーム）に課され得る。所与の方向について、以下の順序付けの制約Ａ→Ｂ及びＢ→Ｃが定義されている場合、順序付けの制約Ｃ→Ａは却下されるであろう。第２に、サポートされるサービスの総数は、サービスパス内で符号化され得るサービスの最大数に制限され得る。

【0093】

これらの２つの制限は、パスグループの選択肢を導入することにより緩和され得る。方向ビットは、各方向における複数グループのサービスパスをサポートするために、追加ビットで強化され得る。例えば、７個の追加ビットを使用することにより、各方向において１２８個までのパスグループを定義することができるようになる。異なるセットのサービス及び順序付けの制約は、各パスグループについて定義され得る。所与のサービスのインスタンスを表すのに使用されるビット数は、さらなる柔軟性を提供するパスグループ間で変えることもできる。

【0094】

以前に指定された順序付けの制約に起因して許容されないサービスパスを定義するために、第１の制限に対処する新たなパスグループが、それ自身の順序付け制約のセットで定義され得る。パスグループの使用は、サービスパスの一部であり得るサービスの最大数を変更しないが、サービスのプールのサイズを増加させるであろう。当該サービスのプールからサービスが１つ以上のサービスパスの一部であるように選択される。パスグループを使用することにより、状態テーブル及び宛て先テーブルのサイズを増加させることができる。これらのテーブルの両方が、定義されるパスグループの数を直線的に増大させるであろう。

【0095】

ここで説明された誘導メカニズムは、加入者毎に２つのルールを使用し、潜在的に大きな加入者ポリシールールテーブルをもたらす結果となる。ＩＰアドレスが、加入者の予め定義されたサービスセットに基づいて加入者に割り当てられた場合、このテーブルのサイズは低減され得る。このアプローチを用いると、加入者毎のルールは、サービスセット毎のルールにより置き換えられ、ルールの数を大いに低減する。この種のソリューションは、多くの加入者が動的ＩＰアドレスを割り当てられるネットワークにおいて、潜在的に展開可能であるかもしれない。

【0096】

ルータは、そのルーティングテーブルを使用してネクストホップを判定し、それに応じて宛て先ＭＡＣアドレスをセットするであろう。サービスネットワークは、サービスに向かってパケットを誘導するためにＭＡＣアドレスを書き換え、それにより宛て先ゲートウェイノードが上書きされ、したがって透過的なレイヤ２セグメントとして扱われることができない。各端において単一のルータの場合、既知のトラフィック方向が宛て先ルータを識別するのに十分であるからこれは問題ではない。複数のルータの場合、適切なルータにトラフィックを方向付けるために何らかのメカニズムが必要とされる。

【0097】

誘導ネットワークは、本質的にはルータとして扱われ得る。接続されたルータは、その後、誘導ネットワークにトラフィックを方向付けるルートを有するであろう。そして誘導ネットワークは、そこからトラフィックを方向付けることができる。加入者トラフィックについて、既存の誘導メカニズムは、単一のアップストリーム及び単一のダウンストリームルータより多くを許容するために用いられ得る。これは、複数のサービスインスタンスのコンセプトと同様であるとみなすことができる。ルータ識別子（サービスインスタンス識別子と同様）は、（ダウンストリームトラフィックについての）加入者テーブル４３０、（アップストリームトラフィックについての）アプリケーションテーブル４４０において、又は（アップストリーム及びダウンストリームトラフィックについての）マイクロフローテーブルにおいてさえも、セットされることができる。これは、メタデータ符号化の問題であり、いくつかの数のビットがこれに割り当てられ得る。各ルータは、依然として加入者トラフィックのためのアップストリーム又はダウンストリームルータであると考えられる。あるいは、ルーティング情報を含む別のテーブルが追加され得る。

【0098】

ここに記載される例としての実施形態について、誘導ネットワークにより転送される全てのトラフィックは、加入者トラフィックであると仮定されている。非加入者トラフィックについて、我々は誘導ネットワークを単純なルータとして扱うことができる。加入者テーブル４３０において見つからないパケットを破棄する替わりに、従来の宛て先ＩＰベースの転送を行う通常のルートテーブルにそれらは送信されてもよい。ルート探索に基づき、同一のメカニズムが、ローカルノードポートに出力されるため、又はレイヤ２コアネットワークをわたって遠隔のノードポートにそれを送信するために使用され得る。非加入者トラフィックは、いかなるインラインサービスも横断しないであろう。

【0099】

スイッチポートは物理ポートであると仮定されているが、ＶＬＡＮタグ及びサービス上の仮想インタフェースを使用して、仮想ポートを同様にサポートすることもできる。仮想ポートは、必要とされる物理ポートの数を低減するために使用されることができる。

【0100】

ここに記載した誘導メカニズムは、複数のテーブル、及び複数テーブルを通じてパケットを処理するときに情報を交換するのに使用されることができるメタデータフィールドをサポートするプロトコルを用いて実装され得る。誘導メカニズムは、各スイッチに格納されるルールの総数を低減するため、及び高価なＴＣＡＭ技術に頼ることを可能な限り回避するためにこれらの２つの特徴を活用する。誘導メカニズムは、加入者テーブル及びマイクロフローテーブルといった大きなテーブルを有する可能性があるが、これらは、ＲＡＭ内に効果的に実装され得る最長プレフィックス一致及び完全一致テーブルである。単一のテーブルのみサポートする代替的な実装で、入力ポート、加入者及びアプリケーションポリシーの全ての有効な組み合わせが、個々のルールとして符号化されなければならない。このルールの組合せ積は、非常に大きなテーブルをもたらす結果となるであろう。また、これらのルールはワイルドカード及びマスクを含むことから、このテーブルは拡張性及び／又はパフォーマンスの問題を抱えることとなるであろう。

【0101】

代替的なアプローチは、当業者によって容易に理解されるように、トラフィックを誘導するために実装され得る。１つのアプローチは、サービスチェーン又は訪れるべきサービスのセットを識別する追加情報を各パケットにタグ付けすることである。この追加情報は、サービスパス全体を識別するフラットラベル又は、訪れるべきサービスを各ラベルが識別するラベルのスタック、のいずれかであり得る。

【0102】

フラットラベルアプローチでは、パケットが着信ポートとラベルの値に基づいて誘導される。パケットは、最初にサービスネットワークに入るときに一度分類される。仮想ローカルエリアネットワーク（ＶＬＡＮ）タグは、フラットラベルとして使用することができるが、このアプローチは問題となる恐れがある。多くのサービスは、レイヤ２ヘッダを削除（strip）してＶＬＡＮタグを廃棄し、その後再分類を推し進める。ＶＬＡＮタグは、１２ビット幅であり、サービスパスの数を４０９６に制限する。一旦方向を考慮し、複数のサービスインスタンスをサポートする必要を考慮すると、この数は、制限になる可能性がある。

【0103】

スタックラベルアプローチでは、訪れるべき順序付きサービスのセットが、ラベルのスタックとして記述される。スタックの一番上のラベルは、訪れるべき次のサービスを識別し、各サービスの後、このラベルはスタックから取り出される。一旦そのスタックが空になると、パケットはネットワークを出る。このアプローチは、ＭＰＬＳ（Multiprotocol Label Switching）ラベルを使用して実装され得る。レイヤ２ヘッダを削除する（stripping away）サービスの問題に加えて、多くのサービスは、ＭＰＬＳヘッダを有するパケットをハンドリングすることができない恐れがある。

【0104】

別の代替的な実施形態では、パケットは、境界スイッチで一度だけそれを行う代わりに、サービス間のすべてのスイッチホップで再分類されることができる。このアプローチは、宛て先ＭＡＣアドレスの書き換えを必要としないが、全てのスイッチホップでの再分類を必要とし、内部ネットワーク内の単純な転送メカニズムを使用することを妨げ、この場合合計の帯域幅の要件は境界においてよりも高い。このアプローチは、また、同一のサービスパス内で複数回横断されるリンクのための（例えば、トンネルを使用するような）別個のラベリングメカニズムの使用を必要とする。

【0105】

図５は、本発明の方法を示すフローチャートである。パケットがネットワーク内の境界スイッチにより受信されると、方法がステップ５００において開始される。パケットはステップ５１０で分類され、分類動作に従ってサービスチェーンが受信されたパケットに割り当てられる。割り当てられたサービスチェーン上の受信されたパケットの位置は、５２０において判定される。サービスチェーン上の位置は、パケットが受信されたポートに従って判定されることができる。受信されたパケットの方向も、パケットが受信されたポートに基づいて必要に応じて判断されることができる。５３０で、受信されたパケットの判定された位置に従って、パケットは割り当てられたサービスチェーン上の次のサービスへ転送される。次のサービスは、判定されたサービスチェーン上の位置に加えて判定された方向に従い、必要に応じて判定され得る。ステップ５３０は、実行されるべき次のサービスに従って、新たな宛て先アドレスを受信されたパケットに割り当てることを含み得る。パケットは、次のサービスに関連付けられたポートを選択することにより、次のサービスに転送されることができる。

【0106】

図６は、本発明の別の実施形態を示すフローチャートである。ステップ６００においてパケットを受信することにより処理が開始する。パケットが伝播する方向が６１０で判定される。受信されたパケットが伝播する方向はアップストリーム又はダウンストリームであることができ、パケットが受信された入口ポートに従って判定され得る。

【0107】

６２０で、受信されたパケットがサービスセットに関連付けられる。パケットをサービスセットに関連付けることは、パケットの少なくとも１つのヘッダフィールドに従って、パケットに適用されるべきサービスの順序付きリストを割り当てることを含み得る。少なくとも１つのヘッダフィールドは、送信元アドレス、宛て先アドレス、送信元ポート、宛て先ポート又はプロトコルを含む群から選択され得る。サービスセットも、判定されたパケットが向かう方向に従って割り当てられ得る。割り当てられたサービスの順序付きリストは、メタデータとして受信されたパケットに添付され得る。

【0108】

デフォルトのサービスセットは、加入者に関連付けられたアドレスに従って、パケットに関連付けられ得る。加入者アドレスは、判定された方向に従って、受信されたパケットの送信元アドレス又は宛て先アドレスとして識別され得る。デフォルトのサービスセットは、受信されたパケットの少なくとも１つのヘッダフィールドに従って、必要に応じて修正されることができる。

【0109】

ステップ６３０で、関連付けられたサービスセット上のパケットの位置が判定される。サービスセット上のパケットの位置は、パケットが受信された入口ポートに従って判定され得る。最後に適用されたサービス及び前に適用された全てのサービスの両方が、サービスセット内のパケットの現在位置及びパケットが向かっている方向に基づいて判定され得る。関連付けられたサービスセット上のパケットに適用される次のサービスがステップ６４０で選択される。次のサービスは、判定されたパケットの方向及び位置に従って選択される。関連付けられたサービスセットは、パケットに既に適用されたサービスを除去するために、判定されたパケットの方向及び位置に従って必要に応じて修正されることができる。

【0110】

ステップ６５０で、選択された次のサービスに従って、新たな宛て先がパケットに割り当てられる。パケットに新たな宛て先を割り当てることは、パケットに関連付けられた宛て先アドレスを書き換えることを含み得る。必要に応じて、６６０で、パケットは新たな宛て先に転送される。パケットを転送するステップは、新たな宛て先に関連付けられるポートを選択すること、及び選択された次のサービスに当該ポートを通じてパケットを送信することを含み得る。

【0111】

図７は、本発明の実施形態に係るスイッチ７００のブロック図である。スイッチ７００は、サービスネットワーク内の境界スイッチであり、ここで述べられた機能性を実装することができる。スイッチ７００は、パケットを送信及び受信するための複数の入力／出力ポートを含む。複数のポートは、第１のポート７０２及び第２のポート７０４を含む。第１のポート７０２及び第２のポート７０４は、単一の物理通信インターフェースとして実装されてもよい。プロセッサ７０６は、入力ポート７０２、出力ポート及びメモリ又はデータリポジトリ７０８に動作可能に接続される。メモリ７０８は、スイッチ７００の内部又は外部にあることができ、プロセッサ７０６によりアクセス可能である。

【0112】

プロセッサ７０６は、第１のポート７０２で受信されたパケットをサービスセットと関連付けるように構成される。プロセッサ７０６は、受信されたパケットの関連付けられたサービスセット上の位置を検出し、検出された位置に従って、関連付けられたサービスセット上の次のサービスを判定する。プロセッサ７０６は、判定された次のサービスにパケットを送信するための第２のポート７０４を選択することができる。第２のポート７０４は、次のサービスと関連付けられることができ、複数のポートから選択される。

【0113】

複数のポートは、ダウンストリームに伝播するパケットをサービスノードに送信し、サービスノードからアップストリームに伝播するパケットを受信するために指定された少なくとも１つのポートを含み得る。少なくとも１つの他のポートは、アップストリームに伝播するパケットを同一のサービスノードに送信し、同一のサービスノードからダウンストリームに伝播するパケットを受信するために指定されることができる。

【0114】

プロセッサ７０６は、パケットが受信された第１のポート７０２に従って、受信されたパケットが向かっている方向（アップストリーム又はダウンストリーム）を判定することができる。プロセッサ７０６は、判定されたパケットの方向及びヘッダフィールドに基づいて、受信されたパケットをサービスセットに関連付けることができる。

【0115】

サービスセットに関連付けられたパケットの一部として、プロセッサ７０６は、加入者に関連付けられたアドレスに従って、デフォルトのサービスセットをパケットに割り当てることができる。加入者は、パケットが向かっている方向に依存して、パケットの送信元アドレス又は宛て先アドレスのいずれかにより識別され得る。プロセッサ７０６は、さらに、パケットの少なくとも１つの他のヘッダフィールドに従って、デフォルトのサービスセットを修正することができる。

【0116】

プロセッサ７０６は、パケットが受信された第１のポート７０２に基づいて、関連付けられたサービスセット上の受信されたパケットの位置を判定することができる。プロセッサ７０６は、判定された次のサービスに従って、受信されたパケットに新たな宛て先を割り当てることができる。

【0117】

スイッチ７００は、また、アップストリーム又はダウンストリーム方向と関係しないパケットを受信するためのトランジットポートを必要に応じて含み得る。プロセッサ７０６は、専ら宛て先アドレスに従ってトランジットポートで受信されたパケットを転送する。スイッチ７００は１つ又は数個のトランジットポートを含み得る。トランジットポートで受信されたパケットは、複数のポート（第１のポート７０２及び第２のポート７０４を含む）又はトランジットポートを介して、それらの宛て先に転送され得る。

【0118】

本発明の実施形態は、機械可読媒体（コンピュータ可読媒体、プロセッサ可読媒体又はその中に具体化されたコンピュータ可読プログラムコードを有するコンピュータ使用可能媒体とも呼ばれる）内に格納されるソフトウェア製品として表され得る。機械可読媒体は、ディスケット、ＣＤ−ＲＯＭ（compact disk read only memory）、ＤＶＤ−ＲＯＭ（digital versatile disc read only memory）、（揮発性又は不揮発性）メモリ装置又は類似の記憶メカニズムを含む、磁気、光学又は電気記憶媒体を含む任意の適切な有形媒体であり得る。機械可読媒体は、実行されたときに本発明の実施形態に係る方法におけるステップをプロセッサに実行させる、命令、コードシーケンス、構成情報又は他のデータの様々な集合を含み得る。当業者は、記載された発明を実装するのに必要な他の命令及び動作もまた、機械可読媒体上に格納され得ることを理解するであろう。機械可読媒体から実行されるソフトウェアは、記載されたタスクを実行するための回路とインタフェースし得る。

【0119】

上述した本発明の実施形態は、例としてのみであることが意図される。変更、修正及び変形は、専ら添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく当業者によって特定の実施形態にもたらされ得る。

【図1】

【図2】

【図3】

【図4a】

【図4b】

【図4c】

【図4d】

【図4e】

【図4f】

【図5】

【図6】

【図7】