[要約] RFC 7387は、MPLSネットワーク上でEthernet Tree(E-Tree)サービスを提供するためのフレームワークを提供しています。このRFCの目的は、E-Treeサービスの設計と展開を容易にすることです。

Internet Engineering Task Force (IETF)                       R. Key, Ed.
Request for Comments: 7387
Category: Informational                                     L. Yong, Ed.
ISSN: 2070-1721                                                   Huawei
                                                               S. Delord
                                                                 Telstra
                                                               F. Jounay
                                                               Orange CH
                                                                  L. Jin
                                                            October 2014
        

A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network

マルチプロトコルラベルスイッチング(MPLS)ネットワーク上のイーサネットツリー(Eツリー)サービスのフレームワーク

Abstract

概要

This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network.

このドキュメントでは、マルチプロトコルラベルスイッチング(MPLS)ネットワーク上でメトロイーサネットフォーラム(MEF)Eツリーサービスをサポートするためのイーサネットツリー(Eツリー)ソリューションフレームワークについて説明します。目的は、既存のMPLSネットワーク上のイーサネットLAN(E-LAN​​)サービスに加えて、E-Treeサービスをエミュレートするシンプルで効果的なアプローチを提供することです。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7387.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7387で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. Terminology ................................................3
   2. Overview ........................................................4
      2.1. Ethernet Bridge Network ....................................4
      2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree .........4
      2.3. IETF L2VPN .................................................5
           2.3.1. Virtual Private LAN Service (VPLS) ..................5
           2.3.2. Ethernet VPN (EVPN) .................................5
           2.3.3. Virtual Private Multicast Service (VPMS) ............6
   3. E-Tree Architecture Reference Model .............................6
   4. E-Tree Use Cases ................................................8
   5. L2VPN Gaps for Emulating MEF E-Tree Service .....................9
      5.1. No Differentiation on AC Role ..............................9
      5.2. No AC Role Indication or Advertisement .....................9
      5.3. Other Issues ...............................................9
   6. Security Considerations ........................................10
   7. References .....................................................11
      7.1. Normative References ......................................11
      7.2. Informative References ....................................11
   Acknowledgments ...................................................12
   Contributors ......................................................12
   Authors' Addresses ................................................13
        
1. Introduction
1. はじめに

This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network.

このドキュメントでは、マルチプロトコルラベルスイッチング(MPLS)ネットワーク上でメトロイーサネットフォーラム(MEF)Eツリーサービスをサポートするためのイーサネットツリー(Eツリー)ソリューションフレームワークについて説明します。目的は、既存のMPLSネットワーク上のイーサネットLAN(E-LAN​​)サービスに加えて、E-Treeサービスをエミュレートするシンプルで効果的なアプローチを提供することです。

This document extends the existing IETF-specified Layer 2 Virtual Private Network (L2VPN) framework [RFC4664] to provide the emulation of E-Tree services over an MPLS network. It specifies the E-Tree architecture reference model and describes the corresponding functional components. It also points out the gaps and required extension areas in existing L2VPN solutions such as Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762] and Ethernet Virtual Private Network (EVPN) [EVPN] for supporting E-Tree services.

このドキュメントは、既存のIETF指定のレイヤ2仮想プライベートネットワーク(L2VPN)フレームワーク[RFC4664]を拡張して、MPLSネットワークを介したE-Treeサービスのエミュレーションを提供します。 E-Treeアーキテクチャの参照モデルを指定し、対応する機能コンポーネントについて説明します。また、E-Treeサービスをサポートするための仮想プライベートLANサービス(VPLS)[RFC4761] [RFC4762]やイーサネット仮想プライベートネットワーク(EVPN)[EVPN]などの既存のL2VPNソリューションのギャップと必要な拡張領域についても説明します。

1.1. Terminology
1.1. 用語

This document adopts all the terminologies defined in RFC 4664 [RFC4664], RFC 4761 [RFC4761], and RFC 4762 [RFC4762]. It also uses the following terms:

このドキュメントでは、RFC 4664 [RFC4664]、RFC 4761 [RFC4761]、およびRFC 4762 [RFC4762]で定義されているすべての用語を採用しています。また、次の用語も使用します。

Leaf Attachment Circuit (AC): An AC with Leaf role. An ingress Ethernet frame at a Leaf AC (Ethernet frame arriving over an AC at the Provider Edge (PE) of an MPLS network) can only be delivered to one or more Root ACs in an E-Tree service instance. An ingress Ethernet frame at a Leaf AC must not be delivered to any Leaf ACs in the E-Tree service instance.

リーフ接続回路(AC):リーフの役割を持つAC。リーフACの入口イーサネットフレーム(MPLSネットワークのプロバイダーエッジ(PE)のAC経由で到着するイーサネットフレーム)は、E-Treeサービスインスタンスの1つ以上のルートACにのみ配信できます。リーフACの入力イーサネットフレームは、E-TreeサービスインスタンスのどのリーフACにも配信しないでください。

Root AC: An AC with Root role. An ingress Ethernet frame at a Root AC can be delivered to one or more of the other ACs in the associated E-Tree service instance.

ルートAC:ルートの役割を持つAC。ルートACの入力イーサネットフレームは、関連するE-Treeサービスインスタンス内の他の1つ以上のACに配信できます。

E-Tree: An Ethernet VPN service in which each AC is assigned the role of a Root or Leaf. The forwarding rules in an E-Tree are as follows:

Eツリー:各ACにルートまたはリーフの役割が割り当てられているイーサネットVPNサービス。 Eツリーの転送ルールは次のとおりです。

o The Root AC can communicate with other Root ACs and Leaf ACs.

o ルートACは、他のルートACおよびリーフACと通信できます。

o Leaf ACs can only communicate with Root ACs.

o リーフACはルートACとのみ通信できます。

2. Overview
2. 概観
2.1. Ethernet Bridge Network
2.1. イーサネットブリッジネットワーク

In this document, "Ethernet bridge network" refers to the Ethernet bridge/switch network defined in IEEE 802.1Q [IEEE802.1Q]. In a bridge network, a data frame is an Ethernet frame; data forwarding is based on destination Media Access Control (MAC) address; MAC reachability is learned in the data plane based on the source MAC address and the port (or tagged port) on which the frame arrives; and the MAC aging mechanism is used to remove inactive MAC addresses from the MAC forwarding table on an Ethernet switch.

このドキュメントでは、「イーサネットブリッジネットワーク」は、IEEE 802.1Q [IEEE802.1Q]で定義されたイーサネットブリッジ/スイッチネットワークを指します。ブリッジネットワークでは、データフレームはイーサネットフレームです。データ転送は、宛先メディアアクセス制御(MAC)アドレスに基づいています。 MAC到達可能性は、送信元MACアドレスとフレームが到着するポート(またはタグ付きポート)に基づいてデータプレーンで学習されます。また、MACエージングメカニズムは、イーサネットスイッチのMAC転送テーブルから非アクティブなMACアドレスを削除するために使用されます。

Data frames arriving at a switch may be destined to known unicast, unknown unicast, multicast, or broadcast MAC destinations. Unknown unicast, multicast, and broadcast frames are forwarded in a similar way, i.e., to every port except the ingress port on which the frame arrives. Multicast forwarding can be further constrained when using multicast control protocol snooping or using multicast MAC registration protocols [IEEE802.1Q].

スイッチに到着するデータフレームは、既知のユニキャスト、未知のユニキャスト、マルチキャスト、またはブロードキャストMAC宛先に送信される場合があります。不明なユニキャスト、マルチキャスト、およびブロードキャストフレームは、同様の方法で転送されます。つまり、フレームが到着する入口ポートを除くすべてのポートに転送されます。マルチキャスト制御プロトコルスヌーピングを使用する場合、またはマルチキャストMAC登録プロトコル[IEEE802.1Q]を使用する場合、マルチキャスト転送をさらに制限できます。

An Ethernet host receiving an Ethernet frame checks the destination address in the frame to decide whether it is the intended destination.

イーサネットフレームを受信するイーサネットホストは、フレーム内の宛先アドレスをチェックして、それが目的の宛先であるかどうかを判断します。

2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree
2.2. MEFマルチポイントイーサネットサービス:E-LAN​​およびE-Tree

MEF 6.1 [MEF6.1] defines two multipoint Ethernet Service types:

MEF 6.1 [MEF6.1]は、2つのマルチポイントイーサネットサービスタイプを定義します。

o E-LAN (Ethernet LAN), a multipoint-to-multipoint service

o E-LAN​​(イーサネットLAN)、マルチポイントツーマルチポイントサービス

o E-Tree (Ethernet Tree), a rooted-multipoint service

o E-Tree(イーサネットツリー)、ルート化されたマルチポイントサービス

The MEF defines User-Network Interface (UNI) in a multipoint service as the Ethernet interface between Customer Equipment (CE) and a Provider Edge (PE), i.e., the PE can send and receive Ethernet frames to/from the CE. The MEF also defines UNI roles in a multipoint service. One role is Root, and another is Leaf.

MEFは、マルチポイントサービスのユーザーネットワークインターフェイス(UNI)を、カスタマー機器(CE)とプロバイダーエッジ(PE)の間のイーサネットインターフェイスとして定義します。つまり、PEはイーサネットフレームをCEとの間で送受信できます。 MEFは、マルチポイントサービスでのUNIロールも定義します。 1つの役割はルートで、もう1つの役割はリーフです。

Note that MEF UNI in a service is equivalent to the Attachment Circuit (AC) defined in L2VPN [RFC4664]. The Root AC and Leaf AC defined in this document are the same as the Root UNI and Leaf UNI as defined in MEF 10.3 [MEF10.3]. The terms "Root AC" and "Leaf AC" are used in the following MEF service description.

サービスのMEF UNIは、L2VPN [RFC4664]で定義されている接続回線(AC)に相当することに注意してください。このドキュメントで定義されているルートACおよびリーフACは、MEF 10.3 [MEF10.3]で定義されているルートUNIおよびリーフUNIと同じです。 「ルートAC」と「リーフAC」という用語は、次のMEFサービスの説明で使用されます。

For an E-LAN service, all ACs have the Root role, which means that any AC can communicate with other ACs in the service. The E-LAN service defined by the MEF may be implemented by IETF L2VPN solutions such as VPLS and EVPN [EVPN].

E-LAN​​サービスの場合、すべてのACにはルートの役割があります。つまり、どのACもサービス内の他のACと通信できます。 MEFによって定義されたE-LAN​​サービスは、VPLSやEVPN [EVPN]などのIETF L2VPNソリューションによって実装できます。

An E-Tree service has one or more Root ACs and at least two Leaf ACs. An E-Tree service supports communication among the roots and between a root and a leaf but prohibits communication among the leaves. Existing IETF L2VPN solutions can't support the E-Tree service. This document specifies the E-Tree architecture reference model that supports the E-Tree service defined by the MEF [MEF6.1]. Section 4 will discuss different E-Tree use cases.

E-Treeサービスには、1つ以上のルートACと少なくとも2つのリーフACがあります。 E-Treeサービスは、ルート間およびルートとリーフ間の通信をサポートしますが、リーフ間の通信を禁止します。既存のIETF L2VPNソリューションは、E-Treeサービスをサポートできません。このドキュメントは、MEF [MEF6.1]によって定義されたE-TreeサービスをサポートするE-Treeアーキテクチャリファレンスモデルを指定します。セクション4では、さまざまなEツリーの使用例について説明します。

2.3. IETF L2VPN
2.3. IETF L2VPN
2.3.1. Virtual Private LAN Service (VPLS)
2.3.1. 仮想プライベートLANサービス(VPLS)

VPLS [RFC4761] [RFC4762] is an L2VPN solution that provides multipoint-to-multipoint Ethernet connectivity across IP/MPLS networks. VPLS emulates traditional Ethernet Virtual LAN (VLAN) services in MPLS networks and may support MEF E-LAN services.

VPLS [RFC4761] [RFC4762]は、IP / MPLSネットワーク全体にマルチポイントツーマルチポイントイーサネット接続を提供するL2VPNソリューションです。 VPLSは、MPLSネットワークで従来のイーサネット仮想LAN(VLAN)サービスをエミュレートし、MEF E-LAN​​サービスをサポートする場合があります。

A data frame in VPLS is an Ethernet frame. Data forwarding in a VPLS instance is based on the destination MAC address and the VLAN on which the frame arrives. MAC reachability learning is performed in the data plane based on the source address and the AC or pseudowire (PW) on which the frame arrives. MAC aging is the mechanism used to remove inactive MAC addresses from a VPLS switching instance (VSI) on a PE. VPLS supports forwarding for known unicast frames, as well as unknown unicast, broadcast, and multicast Ethernet frames.

VPLSのデータフレームはイーサネットフレームです。 VPLSインスタンスでのデータ転送は、宛先MACアドレスとフレームが到着するVLANに基づいています。 MAC到達可能性の学習は、送信元アドレスと、フレームが到着するACまたは疑似配線(PW)に基づいて、データプレーンで実行されます。 MACエージングは​​、PE上のVPLSスイッチングインスタンス(VSI)から非アクティブなMACアドレスを削除するために使用されるメカニズムです。 VPLSは、既知のユニキャストフレーム、および未知のユニキャスト、ブロードキャスト、マルチキャストイーサネットフレームの転送をサポートします。

Many service providers have deployed VPLS in their networks to provide L2VPN services to customers.

多くのサービスプロバイダーは、ネットワークにVPLSを導入してL2VPNサービスを顧客に提供しています。

2.3.2. Ethernet VPN (EVPN)
2.3.2. イーサネットVPN(EVPN)

Ethernet VPN [EVPN] is an enhanced L2VPN solution that emulates an Ethernet LAN or virtual LAN(s) across MPLS networks.

イーサネットVPN [EVPN]は、MPLSネットワーク全体でイーサネットLANまたは仮想LANをエミュレートする拡張L2VPNソリューションです。

EVPN supports active-active multihoming of CEs and uses the Multiprotocol Border Gateway Protocol (MP-BGP) control plane to advertise MAC address reachability from an ingress PE to egress PEs. Thus, a PE learns MAC addresses that are reachable over local ACs in the data plane and other MAC addresses reachable across the MPLS network over remote ACs via the EVPN MP-BGP control plane. As a result, EVPN aims to support large-scale L2VPN with better resiliency compared to VPLS.

EVPNはCEのアクティブ-アクティブマルチホーミングをサポートし、マルチプロトコルボーダーゲートウェイプロトコル(MP-BGP)コントロールプレーンを使用して、入力PEから出力PEへのMACアドレス到達可能性をアドバタイズします。したがって、PEは、データプレーンのローカルACを介して到達可能なMACアドレスと、EVPN MP-BGPコントロールプレーンを介してリモートACを介してMPLSネットワークを介して到達可能な他のMACアドレスを学習します。その結果、EVPNは、VPLSと比較して優れた復元力で大規模なL2VPNをサポートすることを目指しています。

EVPN is a relatively new technique and is still under development in the IETF L2VPN WG.

EVPNは比較的新しい技術であり、IETF L2VPN WGでまだ開発中です。

2.3.3. Virtual Private Multicast Service (VPMS)
2.3.3. 仮想プライベートマルチキャストサービス(VPMS)

VPMS [VPMS] is an L2VPN solution that provides point-to-multipoint connectivity across MPLS networks and supports various attachment circuit (AC) types, including Frame Relay, ATM, Ethernet, PPP, etc.

VPMS [VPMS]は、MPLSネットワーク全体にポイントツーマルチポイント接続を提供し、フレームリレー、ATM、イーサネット、PPPなどを含むさまざまな接続回線(AC)タイプをサポートするL2VPNソリューションです。

In the case of Ethernet ACs, VPMS provides single coverage of receiver membership, i.e., there is no differentiation among multicast groups in one VPN. The destination address in the Ethernet frame is not used in data forwarding.

イーサネットACの場合、VPMSはレシーバーメンバーシップの単一のカバレッジを提供します。つまり、1つのVPN内のマルチキャストグループ間の区別はありません。イーサネットフレームの宛先アドレスは、データ転送では使用されません。

VPMS supports unidirectional point-to-multipoint transport from a sender to multiple receivers and may support reverse transport in a point-to-point manner.

VPMSは、送信者から複数の受信者への単方向ポイントツーマルチポイントトランスポートをサポートし、ポイントツーポイント方式でリバーストランスポートをサポートする場合があります。

3. E-Tree Architecture Reference Model
3. Eツリーアーキテクチャリファレンスモデル

Figure 1 illustrates the E-Tree architecture reference model. Three Provider Edges -- PE1, PE2, and PE3 -- are shown in the figure. Each PE has a Virtual Service Instance (VSI) associated with an E-Tree service instance. A CE attaches to the VSI on a PE via an AC. Each AC must be configured with a Root or Leaf role. In Figure 1, AC1, AC2, AC5, AC6, AC9, and AC10 are Root ACs; AC3, AC4, AC7, AC8, AC11, and AC12 are Leaf ACs. This implies that a PE (local or remote) processes the Ethernet frames from CE01, CE02, etc., as if they originated from a Root AC, and it processes the Ethernet frames from CE03, CE04, etc., as if they originated from a Leaf AC.

図1は、Eツリーアーキテクチャの参照モデルを示しています。図には、3つのプロバイダーエッジ(PE1、PE2、およびPE3)が示されています。各PEには、E-Treeサービスインスタンスに関連付けられた仮想サービスインスタンス(VSI)があります。 CEは、ACを介してPEのVSIに接続します。各ACは、ルートまたはリーフの役割で構成する必要があります。図1では、AC1、AC2、AC5、AC6、AC9、およびAC10がルートACです。 AC3、AC4、AC7、AC8、AC11、およびAC12はリーフACです。これは、PE(ローカルまたはリモート)がCE01、CE02などからのイーサネットフレームをルートACから発信されたかのように処理し、CE03、CE04などからのイーサネットフレームを発信元のように処理することを意味します。リーフAC。

Under this architecture model, the forwarding rules among the ACs, regardless of whether the sending AC and receiving AC are on the same PE or on different PEs, are described as follows:

このアーキテクチャモデルでは、送信ACと受信ACが同じPE上にあるか、異なるPE上にあるかに関係なく、AC間の転送ルールは次のように記述されます。

o An egress frame (the frame to be transmitted over an AC) at an AC with Root role must be the result of an ingress frame at an AC (the frame received at an AC) that has Root or Leaf role and is attached to the same E-Tree service instance.

o ルートの役割を持つACでの出力フレーム(ACを介して送信されるフレーム)は、ルートまたはリーフの役割を持ち、同じ役割に接続されているACでの入力フレーム(ACで受信されたフレーム)の結果である必要があります。 E-Treeサービスインスタンス。

o An egress frame at the AC with Leaf role must be the result of an ingress frame at an AC that has Root role and is attached to the same E-Tree service instance.

o リーフロールを持つACでの出力フレームは、ルートロールを持ち、同じE-Treeサービスインスタンスに接続されているACでの入力フレームの結果である必要があります。

                     <------------E-Tree----------->
                  PE1+---------+         +---------+PE2
    +----+           |  +---+  |         |  +---+  |           +----+
    |CE01+----AC1----+--+   |  |         |  |   +--+----AC5----+CE05|
    +----+ (Root AC) |  | V |  |         |  | V |  | (Root AC) +----+
    +----+           |  |   |  |         |  |   |  |           +----+
    |CE02+----AC2----+--+   |  |         |  |   +--+----AC6----+CE06|
    +----+ (Root AC) |  | S +--+---------+--+ S |  | (Root AC) +----+
    +----+           |  |   |  |         |  |   |  |           +----+
    |CE03+----AC3----+--+   |  |         |  |   +--+----AC7----+CE07|
    +----+ (Leaf AC) |  | I |  |         |  | I |  | (Leaf AC) +----+
    +----+           |  |   |  |         |  |   |  |           +----+
    |CE04+----AC4----+--+   |  |         |  |   +--+----AC8----+CE08|
    +----+ (Leaf AC) |  +-+-+  |         |  +-+-+  | (Leaf AC) +----+
                     +----+----+         +----+----+
                          |      MPLS Core    |
                          |              +----+----+
                          |              |  +-+-+  |           +----+
                          |              |  |   +--+----AC9----+CE09|
                          |              |  | V |  | (Root AC) +----+
                          |              |  |   |  |           +----+
                          |              |  |   +--+----AC10---+CE10|
                          +--------------+--+ S |  | (Root AC) +----+
                                         |  |   |  |           +----+
                                         |  |   +--+----AC11---+CE11|
                                         |  | I |  | (Leaf AC) +----+
                                         |  |   |  |           +----+
                                         |  |   +--+----AC12---+CE12|
                                         |  +---+  | (Leaf AC) +----+
                                     PE3 +---------+
                     <-------------E-Tree---------->
        

Figure 1: E-Tree Architecture Reference Model

図1:Eツリーアーキテクチャの参照モデル

These rules apply to all frame types, i.e., known unicast, unknown unicast, broadcast, and multicast. For known unicast frames, forwarding in a VSI context is based on the destination MAC address.

これらのルールは、すべてのフレームタイプ、つまり既知のユニキャスト、未知のユニキャスト、ブロードキャスト、およびマルチキャストに適用されます。既知のユニキャストフレームの場合、VSIコンテキストでの転送は宛先MACアドレスに基づいています。

A VSI on a PE corresponds to an E-Tree service instance and maintains a MAC forwarding table that is isolated from other VSI tables on the PE. It also keeps track of local AC roles. The VSI receives a frame from an AC or across the MPLS core, and it forwards the frame to another AC over which the destination is reachable according to the VSI forwarding table and forwarding rules described above. When the target AC is on a remote PE, the VSI forwards the frame to the remote PE over the MPLS core. Forwarding over the MPLS core will be dependent on the E-Tree solution. For instance, a solution may adopt PWs to mesh VSIs as in VPLS and to forward frames over VSIs subject to the E-Tree forwarding rules. Alternatively, a solution may adopt the EVPN forwarding paradigm constrained by the E-Tree forwarding rules. Thus, solutions that satisfy the E-Tree requirements could be extensions to VPLS and EVPN.

PE上のVSIはE-Treeサービスインスタンスに対応し、PE上の他のVSIテーブルから分離されたMAC転送テーブルを維持します。また、ローカルACの役割も追跡します。 VSIは、ACから、またはMPLSコア全体でフレームを受信し、上記のVSI転送テーブルと転送ルールに従って宛先に到達できる別のACにフレームを転送します。ターゲットACがリモートPEにある場合、VSIはフレームをMPLSコアを介してリモートPEに転送します。 MPLSコアを介した転送は、E-Treeソリューションに依存します。たとえば、ソリューションはPWを採用してVPLSのようにVSIをメッシュ化し、Eツリー転送ルールの対象となるVSIを介してフレームを転送することができます。あるいは、ソリューションは、Eツリー転送ルールによって制約されたEVPN転送パラダイムを採用する場合があります。したがって、E-Tree要件を満たすソリューションは、VPLSおよびEVPNの拡張となる可能性があります。

In most use cases, an E-Tree service has only a few Root ACs (root CE sites) but many Leaf ACs (leaf CE sites). Furthermore, a PE may have only Root ACs or only Leaf ACs. Figure 1 provides a general E-Tree architecture model.

ほとんどのユースケースでは、E-Treeサービスには少数のルートAC(ルートCEサイト)しかありませんが、多数のリーフAC(リーフCEサイト)があります。さらに、PEはルートACのみ、またはリーフACのみを持つことができます。図1は、一般的なEツリーアーキテクチャモデルを示しています。

4. E-Tree Use Cases
4. Eツリーの使用例

Table 1 below presents some major use cases for E-Tree.

以下の表1は、E-Treeのいくつかの主な使用例を示しています。

          +---------------------------+--------------+------------+
          | Use Case                  | Root AC      | Leaf AC    |
      +---+---------------------------+--------------+------------+
      | 1 | Hub & Spoke VPN           | Hub Site     | Spoke Site |
      +---+---------------------------+--------------+------------+
      | 2 | Wholesale Access          | Customer's   | Customer's |
      |   |                           | Interconnect | Subscriber |
      +---+---------------------------+--------------+------------+
      | 3 | Mobile Backhaul           | RAN NC       | RAN BS     |
      +---+---------------------------+--------------+------------+
      | 4 | IEEE 1588 PTPv2 [IEEE1588]| PTP Server   | PTP Client |
      |   | Clock Synchronization     |              |            |
      +---+---------------------------+--------------+------------+
      | 5 | Internet Access           | BNG Router   | Subscriber |
      |   | Reference [TR-101]        |              |            |
      +---+---------------------------+--------------+------------+
      | 6 | Broadcast Video           | Video Source | Subscriber |
      |   | (unidirectional only)     |              |            |
      +---+---------------------------+--------------+------------+
      | 7 | Broadcast/Multicast Video | Video Source | Subscriber |
      |   | plus Control Channel      |              |            |
      +---+---------------------------+--------------+------------+
      | 8 | Device Management         | Management   | Managed    |
      |   |                           | System       | Device     |
      +---+---------------------------+--------------+------------+
        

Where:

ただし:

      RAN: Radio Access Network       NC: Network Controller
      BS: Base Station                PTP: Precision Time Protocol
      BNG: Broadband Network Gateway
        

Table 1: E-Tree Use Cases

表1:Eツリーの使用例

Common to all use cases, direct Layer 2 leaf-to-leaf communication is required to be prohibited. For mobile backhaul, this may not be valid for Long Term Evolution (LTE) X2 interfaces; an LTE X2 interface [LTE] enables communication between two evolved Node Bs (eNBs). E-Tree service is appropriate for such use cases.

すべての使用例に共通して、直接のレイヤー2リーフ間通信を禁止する必要があります。モバイルバックホールの場合、これはLong Term Evolution(LTE)X2インターフェイスでは有効でない場合があります。 LTE X2インターフェース[LTE]は、2つの発展型ノードB(eNB)間の通信を可能にします。 E-Treeサービスは、このような使用例に適しています。

Also common to the use cases mentioned above, there may be one or multiple Root ACs in one E-Tree service. The need for multiple Root ACs may be driven by a redundancy requirement or by having multiple serving sites. Whether a particular E-Tree service needs to support one or multiple Root ACs depends on the application.

上記の使用例にも共通して、1つのE-Treeサービスに1つまたは複数のルートACが存在する場合があります。複数のルートACの必要性は、冗長性要件によって、または複数のサービスサイトを持つことによって推進されます。特定のE-Treeサービスが1つまたは複数のルートACをサポートする必要があるかどうかは、アプリケーションによって異なります。

5. L2VPN Gaps for Emulating MEF E-Tree Service
5. MEF EツリーサービスをエミュレートするためのL2VPNギャップ

The MEF E-Tree service defines special forwarding rules that prohibit forwarding Ethernet frames among leaves. This poses some challenges to IETF L2VPN solutions such as VPLS and EVPN in emulating E-Tree service over an MPLS network. There are two major issues described in the following subsections.

MEF E-Treeサービスは、リーフ間でのイーサネットフレームの転送を禁止する特別な転送ルールを定義します。これは、MPLSネットワークを介したE-Treeサービスのエミュレーションにおいて、VPLSやEVPNなどのIETF L2VPNソリューションにいくつかの課題をもたらします。次のサブセクションで説明する2つの主要な問題があります。

5.1. No Differentiation on AC Role
5.1. ACの役割に違いはありません

IP/MPLS L2VPN architecture has no distinct roles on Attachment Circuits (ACs) and supports any-to-any connectivity among all ACs. It does not have any mechanism to support forwarding constraints based on an AC role. However, the MEF E-Tree service defines two AC roles -- Root and Leaf -- and defines the forwarding rules based on the originating and receiving AC roles of a given frame.

IP / MPLS L2VPNアーキテクチャは、接続回路(AC)に明確な役割を持たず、すべてのAC間のAny-to-Any接続をサポートします。 ACロールに基づく転送制約をサポートするメカニズムはありません。ただし、MEF E-Treeサービスは、ルートとリーフの2つのACロールを定義し、特定のフレームの発信および受信ACロールに基づいて転送ルールを定義します。

5.2. No AC Role Indication or Advertisement
5.2. ACロールの表示または広告なし

In an L2VPN, when a PE, say PE2, receives a frame from another PE, say PE1, over the MPLS core, PE2 does not know if the frame from PE1 is originated from a Root AC or Leaf AC. This causes the forwarding issue on PE2 because the E-Tree forwarding rules require that the forwarder must know the role of the frame origin, i.e., from Root AC or Leaf AC. This is specifically important when PE2 has both Root AC and Leaf AC attached to the VSI. E-Tree forwarding rules apply to all types of frames (known unicast destination, unknown unicast destination, multicast, and broadcast).

L2VPNでは、PE、たとえばPE2がMPLSコアを介して別のPE、たとえばPE1からフレームを受信すると、PE2は、PE1からのフレームがルートACまたはリーフACから発信されたものかどうかを認識しません。 Eツリー転送ルールでは、フォワーダーがフレームの起点の役割を、つまりルートACまたはリーフACから知る必要があるため、PE2で転送の問題が発生します。これは、PE2にVACに接続されているルートACとリーフACの両方がある場合に特に重要です。 Eツリー転送ルールは、すべてのタイプのフレーム(既知のユニキャスト宛先、不明なユニキャスト宛先、マルチキャスト、およびブロードキャスト)に適用されます。

5.3. Other Issues
5.3. その他の問題

Some desirable requirements for IETF E-Tree are specific to an IP/MPLS L2VPN implementation such as Leaf-only PE. A Leaf-only PE is a PE that only has Leaf AC(s) in an E-Tree service instance; thus, other PEs on the same E-Tree service instance do not necessarily forward the frames originated from a Leaf AC to the Leaf-only PE, which may save some network resources. It is also desirable for an E-Tree solution to work with existing PEs that support single-role ACs, where the role is equivalent to the root in an E-Tree service. These requirements are described in the E-Tree requirement document [RFC7152].

IETF Eツリーのいくつかの望ましい要件は、リーフのみのPEなどのIP / MPLS L2VPN実装に固有です。リーフのみのPEは、EツリーサービスインスタンスにリーフACのみを持つPEです。したがって、同じE-Treeサービスインスタンス上の他のPEは、必ずしもリーフACから発信されたフレームをリーフのみのPEに転送するとは限らず、ネットワークリソースを節約できる場合があります。また、E-Treeソリューションは、役割がE-Treeサービスのルートと同等である、単一の役割のACをサポートする既存のPEと連携することが望ましいです。これらの要件は、Eツリー要件ドキュメント[RFC7152]で説明されています。

6. Security Considerations
6. セキュリティに関する考慮事項

An E-Tree service may be deployed for security reasons to prohibit communication among sites (leaves). An E-Tree solution must enforce E-Tree forwarding constraints. The solution must also guarantee that Ethernet frames do not leak outside of the E-Tree service instance to which they belong.

Eツリーサービスは、サイト(リーフ)間の通信を禁止するために、セキュリティ上の理由で展開される場合があります。 E-Treeソリューションは、E-Tree転送制約を適用する必要があります。ソリューションは、イーサネットフレームが、それらが属するE-Treeサービスインスタンスの外部にリークしないことも保証する必要があります。

An E-Tree service prohibits communication among leaf sites but does not have knowledge of higher-layer security constraints. Therefore, in general, higher-layer applications cannot rely on E-Tree to provide security protection unless all security constraints are fully implemented by the E-Tree service.

E-Treeサービスは、リーフサイト間の通信を禁止しますが、上位層のセキュリティ制約の知識はありません。したがって、一般に、上位層アプリケーションは、すべてのセキュリティ制約がE-Treeサービスによって完全に実装されていない限り、E-Treeに依存してセキュリティ保護を提供することはできません。

Enhancing L2VPN for E-Tree services inherits the same security issues described in the L2VPN framework document [RFC4664]. These relate to both control-plane and data-plane security issues that may arise in the following areas:

E-TreeサービスのL2VPNの拡張は、L2VPNフレームワークドキュメント[RFC4664]で説明されているのと同じセキュリティ問題を継承します。これらは、次の領域で発生する可能性のあるコントロールプレーンとデータプレーンの両方のセキュリティ問題に関連しています。

o issues fully contained in the provider network

o プロバイダーネットワークに完全に含まれる問題

o issues fully contained in the customer network

o 顧客ネットワークに完全に含まれる問題

o issues in the customer-provider interface network

o カスタマープロバイダーインターフェイスネットワークの問題

The framework document has substantial discussions on the security issues and potential solutions to address them. An E-Tree solution must consider these issues and address them properly. VPLS [RFC4761] [RFC4762] and/or EVPN [EVPN] will likely be candidate solutions for an E-Tree service over an MPLS network. The security capabilities built into those solutions will be naturally adopted when supporting E-Tree. For details, see the Security Considerations sections in [RFC4761], [RFC4762], and [EVPN].

フレームワークドキュメントは、セキュリティ問題とそれらに対処するための潜在的な解決策について実質的な議論があります。 E-Treeソリューションはこれらの問題を考慮し、適切に対処する必要があります。 VPLS [RFC4761] [RFC4762]またはEVPN [EVPN]、あるいはその両方が、MPLSネットワーク上のE-Treeサービスの候補ソリューションになる可能性があります。これらのソリューションに組み込まれたセキュリティ機能は、E-Treeをサポートする際に自然に採用されます。詳細については、[RFC4761]、[RFC4762]、および[EVPN]のセキュリティに関する考慮事項のセクションを参照してください。

7. References
7. 参考文献
7.1. Normative References
7.1. 引用文献

[MEF6.1] Metro Ethernet Forum, "Ethernet Services Definitions - Phase 2", MEF 6.1, April 2008.

[MEF6.1] Metro Ethernet Forum、「Ethernet Services Definitions-Phase 2」、MEF 6.1、2008年4月。

[MEF10.3] Metro Ethernet Forum, "Ethernet Service Attributes - Phase 3", MEF 10.3, October 2013.

[MEF10.3]メトロイーサネットフォーラム、「イーサネットサービス属性-フェーズ3」、MEF 10.3、2013年10月。

[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006, <http://www.rfc-editor.org/info/rfc4664>.

[RFC4664] Andersson、L.、Ed。およびE. Rosen、Ed。、 "Framework for Layer 2 Virtual Private Networks(L2VPNs)"、RFC 4664、2006年9月、<http://www.rfc-editor.org / info / rfc4664>。

[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.

[RFC4761] Kompella、K.、Ed。、and Y. Rekhter、Ed。、 "Virtual Private LAN Service(VPLS)Using BGP for Auto-Discovery and Signaling"、RFC 4761、April 2007、<http:// www。 rfc-editor.org/info/rfc4761>。

[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.

[RFC4762] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol(LDP)シグナリングを使用した仮想プライベートLANサービス(VPLS)」、RFC 4762、2007年1月、<http:// www。 rfc-editor.org/info/rfc4762>。

[RFC7152] Key, R., Ed., DeLord, S., Jounay, F., Huang, L., Liu, Z., and M. Paul, "Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN)", RFC 7152, March 2014, <http://www.rfc-editor.org/info/rfc7152>.

[RFC7152] Key、R.、Ed。、DeLord、S.、Jounay、F.、Huang、L.、Liu、Z。、およびM. Paul、「Metro Ethernet Forum(MEF)Ethernet-Tree(E -Tree)Support in Layer 2 Virtual Private Network(L2VPN)」、RFC 7152、2014年3月、<http://www.rfc-editor.org/info/rfc7152>。

7.2. Informative References
7.2. 参考引用

[IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area", IEEE Std 802.1Q, 2011.

[IEEE802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control(MAC)Bridges and Virtual Bridged Local Area」、IEEE Std 802.1Q、2011。

[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588, July 2008.

[IEEE1588] IEEE、「IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems」、IEEE Std 1588、2008年7月。

[LTE] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)", 3GPP TS 36.300 v11.2.0, July 2012.

[LTE] 3GPP、「Evolved Universal Terrestrial Radio Access(E-UTRA)and Evolved Universal Terrestrial Radio Access Network(E-UTRAN)」、3GPP TS 36.300 v11.2.0、2012年7月。

[TR-101] Broadband Forum, "Migration to Ethernet-Based Broadband Aggregation", TR-101 Issue 2, July 2011.

[TR-101]ブロードバンドフォーラム、「イーサネットベースのブロードバンド集約への移行」、TR-101発行2、2011年7月。

[VPMS] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D., and L. Jin, "Framework and Requirements for Virtual Private Multicast Service (VPMS)", Work in Progress, draft-ietf-l2vpn-vpms-frmwk-requirements-05, October 2012.

[VPMS]カミテY、ジュナイF、ニベンジェンキンスB、ブルガード、D、ジン、「仮想プライベートマルチキャストサービス(VPMS)のフレームワークと要件」、作業中、ドラフト- ietf-l2vpn-vpms-frmwk-requirements-05、2012年10月。

[EVPN] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", Work in Progress, draft-ietf-l2vpn-evpn-11, October 2014.

[EVPN] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、J。Uttaro、「BGP MPLSベースのイーサネットVPN」、作業中、draft-ietf-l2vpn-evpn -11、2014年10月。

Acknowledgments

謝辞

The authors would like to thank Nabil Bitar and Adrian Farrel for their detailed review and suggestions.

著者は、詳細なレビューと提案を提供してくれたNabil BitarとAdrian Farrelに感謝します。

Contributors

貢献者

The following people contributed significantly to this document.

以下の人々がこの文書に大きく貢献しました。

Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118, Japan

ゆじ かみて んっt こっむにかちおんs こrぽらちおん Gらんぱrk とうぇr 3ー4ー1 しばうら、 みなとーく ときょ 108ー8118、 じゃぱん

   EMail: y.kamite@ntt.com
        

Wim Henderickx Alcatel-Lucent Copernicuslaan 50 2018 Antwerp, Belgium

Wim Henderickx Alcatel-Lucent Copernicuslaan 50 2018アントワープ、ベルギー

   EMail: wim.henderickx@alcatel-lucent.com
        

Authors' Addresses

著者のアドレス

Raymond Key (editor)

レイモンド・キー(編集者)

   EMail: raymond.key@ieee.org
        

Lucy Yong (editor) Huawei USA

Lucy Yong(編者)hu A is USA

   EMail: lucy.yong@huawei.com
        

Simon Delord Telstra

サイモンデロードテルストラ

   EMail: simon.delord@gmail.com
        

Frederic Jounay Orange CH 4 rue caudray 1020 Renens Switzerland

Frederic Jounay Orange CH 4 rue caudray 1020 Renensスイス

   EMail: frederic.jounay@orange.ch
        

Lizhong Jin

私は一種のジン

   EMail: lizho.jin@gmail.com