Independent Submission                                         D. Melman
Request for Comments: 6847                                    T. Mizrahi
Category: Informational                                          Marvell
ISSN: 2070-1721                                          D. Eastlake 3rd
                                                            January 2013

Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL)




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.


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


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 ( 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トラストの法的規定(の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

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
   Example - ENode to ENode .....................  8
      Forwarding from A to C in Dense Mode ....  9
      Forwarding from A to C in Sparse Mode ...  9
   Example - ENode to Native FC Node ............ 10
   Example - ENode to ENode with Non-FCRB EoR ... 10
   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
1. Introduction
1. はじめに

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].


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.


2. Abbreviations
2. 略語

DCB Data Center Bridging


ENode FCoE Node such as server or storage array

サーバーやストレージアレイなどのENode FCoEノード

EoR End of Row

EoR End of Row

FC Fibre Channel


FCF FCoE Forwarder

FCF FCoEフォワーダー

FCoE Fibre Channel over Ethernet

FCoE Fibre Channel over Ethernet

FCRB FCF over RBridge


FIP FCoE Initialization Protocol

FIP FCoE初期化プロトコル

FSPF Fabric Shortest Path First


LAN Local Area Network


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


WAN Wide Area Network


3. FCoE over TRILL
3. FCoE over TRILL
3.1. FCoE over a TRILL Cloud
3.1. TRILLクラウド上のFCoE

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.


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.


            |   |_________
            |   |         \  ___   _
            +---+          \/   \_/ \__                  _   __
         FCoE Storage     _/           \                / \_/  \_
            Array        /    TRILL    /       +---+    \_       \
          (ENode A)      \_   Cloud   /________|   |____/  SAN  _/
                          /           \        |   |    \__   _/
                          \__/\_   ___/        +---+       \_/
            +---+         /     \_/             FCF
            |   |________/
            |   |
          (ENode B)

Figure 1. The "Separate Cloud" Approach


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.


3.2. FCoE over an RBridge
3.2. RBridgeを介したFCoE
3.2.1. FCRB
3.2.1. FCRB

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).


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.


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)               /                          /           \
                           /                           \__/\_   ___/
      +---+               /                                  \_/
      |   |______________/
      |   |
    (ENode B)

Figure 2. FCRB Entity in the Network


The FCRB entity maintains layer independence between the TRILL and FCoE protocols, while enabling both protocols on the same network.


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.


3.2.2. Topology
3.2.2. トポロジー
   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.2.3. The FCRB Flow
3.2.3. FCRBフロー Example - ENode to ENode 例-ENodeからENode

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:


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 |     |        |
 +--------+     +--------+     +--------+     +--------+     +--------+
 +--------+     +--------+     +--------+     +--------+     +--------+
   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間のトラフィック-例 Forwarding from A to C in Dense Mode 密モードでのAからCへの転送

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に転送します。 Forwarding from A to C in Sparse Mode スパースモードでのAからCへの転送

o Traffic is forwarded to ToR 1, as described in Section

o セクション3.で説明されているように、トラフィックは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

o パケットはToR 2に到達します。この時点から、プロセスはセクション3.で説明したプロセスと同じです。 Example - ENode to Native FC Node 例-ENodeからネイティブFCノードへ
+--------+     +--------+     +--------+     +---------+     +--------+
|  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.


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

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ノードに転送されます。 Example - ENode to ENode with Non-FCRB EoR 例-FCNode EoR以外のENodeからENode

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.


+--------+     +--------+                    +--------+     +--------+
| FCoE   |.....|  FCF   |....................|  FCF   |.....| FCoE   |
| ENode  |     +--------+     +--------+     +--------+     | ENode  |
|        |     |RBridge |.....|RBridge |.....|RBridge |     |        |
+--------+     +--------+     +--------+     +--------+     +--------+
+--------+     +--------+     +--------+     +--------+     +--------+
  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

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

この例は、ノードの一部がFCRBであり、ノードの一部がRBridgeであるハイブリッドネットワークを持つことが可能であることを示しています。この例の転送手順は、セクション3.で説明されているスパースモード転送に多少似ています。 Example - FCoE Control Traffic through an FCRB 例-FCRBを介したFCoE制御トラフィック

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.


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

For general TRILL security considerations, see [TRILL].


For general FCoE security considerations, see Annex D of [FC-BB-5].


There are no additional security implications imposed by this document.


5. Acknowledgments
5. 謝辞

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が有益な情報を提供してくれたことに感謝します。

6. References
6. 参考文献
6.1. Normative References
6.1. 引用文献

[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月。

6.2. Informative References
6.2. 参考引用

[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


Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel

Tal Mizrahi Marvell 6 Hamada St. Yokneam、20692 Israel


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