[要約] RFC 6847は、Fibre Channel over Ethernet (FCoE)をTransparent Interconnection of Lots of Links (TRILL)上で実現するためのプロトコルを定義しています。このRFCの目的は、FCoEとTRILLの統合により、データセンターネットワークの効率性と柔軟性を向上させることです。
Independent Submission D. Melman
Request for Comments: 6847 T. Mizrahi
Category: Informational Marvell
ISSN: 2070-1721 D. Eastlake 3rd
Huawei
January 2013
Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL)
多数のリンクの透過的な相互接続（TRILL）を介したファイバーチャネルオーバーイーサネット（FCoE）
Abstract
概要
Fibre Channel over Ethernet (FCoE) and Transparent Interconnection of Lots of Links (TRILL) are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's Media Access Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols.
ファイバーチャネルオーバーイーサネット（FCoE）と透過的な相互リンクのリンク（TRILL）は、データセンター環境における2つの新しい標準です。これら2つのプロトコルは一見無関係であるように見えますが、どちらもイーサネットを介してホップバイホップ転送を実行し、各ホップでパケットのメディアアクセス制御（MAC）アドレスを変更するため、転送プレーンで非常によく似た動作をします。このドキュメントでは、これら2つのプロトコルの統合展開のアーキテクチャについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6847.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6847で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ................................................. 2
2. Abbreviations ................................................ 3
3. FCoE over TRILL .............................................. 4
3.1. FCoE over a TRILL Cloud ................................. 4
3.2. FCoE over an RBridge .................................... 5
3.2.1. FCRB ............................................... 5
3.2.2. Topology ........................................... 7
3.2.3. The FCRB Flow ..................................... 8
3.2.3.1. Example - ENode to ENode ..................... 8
3.2.3.1.1. Forwarding from A to C in Dense Mode .... 9
3.2.3.1.2. Forwarding from A to C in Sparse Mode ... 9
3.2.3.2. Example - ENode to Native FC Node ............ 10
3.2.3.3. Example - ENode to ENode with Non-FCRB EoR ... 10
3.2.3.4. Example - FCoE Control Traffic through an FCRB 11
4. Security Considerations ..................................... 12
5. Acknowledgments ............................................. 12
6. References .................................................. 12
6.1. Normative References ................................... 12
6.2. Informative References ................................. 12
Data center networks are rapidly evolving towards a consolidated approach, in which Ethernet is used as the common infrastructure for all types of traffic. Storage traffic was traditionally dominated by the Fibre Channel (FC) protocol suite. At the intersection between these two technologies a new technology was born, Fibre Channel over Ethernet (FCoE), in which native FC packets are encapsulated with an FCoE encapsulation over an Ethernet header. FCoE is specified in [FC-BB-5]. (A future version of FCoE is under development and is expected to be specified in a document to be referred to as FC-BB-6; however, this is a work in progress and is beyond the scope of this document.)
データセンターネットワークは、イーサネットがすべてのタイプのトラフィックの共通インフラストラクチャとして使用される統合アプローチに向けて急速に進化しています。ストレージトラフィックは、従来、ファイバーチャネル（FC）プロトコルスイートが主流でした。これら2つのテクノロジーの交点で、新しいテクノロジーであるFibre Channel over Ethernet（FCoE）が生まれました。このテクノロジーでは、ネイティブFCパケットがイーサネットヘッダー上のFCoEカプセル化でカプセル化されます。 FCoEは[FC-BB-5]で指定されています。 （FCoEの将来のバージョンは開発中であり、FC-BB-6と呼ばれるドキュメントで指定される予定ですが、これは進行中の作業であり、このドキュメントの範囲を超えています。）
Traffic between two FCoE end nodes (ENodes) is forwarded through one or more FCoE Forwarders (FCFs). An FCF takes a forwarding decision based on the Fibre Channel destination ID (D_ID), and enforces security policies between ENodes, also known as zoning. Once an FCF takes a forwarding decision, it modifies the source and destination MAC addresses of the packet, to reflect the path to the next-hop FCF or ENode. An FCoE virtual link is an Ethernet link between an ENode and an FCF, or between two FCFs. An FCoE virtual link may traverse one or more Layer 2 bridges. FCFs use a routing protocol called Fabric Shortest Path First (FSPF) to find the optimal path to each destination. An FCF typically has one or more native Fibre Channel interfaces, allowing it to communicate with native Fibre Channel devices, e.g., storage arrays.
2つのFCoEエンドノード（ENode）間のトラフィックは、1つ以上のFCoEフォワーダー（FCF）を介して転送されます。 FCFは、ファイバーチャネルの宛先ID（D_ID）に基づいて転送の決定を行い、ゾーニングとも呼ばれるENode間にセキュリティポリシーを適用します。 FCFが転送の決定を行うと、パケットの送信元および宛先MACアドレスを変更して、ネクストホップFCFまたはENodeへのパスを反映します。 FCoE仮想リンクは、ENodeとFCFの間、または2つのFCFの間のイーサネットリンクです。 FCoE仮想リンクは、1つ以上のレイヤー2ブリッジを通過できます。 FCFは、Fabric Shortest Path First（FSPF）と呼ばれるルーティングプロトコルを使用して、各宛先への最適なパスを見つけます。通常、FCFには1つ以上のネイティブファイバーチャネルインターフェイスがあり、ストレージアレイなどのネイティブファイバーチャネルデバイスと通信できます。
TRILL [TRILL] is a protocol for transparent least-cost routing, where Routing Bridges (RBridges) forward traffic to their destination based on a least-cost route, using a TRILL encapsulation header. RBridges route TRILL-encapsulated packets based on the egress RBridge nickname in the TRILL header. An RBridge routes a TRILL-encapsulated packet after modifying its MAC addresses to reflect the path to the next-hop RBridge and decrementing a Hop Count field.
TRILL [TRILL]は、透過的な最小コストルーティング用のプロトコルです。ルーティングブリッジ（RBridges）は、TRILLカプセル化ヘッダーを使用して、最小コストルートに基づいてトラフィックを宛先に転送します。 RBridgeは、TRILLヘッダーの出力RBridgeニックネームに基づいてTRILLカプセル化パケットをルーティングします。 RBridgeは、MACアドレスを変更してネクストホップRBridgeへのパスを反映し、ホップカウントフィールドをデクリメントした後、TRILLカプセル化パケットをルーティングします。
TRILL and FCoE bear a strong resemblance in their forwarding planes. Both protocols take a routing decision based on protocol addresses above Layer 2, and both modify the Ethernet MAC addresses on a per-hop basis. Each of the protocols uses its own routing protocol rather than using any type of bridging protocol, such as the spanning tree protocol [802.1Q] or the Shortest Path Bridging protocol [802.1Q].
TRILLとFCoEは、フォワーディングプレーンに非常によく似ています。どちらのプロトコルも、レイヤー2より上のプロトコルアドレスに基づいてルーティングの決定を行い、両方のホップでイーサネットMACアドレスを変更します。各プロトコルは、スパニングツリープロトコル[802.1Q]や最短パスブリッジプロトコル[802.1Q]など、あらゆるタイプのブリッジプロトコルを使用するのではなく、独自のルーティングプロトコルを使用します。
FCoE and TRILL are both targeted at the data center environment, and their concurrent deployment is self-evident. This document describes an architecture for the integrated deployment of these two protocols.
FCoEとTRILLはどちらもデータセンター環境を対象としており、同時展開は自明です。このドキュメントでは、これら2つのプロトコルの統合展開のアーキテクチャについて説明します。
DCB Data Center Bridging
DCBデータセンターブリッジング
ENode FCoE Node such as server or storage array
サーバーやストレージアレイなどのENode FCoEノード
EoR End of Row
EoR End of Row
FC Fibre Channel
FCファイバーチャネル
FCF FCoE Forwarder
FCF FCoEフォワーダー
FCoE Fibre Channel over Ethernet
FCoE Fibre Channel over Ethernet
FCRB FCF over RBridge
RBridge上のFCRB FCF
FIP FCoE Initialization Protocol
FIP FCoE初期化プロトコル
FSPF Fabric Shortest Path First
FSPFファブリックの最短パスが最初
LAN Local Area Network
LANローカルエリアネットワーク
RBridge Routing Bridge SAN Storage Area Network
RBridge Routing Bridge SANストレージエリアネットワーク
ToR Top of Rack
ToR Top of Rack
TRILL Transparent Interconnection of Lots of Links
多くのリンクのTRILL透過的な相互接続
WAN Wide Area Network
WANワイドエリアネットワーク
The simplest approach for running FCoE traffic over a TRILL network is presented in Figure 1. The figure illustrates a TRILL-enabled network, in which FCoE traffic is transparently forwarded over the TRILL cloud. The figure illustrates two ENodes, a Server and an FCoE Storage Array, an FCF, and a native Fibre Channel SAN connected to the FCF.
TRILLネットワークを介してFCoEトラフィックを実行するための最も単純なアプローチを図1に示します。この図は、TRILL対応ネットワークを示しています。このネットワークでは、FCoEトラフィックがTRILLクラウドを介して透過的に転送されます。この図は、2つのENode、サーバーとFCoEストレージアレイ、FCF、およびFCFに接続されたネイティブファイバーチャネルSANを示しています。
FCoE traffic between the two ENodes is sent from the first ENode over the TRILL cloud to the FCF, and then back through the TRILL cloud to the second ENode.
2つのENode間のFCoEトラフィックは、TRILLクラウドを介して最初のENodeからFCFに送信され、次にTRILLクラウドを経由して2番目のENodeに戻ります。
+---+
| |_________
| | \ ___ _
+---+ \/ \_/ \__ _ __
FCoE Storage _/ \ / \_/ \_
Array / TRILL / +---+ \_ \
(ENode A) \_ Cloud /________| |____/ SAN _/
/ \ | | \__ _/
\__/\_ ___/ +---+ \_/
+---+ / \_/ FCF
| |________/
| |
+---+
Server
(ENode B)
Figure 1. The "Separate Cloud" Approach
図1.「個別のクラウド」アプローチ
The configuration in Figure 1 separates the TRILL cloud(s) and the FCoE cloud(s). The TRILL cloud routes FCoE traffic as standard Ethernet traffic, and appears to the ENodes and FCF as an Ethernet LAN. FCoE traffic routed over the TRILL cloud includes FCoE data frames, as well as FCoE control traffic, including FCoE Initialization Protocol (FIP) frames. To eliminate frame loss due to queue overflow, the switches in any TRILL Cloud used with FCoE would likely implement and use the relevant DCB protocols [TRILLPFC] [TRILLCN].
図1の構成は、TRILLクラウドとFCoEクラウドを分離しています。 TRILLクラウドはFCoEトラフィックを標準のイーサネットトラフィックとしてルーティングし、ENodeおよびFCFからはイーサネットLANとして認識されます。 TRILLクラウドを介してルーティングされるFCoEトラフィックには、FCoEデータフレームと、FCoE初期化プロトコル（FIP）フレームを含むFCoE制御トラフィックが含まれます。キューのオーバーフローによるフレームの損失をなくすために、FCoEで使用されるTRILLクラウドのスイッチは、関連するDCBプロトコル[TRILLPFC] [TRILLCN]を実装して使用する可能性があります。
The main drawbacks of the Separate Cloud approach are that RBridges and FCFs are separate nodes in the network, resulting in more cabling and boxes, and that communication between ENodes usually requires traversing the TRILL cloud twice, so there are twice as many hops. As mentioned above, data center networking is converging towards a consolidated and cost-effective approach, where the same infrastructure and equipment are used for both data and storage traffic, and where high efficiency and minimal number of hops are important factors when designing the network topology.
セパレートクラウドアプローチの主な欠点は、RBridgesとFCFがネットワーク内の別のノードであるため、ケーブル接続とボックスが多くなること、およびENode間の通信には通常TRILLクラウドを2回通過する必要があるため、ホップ数が2倍になることです。上記のように、データセンターのネットワーキングは、データトラフィックとストレージトラフィックの両方に同じインフラストラクチャと機器が使用され、ネットワークトポロジを設計するときに高効率と最小ホップ数が重要な要素である、統合された費用効果の高いアプローチに集中しています。 。
The Separate Cloud approach is presented as background to clarify the motivation to develop an alternative approach with a higher level of integration.
セパレートクラウドアプローチは、より高いレベルの統合で代替アプローチを開発する動機を明確にするための背景として提示されています。
Rather than using the Separate Cloud approach discussed in Section 3.1, an alternate approach is presented, where each switch incorporates both an FCF entity and an RBridge entity. This consolidated entity is referred to as FCoE-forwarder-over-RBridge (FCRB).
セクション3.1で説明したセパレートクラウドアプローチを使用する代わりに、各スイッチにFCFエンティティとRBridgeエンティティの両方を組み込む代替アプローチを示します。この統合エンティティは、FCoE-forwarder-over-RBridge（FCRB）と呼ばれます。
Figure 2 illustrates an FCRB and its main building blocks. An FCRB can be functionally viewed as two independent entities:
図2は、FCRBとその主な構成要素を示しています。 FCRBは、機能的に2つの独立したエンティティと見なすことができます。
o An FCoE Forwarder (FCF) entity.
o FCoEフォワーダー（FCF）エンティティ。
o An RBridge entity.
o RBridgeエンティティ。
The FCF entity is connected to one of the ports of the RBridge, and appears to the RBridge as a native Ethernet host. A detailed description of the interaction between the layers is presented in Section 3.2.3.
FCFエンティティは、RBridgeのポートの1つに接続され、RBridgeからネイティブイーサネットホストとして認識されます。レイヤー間の相互作用の詳細な説明は、セクション3.2.3に記載されています。
Note: In this document, the term "FCF" is used slightly differently than defined in [FC-BB-5] to emphasize the concept that an FCRB is logically similar to an RBridge cascaded to an FCF. In the terminology defined in [FC-BB-5], an FCRB would be referred to as an FCF, and the FCF building block in Figure 2 would be referred to as an FC switching element.
注：このドキュメントでは、「FCF」という用語は、[FC-BB-5]で定義されているものとは少し異なり、FCRBがFCFにカスケードされたRBridgeと論理的に類似しているという概念を強調します。 [FC-BB-5]で定義されている用語では、FCRBはFCFと呼ばれ、図2のFCFビルディングブロックはFCスイッチングエレメントと呼ばれます。
+-------------------+
|FCRB |
| +-----------+ | Native FC
| | FCF |------ Interface
| +-----+-----+ |
| | |
| +-----+-----+ |
| | RBridge | |
| +-+-+---+-+-+ |
| | | | | |
+-----|-|---|-|-----+
FCoE/ / | | |
+---+ Ethernet / / | | FCoE / Ethernet
| |___________________/ / | | over TRILL ___ _
| | / | | / \_/ \__
+---+ / | \_____________ _/ \
FCoE Storage / \_______________/ TRILL /
Array / \_ Cloud /
(ENode A) / / \
/ \__/\_ ___/
+---+ / \_/
| |______________/
| |
+---+
Server
(ENode B)
Figure 2. FCRB Entity in the Network
図2.ネットワーク内のFCRBエンティティ
The FCRB entity maintains layer independence between the TRILL and FCoE protocols, while enabling both protocols on the same network.
FCRBエンティティは、TRILLプロトコルとFCoEプロトコルの間のレイヤーの独立性を維持しながら、同じネットワーク上で両方のプロトコルを有効にします。
Note that FCoE traffic is always forwarded through an FCF and cannot be forwarded directly between two ENodes. Thus, FCoE traffic between ENodes A and B in the topology in Figure 1 is forwarded through the path
FCoEトラフィックは常にFCFを介して転送され、2つのENode間で直接転送できないことに注意してください。したがって、図1のトポロジのENode AとBの間のFCoEトラフィックは、パスを介して転送されます。
ENode A-->TRILL cloud-->FCF-->TRILL cloud-->ENode B
As opposed to the topology in Figure 1, the FCF in Figure 2 is adjacent to ENodes A and B. In Figure 2, the FCRB is connected to ENodes A and B, and functions as the edge RBridge that connects these two nodes to the TRILL cloud, as well as the FCF that forwards traffic between these two nodes. Thus, traffic between ENodes A and B in the topology in Figure 2 is forwarded through the path
図1のトポロジーとは異なり、図2のFCFはENode AおよびBに隣接しています。図2では、FCRBはENode AおよびBに接続され、これら2つのノードをTRILLに接続するエッジRBridgeとして機能します。クラウド、およびこれら2つのノード間でトラフィックを転送するFCFです。したがって、図2のトポロジーのENode AとBの間のトラフィックは、パスを介して転送されます。
ENode A-->FCRB-->ENode B
ENode A-> FCRB-> ENode B
Hence, the usage of FCRB entities allows TRILL and FCoE to use common infrastructure and equipment, as opposed to requiring separate infrastructure as shown in the Separate Cloud topology presented in Figure 1.
したがって、FCRBエンティティを使用すると、TRILLとFCoEで共通のインフラストラクチャと機器を使用できるようになります。図1に示す個別のクラウドトポロジに示すように、個別のインフラストラクチャが必要になるのではありません。
The network configuration illustrated in Figure 3 shows a typical
topology of a data center network. Servers are hierarchically
connected through Top-of-Rack (ToR) switches, also known as access
switches, and each set of racks is aggregated through an End-of-Row
(EoR) switch. The EoR switches are aggregated to the core switches,
which may be connected to other clouds, such as an external WAN or a
native FC SAN.
_ __ _ __
/ \_/ \_ / \_/ \_
\_ \ \_ \ ....
/ SAN _/ / WAN _/
\__ _/ \__ _/
\_/ \_/
| |
| |
+------+ +------+
Core | | | |
FCoE over | | | |
RBridge | | | |
(FCRB) +------+ +------+
| \___ ___/ |
| \ / |
| \/ |
EoR +----+_______/\_______+----+
FCoE over | | | |
RBridge | | | |
(FCRB) +----+ +----+
/ \ / \
/ \ / \
ToR +---+ +---+ +---+ +---+
FCoE over | | | | | | | |
RBridge | | | | | | | |
(FCRB) +---+ +---+ +---+ +---+
/ \ / \ / \ / \
/ \ / \ / \ / \
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
Servers/ | | | | | | | | | | | | | | | |
ENodes +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
A B C D E F G H
Figure 3. FCoE over RBridge Topology
図3. FCoE over RBridgeトポロジ
Note that in the example in Figure 3, all the ToR, EoR, and core switches are FCRB entities, but it is also possible for some of the network nodes to be pure RBridges, creating a topology in which FCRBs are interconnected through TRILL clouds.
図3の例では、すべてのToR、EoR、およびコアスイッチがFCRBエンティティであることに注意してください。ただし、一部のネットワークノードを純粋なRBridgeにして、FCRBがTRILLクラウドを通じて相互接続されるトポロジを作成することもできます。
FCoE traffic sent between the two ENodes A and B in Figure 3 is transmitted through the ToR FCRB, since A and B are connected to the same ToR. Traffic between ENodes A and C must be forwarded through the EoR FCRB.
図3の2つのENode AとBの間で送信されるFCoEトラフィックは、AとBが同じToRに接続されているため、ToR FCRBを介して送信されます。 ENode AとCの間のトラフィックは、EoR FCRBを介して転送する必要があります。
The FCoE jargon distinguishes between two deployment modes:
FCoEの専門用語は、2つの展開モードを区別します。
o Sparse mode: an FCoE packet sent between two FCFs may be forwarded over several hops of a Layer 2 network, allowing the underlying Layer 2 network to determine the path between the two FCFs.
o スパースモード：2つのFCF間で送信されるFCoEパケットは、レイヤー2ネットワークのいくつかのホップを介して転送され、基になるレイヤー2ネットワークが2つのFCF間のパスを決定できるようにします。
o Dense mode: each node along the path between two FCFs is also an FCF, and the network is configured such that the forwarding decision at each hop is taken at the FCF layer, allowing the path between the two FCFs to be based on the FSPF routing protocol.
o 高密度モード：2つのFCF間のパスに沿った各ノードもFCFであり、ネットワークは各ホップでの転送の決定がFCFレイヤーで行われるように構成され、2つのFCF間のパスがFSPFルーティングに基づくことができますプロトコル。
Figure 4 illustrates the traffic between ENodes A and C, which are not connected to the same ToR. The following two subsections describe the forwarding procedure in the Dense mode and in the Sparse mode, respectively.
図4は、同じToRに接続されていないENode AとC間のトラフィックを示しています。次の2つのサブセクションでは、それぞれデンスモードとスパースモードでの転送手順について説明します。
+--------+ +--------+ +--------+ +--------+ +--------+
| FCoE |.....| FCF |.....| FCF |.....| FCF |.....| FCoE |
| ENode | +--------+ +--------+ +--------+ | ENode |
| | |RBridge |.....|RBridge |.....|RBridge | | |
+--------+ +--------+ +--------+ +--------+ +--------+
|Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet|
+--------+ +--------+ +--------+ +--------+ +--------+
Server ToR 1 EoR ToR 2 FCoE Storage
ENode A FCRB FCRB FCRB Array
ENode C
Figure 4. Traffic between two ENodes - Example
図4. 2つのENode間のトラフィック-例
o FCoE traffic from A is sent to ToR 1 over the Ethernet interface. The destination MAC address is the address of the FCF entity at ToR 1.
o AからのFCoEトラフィックは、イーサネットインターフェイスを介してToR 1に送信されます。宛先MACアドレスは、ToR 1のFCFエンティティのアドレスです。
o ToR 1:
o ToR 1：
o The packet is forwarded to the FCF entity at the ToR. Thus, forwarding between ENode A and the FCF at the ToR is analogous to forwarding between two Ethernet hosts.
o パケットは、ToRでFCFエンティティに転送されます。したがって、ToRでのENode AとFCF間の転送は、2つのイーサネットホスト間の転送に類似しています。
o The FCF entity at the ToR takes a forwarding decision based on the FC addresses. This decision is based on the FSPF routing protocol at the FCF layer. The FCF entity at the ToR forwards the packet to the FCF entity in the EoR.
o ToRのFCFエンティティは、FCアドレスに基づいて転送の決定を行います。この決定は、FCFレイヤーのFSPFルーティングプロトコルに基づいています。 ToRのFCFエンティティは、パケットをEoRのFCFエンティティに転送します。
o The FCF then updates the destination MAC address of the packet to the address of the EoR FCF.
o 次に、FCFはパケットの宛先MACアドレスをEoR FCFのアドレスに更新します。
o The packet is forwarded to the RBridge entity, where it is encapsulated in a TRILL header, and sent to the RBridge at the EoR over a single hop of the TRILL network.
o パケットはRBridgeエンティティに転送され、そこでTRILLヘッダーにカプセル化され、TRILLネットワークの単一ホップを介してEoRのRBridgeに送信されます。
o The RBridge entity in the EoR FCRB, acting as the egress RBridge, decapsulates the TRILL header and forwards the FCoE packet to the FCF entity. From this point, the forwarding process is similar to the one described above for the ToR.
o EoR FCRB内のRBridgeエンティティは、出力RBridgeとして機能し、TRILLヘッダーのカプセル化を解除し、FCoEパケットをFCFエンティティに転送します。この時点から、転送プロセスは、ToRについて上記で説明したものと同様です。
o A similar forwarding process takes place at the next-hop ToR FCRB, where the FCRB finally forwards the FCoE packet to the target, ENode C.
o 同様の転送プロセスがネクストホップのToR FCRBで行われ、FCRBは最終的にFCoEパケットをターゲットのENode Cに転送します。
o Traffic is forwarded to ToR 1, as described in Section 3.2.3.1.1.
o セクション3.2.3.1.1で説明されているように、トラフィックはToR 1に転送されます。
o The FCF in ToR 1, based on an FSPF forwarding decision, forwards the packet to the FCF in ToR 2. The destination MAC address of the FCoE packet is updated, reflecting the FCF in ToR 2. The RBridge entity in ToR 2 adds a TRILL encapsulation, with an egress RBridge nickname representing ToR 2.
o ToR 1のFCFは、FSPF転送決定に基づいて、パケットをToR 2のFCFに転送します。FCoEパケットの宛先MACアドレスは、ToR 2のFCFを反映して更新されます。ToR2のRBridgeエンティティはTRILLを追加しますカプセル化、ToR 2を表す出力RBridgeニックネーム。
o The packet reaches the EoR. The RBridge entity in the EoR routes the packet to the RBridge entity in ToR 2.
o パケットはEoRに到達します。 EoRのRBridgeエンティティは、ToR 2のRBridgeエンティティにパケットをルーティングします。
o The packet reaches ToR 2. From this point on, the process is identical to the one described in Section 3.2.3.1.1.
o パケットはToR 2に到達します。この時点から、プロセスはセクション3.2.3.1.1で説明したプロセスと同じです。
+--------+ +--------+ +--------+ +---------+ +--------+
| FCoE |.....| FCF |.....| FCF |.....| FCF |.....| FC |
| ENode | +--------+ +--------+ +----+----+ |protocol|
| | |RBridge |.....|RBridge |.....| RB | | | stack |
+--------+ +--------+ +--------+ +----+ FC | | |
|Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Eth | |<===>| |
+--------+ +--------+ +--------+ +----+----+ +--------+
Server ToR EoR Core Native FC
ENode FCRB FCRB FCRB Storage Array
Figure 5. Example of Traffic between an ENode and a Native FC Storage Array
図5. ENodeとネイティブFCストレージアレイ間のトラフィックの例
Figure 5 illustrates a second example, where traffic is sent between an ENode and an FC Storage Array, based on the network topology in Figure 3.
図5は、図3のネットワークトポロジに基づいてENodeとFCストレージアレイの間でトラフィックが送信される2番目の例を示しています。
o FCoE traffic from the ENode is sent to the ToR over the Ethernet interface. The forwarding process through the ToR FCRB and through the EoR is similar to the corresponding steps in Section 3.2.3.1.
o ENodeからのFCoEトラフィックは、イーサネットインターフェイスを介してToRに送信されます。 ToR FCRBおよびEoRを介した転送プロセスは、セクション3.2.3.1の対応する手順と同様です。
o When the packet reaches the core FCRB, the egress RBridge entity decapsulates the TRILL header and forwards the FCoE packet to the FCF entity. The packet is then forwarded as a native FC packet through the FC interface to the native FC node.
o パケットがコアFCRBに到達すると、出力RBridgeエンティティはTRILLヘッダーのカプセル化を解除し、FCoEパケットをFCFエンティティに転送します。その後、パケットはネイティブFCパケットとして、FCインターフェイスを介してネイティブFCノードに転送されます。
The example illustrated in Figure 6 is similar to the one shown in Figure 4, except that the EoR is an RBridge rather than an FCRB.
図6に示す例は、EoRがFCRBではなくRBridgeであることを除いて、図4に示す例と似ています。
+--------+ +--------+ +--------+ +--------+
| FCoE |.....| FCF |....................| FCF |.....| FCoE |
| ENode | +--------+ +--------+ +--------+ | ENode |
| | |RBridge |.....|RBridge |.....|RBridge | | |
+--------+ +--------+ +--------+ +--------+ +--------+
|Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet|
+--------+ +--------+ +--------+ +--------+ +--------+
Server ToR 1 EoR ToR 2 FCoE Storage
ENode A FCRB FCRB FCRB Array
ENode C
Figure 6. Example of Traffic between Two ENodes
図6. 2つのENode間のトラフィックの例
An FCoE packet sent from ENode A to C is forwarded as follows:
ENode AからCに送信されたFCoEパケットは、次のように転送されます。
o The packet is sent to the FCF in ToR 1, as in the previous example.
o 前の例のように、パケットはToR 1のFCFに送信されます。
o The FCF in ToR 1 takes a forwarding decision based on the FC addresses and forwards the packet to the next-hop FCF, which resides in ToR 2. This forwarding decision is taken at the FCF layer and is based on the FSPF routing protocol.
o ToR 1のFCFは、FCアドレスに基づいて転送決定を行い、パケットをToR 2にあるネクストホップFCFに転送します。この転送決定はFCFレイヤーで行われ、FSPFルーティングプロトコルに基づいています。
o The packet is then forwarded to the RBridge entity in ToR 1, where it is encapsulated in a TRILL encapsulation, and forwarded to the RBridge at ToR 2. The packet is routed over the TRILL cloud through the RBridge at the EoR. The path through the TRILL cloud is determined by TRILL's IS-IS routing protocol.
o 次に、パケットはToR 1のRBridgeエンティティに転送され、そこでTRILLカプセル化でカプセル化されて、ToR 2のRBridgeに転送されます。パケットは、EoRのRBridgeを介してTRILLクラウドを介してルーティングされます。 TRILLクラウドを経由するパスは、TRILLのIS-ISルーティングプロトコルによって決定されます。
o Once the packet reaches ToR 2, it is forwarded in a similar manner to the description in Section 3.2.3.1.
o パケットがToR 2に到達すると、セクション3.2.3.1の説明と同様の方法で転送されます。
This example demonstrates that it is possible to have a hybrid network, in which some of the nodes are FCRBs and some of the nodes are RBridges. The forwarding procedure in this example is somewhat similar to the sparse-mode forwarding described in Section 3.2.3.1.2.
この例は、ノードの一部がFCRBであり、ノードの一部がRBridgeであるハイブリッドネットワークを持つことが可能であることを示しています。この例の転送手順は、セクション3.2.3.1.2で説明されているスパースモード転送に多少似ています。
The previous subsections focused on the data plane, i.e., storage data exchanges transported over an FCoE encapsulation. FCoE also requires control and management traffic that is used for initializing sessions (i.e., FIP), distributing routing information (i.e., FSPF), and administering and managing fabric.
前のサブセクションでは、データプレーン、つまりFCoEカプセル化を介して転送されるストレージデータ交換に焦点を当てました。 FCoEには、セッションの初期化（つまり、FIP）、ルーティング情報の配布（つまり、FSPF）、およびファブリックの管理と管理に使用される制御および管理トラフィックも必要です。
The FCoE Initialization Protocol (FIP) uses Ethernet frames with a dedicated Ethertype, allowing the FCF to distinguish these frames from other traffic. FIP uses both unicast and multicast traffic. The following example describes the forwarding scheme of a multicast FIP packet sent through the network depicted in Figure 4:
FCoE初期化プロトコル（FIP）は専用のEthertypeを持つイーサネットフレームを使用するため、FCFはこれらのフレームを他のトラフィックと区別できます。 FIPはユニキャストとマルチキャストの両方のトラフィックを使用します。次の例では、図4に示すネットワークを介して送信されるマルチキャストFIPパケットの転送方式について説明します。
o ENode A generates a multicast frame to a multicast MAC address that represents all the FCFs (All-FCF-MAC).
o ENode Aは、すべてのFCF（All-FCF-MAC）を表すマルチキャストMACアドレスにマルチキャストフレームを生成します。
o The packet is forwarded to the ToR FCRB node. The RBridge entity forwards a copy of the packet to its FCF entity, and also sends the packet through the TRILL cloud as a multicast TRILL encapsulated packet.
o パケットはToR FCRBノードに転送されます。 RBridgeエンティティは、パケットのコピーをFCFエンティティに転送し、マルチキャストTRILLカプセル化パケットとしてTRILLクラウドを介してパケットを送信します。
o Each of the FCRBs then receives the packet, forwards a copy to its FCF entity, and forwards the packet through the TRILL network, allowing all the FCFs to receive the packet.
o 次に、各FCRBはパケットを受信し、そのFCFエンティティにコピーを転送し、TRILLネットワークを介してパケットを転送し、すべてのFCFがパケットを受信できるようにします。
While FIP packets have a dedicated Ethertype and frame format, other types of FCoE control and management frames use the same FCoE encapsulation as FCoE data traffic. Thus, the forwarding scheme for such control traffic is similar to the examples described in the previous subsections, with the exception that these frames can be sent between ENodes, between FCFs, or between ENodes and FCFs.
FIPパケットには専用のEthertypeおよびフレーム形式がありますが、他のタイプのFCoE制御および管理フレームは、FCoEデータトラフィックと同じFCoEカプセル化を使用します。したがって、このような制御トラフィックの転送方式は、これらのフレームをENode間、FCF間、またはENodeとFCF間で送信できることを除いて、前のサブセクションで説明した例と同様です。
For general TRILL security considerations, see [TRILL].
TRILLのセキュリティに関する一般的な考慮事項については、[TRILL]を参照してください。
For general FCoE security considerations, see Annex D of [FC-BB-5].
FCoEのセキュリティに関する一般的な考慮事項については、[FC-BB-5]の付録Dを参照してください。
There are no additional security implications imposed by this document.
このドキュメントによって課される追加のセキュリティの影響はありません。
The authors gratefully acknowledge Ayandeh Siamack and David Black for their helpful comments. The authors also thank the T11 committee for reviewing the document, and in particular Pat Thaler and Joe White for their useful input.
著者は、有益なコメントをしてくれたAyandeh SiamackとDavid Blackに感謝の意を表します。著者はまた、文書をレビューしてくれたT11委員会に感謝します。特に、Pat ThalerとJoe Whiteが有益な情報を提供してくれたことに感謝します。
[TRILL] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[TRILL] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[FC-BB-5] ANSI INCITS 462: "Information Technology - Fibre Channel - Backbone - 5 (FC-BB-5)", May 2010.
[FC-BB-5] ANSI INCITS 462：「情報技術-ファイバーチャネル-バックボーン-5（FC-BB-5）」、2010年5月。
[802.1Q] "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q(tm), 2012 Edition, October 2012.
[802.1Q]「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、IEEE Std 802.1Q（tm）、2012年版、2012年10月。
[TRILLPFC] Eastlake 3rd, D., Wadekar, M., Ghanwani, A., Agarwal, P., and T. Mizrahi, "TRILL: Support of IEEE 802.1 Priority-based Flow Control and Enhanced Transmission Selection", Work in Progress, January 2013.
[TRILLPFC] Eastlake 3rd、D.、Wadekar、M.、Ghanwani、A.、Agarwal、P.、and T. Mizrahi、 "TRILL：Support of IEEE 802.1 Priority-based Flow Control and Enhanced Transmission Selection"、Work in Progress 、2013年1月。
[TRILLCN] Eastlake 3rd, D., Wadekar, M., Ghanwani, A., Agarwal, P., and T. Mizrahi, "TRILL: Support of IEEE 802.1 Congestion Notification", Work in Progress, January 2013.
[TRILLCN] Eastlake 3rd、D.、Wadekar、M.、Ghanwani、A.、Agarwal、P.、and T. Mizrahi、 "TRILL：Support of IEEE 802.1 Congestion Notification"、Work in Progress、2013年1月。
Authors' Addresses
著者のアドレス
David Melman Marvell 6 Hamada St. Yokneam, 20692 Israel
David Melman Marvell 6 Hamada St. Yokneam、20692 Israel
EMail: davidme@marvell.com
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel
Tal Mizrahi Marvell 6 Hamada St. Yokneam、20692 Israel
EMail: talmi@marvell.com
Donald Eastlake 3rd Huawei USA R&D 155 Beaver Street Milford, MA 01757 USA
ドナルドイーストレイク3rd Huawei USA R＆D 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com