Junos OS を搭載したデバイスでの OpenFlow フローとフィルターについて
OpenFlow フローは、さまざまな要素によって定義されます。 表 1 は、OpenFlow v1.0 および OpenFlow v1.3.1 でのフロー要素のサポートの概要を示しています。OpenFlow バージョンでサポートされている要素は、フローを一意に識別します。
フロー要素 |
OpenFlow v1.0 でサポートされていますか? |
OpenFlow v1.3.1 でサポートされていますか? |
---|---|---|
一致条件 |
はい |
はい |
一連のアクション |
はい |
いいえ |
フロー指示 |
いいえ |
はい |
フロー優先度 |
はい |
はい |
フロー タイムアウト情報 |
はい |
はい |
フロークッキーとクッキーマスク |
いいえ |
はい |
フローエントリは、完全一致を必要としないフィールドのワイルドカード一致条件を指定します。フロー エントリーにすべての一致条件のワイルドカードが含まれている場合、すべてのパケットがそのフロー エントリーに一致します。
OpenFlow フローベースの転送を実装するには、Junos OS を実行するデバイスでフィルターを使用します。OpenFlow に参加するように設定された論理インターフェイスごとに、1 つのフィルターが作成され、入力方向の論理インターフェイスに適用されます。フィルター名は、論理ユニット番号を含むインターフェイス名と、内部的に割り当てられた仮想スイッチ ID(ge-1/1/0.0_0 など)を連結したものです。
自動生成された OpenFlow フィルター名またはフィルター用語名と競合するフィルター名またはフィルター用語名を手動で設定した場合、Junos OS は 中にエラー commit check
を生成しません。競合がある場合、コミットは成功しますが、フィルターまたはフィルター用語の 1 つは、受信した順序に基づいて拒否されます。
フィルターは、一致条件を持つ1つ以上の項、アクション(OpenFlow v1.0の場合)または命令(OpenFlow v1.3.1の場合)で構成されます。OpenFlow フローはフィルター用語にマップされ、フローの追加、削除、および変更に対する OpenFlow コントローラーのリクエストは、フィルター内の用語の追加、削除、または変更につながります。OpenFlow コントローラがフロー変更リクエストを送信すると、イングレス ポートのフロー エントリ一致条件によって、更新される論理インターフェイス フィルタが決まります。OpenFlow フローの優先順位によって、フィルター内の用語の順序が決まります。ここで、優先度の高い用語は優先度の低い用語の上にインストールされます。フロー一致条件はフィルター項目一致条件にマッピングされ、フローアクションまたは命令はフィルター項目 then
ステートメントにマッピングされます。フローアクションまたは命令によっては、 then
ステートメントにパケットをネクストホップまたはOpenFlowコントローラーに転送するアクション、またはパケットを破棄するアクションが含まれる場合があります。
OpenFlow コントローラがフローを変更するリクエストを送信したが、条件に一致するフローエントリがない場合、OpenFlow v1.0 はフローテーブルにフローのエントリを追加します。ただし、同じ状況では、OpenFlow v1.3.1 はこのフローをフローテーブルに追加せず、エラーもログに記録されません。
各 OpenFlow フロー エントリは、フィルター項目に対応しています。ただし、各フローエントリーは、イングレスポートの一致条件に応じて、1つ以上のフィルターの項にマッピングされる場合があります。イングレスポートがワイルドカード一致の場合、フローエントリは、そのOpenFlow仮想スイッチのすべてのインターフェイスフィルターに用語として表示されます。たとえば、OpenFlow コントローラが、イングレス ポート フィールドのワイルドカード一致で新しいフロー エントリを追加する要求を送信するとします。この場合、フローは、その仮想スイッチの下で設定されたすべての OpenFlow 論理インターフェイスの新しいフィルター項目として追加されます。
Junos OS を実行するデバイスは、フローを変更および削除するためのストリクトおよび非ストリクト両方のフロー mod コマンドをサポートしています。OpenFlow コントローラーの厳密な変更と厳密な削除のフロー mod リクエストは、ワイルドカードと優先度を含むすべてのヘッダー フィールドの説明と完全に一致するフローのみを変更または削除します。厳密でない変更および削除フローmodリクエストは、リクエストと完全に一致するフロー、またはリクエストよりも具体的なフローを変更または削除します。
既に説明した機能に加えて、OpenFlow v1.3.1 はフロークッキーもサポートしています。この識別子は、フローがフローテーブルにインストールされているときに OpenFlow コントローラが指定できる識別子です。この Cookie を使用すると、OpenFlow はフローの変更操作と削除操作用に選択されたフローをフィルター処理できます。
どのフロー エントリ drop
でも一致しないパケットに対するデフォルト アクションは、パケットを破棄する 、または packet-in
パケットを受け取ってコントローラに転送する のいずれかに設定できます。既定のアクションは OpenFlow 仮想スイッチに固有であり、その仮想スイッチに関連付けられているすべてのフィルターで同じです。デフォルト アクションを明示的に設定しない場合、デフォルトは packet-in
です。
論理インターフェイスが利用できなくなった場合、その論理インターフェイスに関連付けられているフィルターはパケット転送エンジンから削除されます。フィルターは削除されますが、ルーティング エンジンは、OpenFlow タイマーに応答してフローがパージされるまで、論理インターフェイスに一致するフローをイングレス ポートとして保持します。OpenFlow タイマーの詳細については、 Junos OS を実行するデバイスでの OpenFlow フロー入力タイマーについてを参照してください。フローがパージされる前に論理インターフェイスが使用可能になった場合、その時点でルーティング エンジンが保持していたフィルターとフローは、ハードウェアに再インストールされます。
同様に、論理インターフェイスが利用できなくなった場合、その論理インターフェイスをアクション セットまたは命令内の唯一のアクティブなエグレス インターフェイスとするフローは無効と見なされます。無効なフローはパケット転送エンジンから削除されますが、さまざまなOpenFlowタイマーに応答してフローがパージされるまで、ルーティングエンジンによって無期限に保持されます。または、アクション セットまたは命令に複数のアクティブなエグレス インターフェイスの 1 つとして論理インターフェイスを含むフローは、引き続き有効です。その場合、フローはパケット転送エンジンに残りますが、マルチキャストネクストホップが更新され、有効なエグレスインターフェイスとしてその論理インターフェイスが削除されます。