RFC7209 Ethernet VPN(EVPN)の要件

はじめに

この文書は RFC7209 Requirements for Ethernet VPN (EVPN) の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスが欠けた文章になっている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

目次

Abstract

イーサネットL2VPNサービスが広く採用されてきて、この技術のための(データセンター相互接続などの)新しいアプリケーションたちの出現によって、現在のVirtual Private LAN Service (VPLS)ソリューションで難なく解決できるものではない、いくつもの要件が積み重なってきています。特にAll-Activeで転送可能なマルチホーミングがサポートされておらず、そのため複数宛先トラフィックを最適化するためのMultipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs)を実現するソリューションが存在しません。さらにVPLSのプロビジョニングはBGPベースの自動発見の文脈においてさえ、ネットワーク事業者がアクセスの設定に加えて様々なパラメータを指定する必要があります。この文書では上記の問題を解決するEtherent VPN (EVPN)ソリューションの要件について明確にします。

1. はじめに

Virtual Private LAN Service (VPLS)はRFC4664、RFC4671、RFC4672で定義されている実績があり広く導入された技術です。しかし既存のソリューションには冗長性やマルチキャストの最適化やプロビジョニングの簡便性の面で多くの制約があります。さらに新しいアプリケーションによってEthernet Tree (E-Tree)やVirtual Private Wire Service (VPWS)といった他のL2VPNサービスへの新しい要件がいくつか生まれています。

マルチホーミングの分野については、現在のVPLSは例えばVPLS-BG-MHに記載されているようにSingle-Active冗長モード(3節で定義します)のマルチホーミングだけをサポートすることができます。All-Active冗長モード(3節で定義します)による柔軟なマルチホーミングは現在のVPLSソリューションではサポートできません。

マルチキャスト最適化の分野については、RFC7117がVPLSと結合したときにどのようにマルチキャストLSPを使用することができるかについて記述しています。しかしこのソリューションはPoint-to-Multipoint (P2MP) LSPに限定されており、Multipoint-to-Multipoint (MP2MP) LSPをVPLSで実現するソリューションについては定義されていません。

プロビジョニングの簡便性の分野については、現在のVPLSはBGPベースのサービス自動発見(RFC4761、RFC6074)に頼った片側のプロビジョニングの仕組みを提供しています。しかしこれではアクセス側のイーサネットの設定に加えてネットワーク側のパラメータをいくつかのパラメータを事業者が設定する必要があります。

データセンター相互接続の分野においては。VLAN bundleとVLAN-basedサービスインターフェイスを組み合わせたような新しいサービスインターフェイスのタイプへの要求がアプリケーション側から高まっています。これらは「VLAN-Aware Bundling」サービスインターフェイスと呼ばれます。

仮想化アプリケーションによってネットワークで処理しなければならないMAC(Media Access Control)アドレスの分量が加速的に増加しています。これによって障害時のネットワークの再収束がPEによって学習されるMACアドレスの数に依存しないようにする要求が生じました。

複数宛先トラフィックのフレームのフラッディングの量を最小化しフラッディングを与えられたサイトの境界線に閉じ込めたいという要求があります。

また、VPLSと階層的VPLS(H-VPLS)で実現できる範囲を超えた柔軟なVPNトポロジーとポリシーをサポートする要件もあります。

この文書では、上記の問題を解決する新しいソリューション、名付けてEtherent VPN (EVPN)に対する要件を定義することに焦点を当てます。

4節では冗長化を探究します。5節ではマルチキャスト最適化の要件について記述します。6節ではプロビジョニングの簡便性の要件について記載します。7節では新しいサービスインターフェイスの要件に焦点を当てます。8節では高速収束について注目します。9節ではフラッディングの抑制の要件について記載します。最後に10節で柔軟なVPNトポロジーとポリシーのサポートについて議論します。

2. Specification of Requirements

RFC2119のいつもの

3. 用語

AS: 自律システム(Autonomous System)

CE: Customer Edge

E-Tree: Ethernet Tree

MACアドレス: Media Access Controlアドレス - MACと呼ぶことにします

LSP: Label Switched Path

PE: Provider Edge

MP2MP: Multipoint to Multipoint

VPLS: Virtual Private LAN Service

Single-Active Redundancy Mode: デバイスまたはネットワークが2つ以上のPEのグループにマルチホームしていて、このような冗長グループの中でただ一つのPEが、与えられたVLANにおいてマルチホームのデバイスまたはネットワークへ/からのトラフィックを転送できるとき、このようなマルチホーミングを「Single-Active」と呼びます。

All-Active Redundancy Mode: デバイスまたはネットワークが2つ以上のPEのグループにマルチホームしていて、このような冗長グループのすべてのPEが、与えられたVLANにおいてマルチホームのデバイスまたはネットワークへ/からのトラフィックを転送できるとき、このようなマルチホーミングを「All-Active」と呼びます。

4. 冗長性の要件

4.1. フローベースのロードバランス

一連のPEノードにCEのノードをマルチホームするときの一般的な仕組みは、802.1AXに基づいてマルチシャーシのリンクアグリゲーショングループ(LAG)を採用することです。PWE3-ICCPにはこのような手法が記載されています。イーサネットのリンクアグリゲーションにおいて、PEに接続された接続回線(Attachment Circuits)越しにCEがトラフィックを分散させるロードバランスのアルゴリズムは非常に柔軟です。このアルゴリズムの唯一の要件は、与えられたトラフィックフローに対してフレームが確実に順序どおりに配送されるようにすることです。バンドル内の出力リンクを選択するアルゴリズムの典型的な実装では、次のうち1つ以上のフィールドに基づいてフローを識別するハッシュ関数をベースとしています。

ここで述べておく重要なポイントは、802.1AXではイーサネットバンドルに対する標準のロードバランスアルゴリズムを定義しておらず、違う実装では違う動作をするということです。事実としてリンク上で非対称のロードバランスがあったとしてもバンドルは正常に動作します。そうなると、All-Activeマルチホーミングのための第一の要件は、L2、L3、L4のヘッダーフィールドに基づいてCEノードからのトラフィックに対して柔軟なフローベースのロードバランスを実現することができることになります。

  • (R1a) EVPNソリューションは、上記のようにCEからのトラフィックに対して柔軟なフローベースのロードバランスをできなければなりません(MUST)。

  • (R1b) EVPNソリューションは、CEが一つ以上のPEに接続している場合でもCE宛のトラフィックに対してフローベースのロードバランスをサポートすることもできなければなりません(MUST)。そのためCEが接続されているPEの数によらずCEに接続された複数のリンクを活用することができなければなりませんん(MUST)。

CEが複数のPEにマルチホームしているときに、それぞれのリモートPEからそれぞれのマルチホーミングPEまで複数の等コストマルチパス(ECMP)が存在し得るということは留意するべきでしょう。さらにAll-ActiveでマルチホームしているCEについて、リモートPEはこのマルチホームしているCE宛のトラフィックを送信するにあたってマルチホームPEのうちのいずれかを選ぶことができます。そのため、All-Activeマルチホーミングをサポートする場合は、マルチホームCE宛のトラフィックに対してこれらのパスを最大限活用しなくてはなりません(MUST)。

(R1c) EVPNソリューションは、複数の自律システムにまたがる冗長グループのメンバーであるPE間でフローベースのロードバランスをサポートできるべきです(SHOULD)。

4.2. フローベースのマルチパス

4.1節で記述した(フローベースのロードバランスなどの)All-Active冗長モードに合うどのようなソリューションも、与えられたPEのペアの間の複数のパスを活用しなければなりません。たとえば、2つ以上のLSPがリモートPEとAll-Active冗長モードのグループにあるPEのペアの間にあるとき、冗長グループにあるPE宛のトラフィックに対してフローごとにそれらのLSPの間でトラフィックをロードバランスできる必要があります。さらにもしリモートPEと冗長グループにあるうちの1つのPEとの間に2つ以上のECMPパスが存在するとき、すべての等コストLSPを活用する必要があります。後者のためにRFC6790のエントロピーラベルに基づいたロードバランス機能を活用することも可能です。

(R2a) EVPNソリューションは、リモートPEとAll-Activeマルチホーミングの冗長グループに属するすべてのPEの間にあるすべてのLSPを活用できなければなりません(MUST)

(R2b) EVPNソリューションは、リモートPEとAll-Activeマルチホーミングの冗長グループに属する任意のPEの間にあるすべてのECMPパスを活用できなければなりません(MUST)

例としてCE1がPE1とPE2にマルチホームをし、CE2がPE3とPE4にマルチホームをして、All-Active冗長モードで動作しているシナリオを考えます。さらに、CE1とCE2がマルチホームしている任意のPEの間に3本のECMPパスが存在しているとします。CE1からCE2へのトラフィックは、次のようにMPLS/IPコア上で異なる12本のパスで転送されます。CE1はPE1とPE2にトラフィックをロードバランスします。PE1とPE2はそれぞれがPE3とPE4に3本のECMPパスを持っているため、合計12本のパスがあります。最後にPE3とPE4にトラフィックが到着すると、イーサネットチャネル(リンクバンドル)越しにCE2に転送されます。

フローベースのマルチパスが前節で記述したようなフローベースのロードバランスを補完することは指摘する価値があります。

4.3. 地理的に冗長化されたPEノード

マルチホームの接続性をCEやアクセスネットワークに提供するPEノードは、物理的に同じ場所に設置されている(コロケーション)場合もあれば、異なる場所(Central Office(CO)やPoint of Presence(POP)など)に地理的に分散されている場合もあります。後者は電力障害や自然災害に対してビジネス継続性を確保できるような地理的な冗長を実現するときに必要となります。All-Activeマルチホーミングの仕組みは、コロケーションに加えて地理的に分散したPEの配置をサポートする必要があります。後者のシナリオはマルチホーミングの仕組みを動作させる上で多くの場合PEの間に専用線が必要であるということを意味しますが、コスト的に魅力ではありません。さらにリモートPEからデュアルホーム構成のPEのペアへのIGPコストは、後者のPEが地理的に冗長化されているときには同じであるということが仮定できません。

(R3a) EVPNソリューションは、All-Activeマルチホーミングを、マルチホームのグループに属するPEの間で専用の制御リンクやデータリンクを必要とすることなくサポートしなければなりません(MUST)。

(R3b) EVPNソリューションは、リモートPEからマルチホームのグループに属するそれぞれのPEの間のIGPコストが異なることをサポートしなければなりません(MUST)。

(R3c) EVPNソリューションは、同じ自律システム内の異なるIGPドメインにまたがったマルチホーミングをサポートしなければなりません(MUST)。

(R3d) EVPNソリューションは、複数の自律システムをまたがったマルチホーミングをサポートするべきです(SHOULD)。

4.4. 最適化されたトラフィックの転送

典型的なネットワークでは、指定されたPEのペアを考えたときに、シングルホームのCEとマルチホームのCEが両方とも接続されていると考えるのが一般的です。

(R4) All-Activeマルチホーミングは、次のシナリオに対してユニキャストトラフィックの最適な転送をサポートするべきです(SHOULD)。「最適な転送」とは、宛先のCEがマルチホームのPEのうちの1つに接続されていない限り、マルチホームのグループのメンバーであるPE機器の間でトラフィックが転送されないことを意味します。

  1. シングルホームCEからマルチホームCE
  2. マルチホームCEからシングルホームCE
  3. マルチホームCEからマルチホームCE

これは特に地理的に冗長化されたPEの場合に重要になってきます。あるPEから同じマルチホームグループの別のPEへトラフィックを転送することはレイテンシーの増加を招きます。さらにPEノードとコアノードのスイッチング容量が非効率的に使用されます。

4.5. 柔軟な冗長グループのサポート

(R5) 柔軟な冗長グループをサポートするために、マルチホーミングの仕組みはPEノードを任意の冗長グループにグルーピングでき、それぞれの冗長グループが同じグループのPEを共有するすべてのマルチホームの機器やネットワークを表せるようにするべきです(SHOULD)。

一番良い例の説明として、3つのPEノードPE1, PE2, PE3を考えます。マルチホーミングの仕組みは与えられたPE、例えばPE1が複数の冗長グループに同時に所属できるようにしなければなりません(MUST)。たとえばグループ(PE1, PE2), (PE1, PE3), (PE2, PE3)が存在して、CEはこれらの3つの冗長グループのうちいずれに対してもマルチホームできます。

4.6. マルチホームされたネットワーク

単一の機器ではなくPEのグループにマルチホームしているイーサネットのネットワークを要求するアプリケーションが存在します。イーサネットのネットワークは典型的にはMultiple Spanning Tree Protocol (802.1Q)やEthernet Ring Protection Switching (G.8032)などのレジリエンシーの仕組みを動作させています。PEはこのイーサネットネットワークの制御プロトコルに参加することもできますし、参加しないこともできます。802.1QやG.8032を動作させているネットワークがマルチホームするために、これらのプロトコルは、それぞれのVLANについてマルチホームのリンクのうち1つのリンクだけがアクティブであることが必要となります。

(R6a) EVPNソリューションは、すべてのVLANが単一のPEでアクティブとなるSingle-Active冗長モードによるマルチホームのネットワーク接続をサポートしなければなりません(MUST)。

(R6b) EVPNソリューションは、分割されたVLANの集合がいずれかのPEでアクティブとなるSingle-Active冗長モードによるマルチホームのネットワーク接続をサポートしなければなりません(MUST)。

(R6c) EVPNソリューションは、複数のASにまたがる冗長グループのメンバーであるPEの間でSingle-Active冗長モードをサポートするべきです(SHOULD)。

(R6d) EVPNソリューションは、MACベースのロードバランスをしている(つまりあるVLANにおいて異なるMACアドレスが異なるPEから到達可能である)マルチホームのネットワークに対してもSingle-Active冗長モードをサポートできます(MAY)。

5. マルチキャスト最適化の要件

マルチキャスト、ブロードキャスト、Unknownユニキャストトラフィックを最適化するためにMP2MP LSPを使用し、コアルータでのマルチキャストの状態数を減らすことが望ましいような環境が存在します。RFC7117ではMP2MP LSPを使用することが不可能となっています。なぜなら現在のVPLSソリューションではLSP越しにUnknownユニキャストを受信したegress PEが学習を実行しないといけないからです。送信者を特定する継承の仕組みを持っていないためMP2MP LSPを使用することが困難になっています。もし学習をするための送信者の特定が必要性がなくなればマルチキャスト最適化のためのMP2MP LSPを使用しやすくなります。

(R7a) EVPNソリューションは、MP2MP LSP越しにパケットを受信したときにMPLS LSPに対してMAC学習を必要としない仕組みを提供しなければなりません(MUST)。

(R7b) EVPNソリューションは、MP2MP LSPを使用してマルチキャスト、ブロードキャスト、Unknownユニキャストのトラフィックの配送の最適化をできる手順を提供するべきです(SHOULD)。

6. プロビジョニングの簡便さの要件

L2VPN技術のエンタープライズでの採用が拡大したため、プロビジョニングの簡便さが最重要になっています。現在のVPLSは自動発見の仕組みを備えていて、MPLS/IPコアネットワーク越しに与えられたVPNインスタンスに所属するPEの自動発見することが可能になっているとはいえ、さらなる単純化が下記のように求められています。

(R8a) EVPNソリューションは、RFC4761やRFC6074に記載されているVPLSの自動発見に似せて、VPNに参加するPEのMPLS/IPコアネットワーク越しの自動発見をサポートしなければなりません(MUST)。

(R8b) EVPNソリューションは、与えられた冗長グループまたはマルチホームグループに所属するPEの自動発見をサポートするべきです(SHOULD)。

(R8c) EVPNソリューションは、マルチホーム機器やマルチホームネットワークのためのサイトIDの自動送信をサポートし、サイトIDに基づいた冗長グループIDの自動生成をサポートするべきです(SHOULD)

(R8d) EVPNソリューションは、冗長(マルチホーミング)グループに参加するPEの間でのDesignated Forwarder (DF)の自動選出をサポートするべきであり、(VLANなどの)サービスインスタンスを冗長グループに参加するPEの間で分割できるようにするべきです(SHOULD)。

(R8e) VLAN識別子がMPLSネットワーク内でグローバルであるような(最大4Kのサービスに限定するネットワークの)デプロイでは、PEはMPLS特有の属性(VPN IDやBGP Route Targetなど)をVLAN識別子から計算するべきです(SHOULD)。VLAN識別子をネットワーク事業者がアクセス回線に設定するだけで、コアネットワーク越しのサービスを設定するためのすべてのMPLSとBGPのパラメータが、明示的な設定を必要とせずに自動的に計算できます。

(R8f) 新しい値が設定されていないパラメータについてはデフォルトの値を使用するように実装するべきです(SHOULD)。

7. 新しいサービスインターフェイスの要件

MEFと802.1Qは次のサービス仕様を規定しています。

Portモード: このモードではポートのすべてのトラフィックが単一のブリッジドメインとそれに対応するL2VPNサービスインスタンスマッピングされます。顧客のVLANの透過性はend-to-endで保証されます。

VLANモード: このモードではポートのそれぞれのVLANが一意のブリッジドメインとそれに対応するL2VPNサービスインスタンスマッピングされます。このモードではポートでのサービスの重畳が可能になり、任意のVLAN変換をサポートします。

VLANバンドルモード: このモードでは、ポートのVLANのグループが一括して一意のブリッジドメインとL2VPNサービスインスタンスマッピングされます。顧客のMACアドレスは同じサービスインスタンスマッピングされたすべてのVLANの中で一意である必要があります。

上記のサービスのそれぞれに対して、関連するサービスをサポートするPEにおいて単一のブリッジドメインがサービスインスタンスごとに割り当てられます。たとえばPortモードの場合、ポートに設定されたVLANの数に関わらず、単一のブリッジドメインがそのサービスインスタンスに属するすべてのポートのために割り当てられます。

なお、上記の「ブリッジドメイン」という用語は、IEEEブリッジモデルで定義されているMAC転送テーブルを意味しており、特定の実装を示すものではありません。

RFC4762では2つのタイプのVPLSサービスが「unqualified学習とqualified学習」に基づいて定義されており、それぞれがPortモードとVLANモードにマッピングされます。

(R9a) EVPNソリューションは、上記の3つのサービスタイプ(Portモード、VLANモード、VLANバンドル)をサポートしなければなりません(MUST)

データセンター相互接続のためにホストされたアプリケーションに対して、単一のL2VPNインスタンスを使用して、インスタンスに関連付けられた複数のVLANの間でのデータプレーン分割を維持したまま、WAN越しにイーサネットのVLANを拡張できる能力をネットワーク事業者は求めています。「これをVLAN-aware Bundleサービス」と呼びます。

(R9b) EVPNソリューションは、VLAN-aware Bundleサービスをサポートすることができます(MAY)。

これにより新しいサービスインターフェイスが2つ生じます。変換を伴わないVLAN-aware Bundleと変換の伴うVLAN-aware Bundleです。

変換を伴わないVLAN-aware Bundleのためのサービスインターフェイスは次の特徴を持っています:

全対一のバンドルの特別なケースにおいては、このサービスインターフェイスは顧客VLANについてのいかなる事前知識を仮定してはいけません。言い換えると、顧客VLANをPEに設定してはいけません。その代わりにポートベースのサービスのようにインターフェイスを設定します。

変換を伴うVLAN-Aware Bundleのためのサービスインターフェイスは次の特徴を持っています:

これらの新しいサービスタイプと以前に定義されていた3つのタイプの間で、サービスプロバイダ側のリソース確保の点においての一番大きな差分は、新しいサービスは、L2VPNサービスインスタンスごとに単一のブリッジドメインではなく、L2VPNサービスごとに複数のブリッジドメインを(顧客VLANごとに1つ)確保する必要があることです。

8. 高速収束

(R10a) EVPNソリューションは、マルチホームの機器とマルチホームのネットワークの両方のケースに対して、PE-CE間の接続回線の障害に加えてPEノードの障害からの回復能力を提供する必要があります(MUST)。

(R10b) この回復機構はPEによって学習されたMACアドレスの数に依存しない収束時間を提供しなければなりません(MUST)。これはレイヤー2ネットワークで処理しなければならないMACアドレスの数が増える仮想化プリケーションの文脈においては特に重要です。

(R10c) さらにこの回復機構は、接続回線やPEに関連付けられたサービスインスタンスの数に依存しない収束時間を提供するべきです(SHOULD)。

9. フラッディングの抑制

(R11a) EVPNソリューションは、ネットワーク事業者がUnknownユニキャストフレームを破棄するかフラッディングするかを選択できるようにするべきです(SHOULD)。この属性はサービスインスタンスごとに設定可能である必要があります。

(R11b) 加えて、データセンター相互接続に使用する場合には、与えられたサイトの境界の外側へのブドードキャストフレームのフラッディングを最小化するべきです(SHOULD)。特に関心があるのが定期的なAddress Resolution Protocol(ARP)トラフィックです。

(R11c) さらにトポロジー変更時のユニキャストトラフィックの必要のないフラッディングを排除するべきです(SHOULD)。与えられたMACアドレスに対するバックアップパスの事前知識をPEが持っているようなマルチホームのサイトに対しては特にです。

10. 柔軟なVPNトポロジーとポリシーのサポート

(R12a) EVPNソリューションは、そのソリューションの下地となる機構によって制約を受けない柔軟なVPNトポロジーをサポートする能力を備えるべきです(MUST)。

これについての一つの例はE-Treeトポロジーです。VPNの一つ以上のサイトがルートになり、他がリーフとなります。ルートは他のルートやリーフにトラフィックを送信することができますが、リーフはルートとだけしか通信することができません。EVPNソリューションはE-Treeトポロジーをサポートする能力を提供しなければなりません(MUST)。

(R12b) EVPNソリューションは、VPNのどのPEがどのMACアドレスを学習し、特定のMACアドレスがどのように転送されるかを制御するために、MACアドレスの粒度でポリシーを適用する能力を提供することができます(MAY)。特定のMACアドレストラフィックを送信または受信できるように、VPN中のいくつかのPEに対してだけポリシーを適用できるようにすることを可能にするべきです。

(R12c) EVPNソリューションは、RFC4364に記述されているinter-AS Option-Cとinter-AS Option-Bの両方のシナリオをサポートできなければなりません(MUST)。

11. セキュリティについての考察

EVPNソリューションのために開発されたいかなるプロトコル拡張も適切なセキュリティの分析を含むべきです。MAC学習がデータプレーンで行われるRFC4761とRFC4762とMAC学習がコントロールプレーンで行われるRFC4364で扱われているセキュリティ要件に加えて、次の追加の要件を補う必要があります。

(R13) EVPNソリューションは、同じMACアドレスが2つの異なるイーサネットセグメントの背後に現れる状況を(不注意によるものか悪意のあるものかにかかわらず)検出して適切に処理する機能を持たなければなりません(MUST)。

(R14) EVPNソリューションは、悪意のあるトラフィックがネットワークに入ってくることを制限するため、そのMACアドレスを特定のイーサネットセグメントに関連付ける機能(別名「Sticky MAC」)を持たなければなりません(MUST)。この機能は詐称されたMACアドレスがネットワークに出現することを制限することができます。この機能が有効化されたとき、このようなSticky MACアドレスMACモビリティは許されず、その他のいかなるイーサネットセグメントからのこのようなMACアドレス宛のトラフィックは破棄されなくてはなりません(MUST)。

12. 標準への参考文献

省略

13. 有益な参考文献

省略