Network Working Group                                       David
Independent Submission                                         D. Melman
Internet Draft                                               Tal
Request for Comments: 6847                                    T. Mizrahi
Intended status:
Category: Informational                                          Marvell
Expires: May 2013                                        Donald
ISSN: 2070-1721                                              D. Eastlake
                                                                  Huawei
                                                        November 7, 2012

                              FCoE
                                                            January 2013

                Fibre Channel over TRILL
                        draft-mme-trill-fcoe-05.txt Ethernet (FCoE) over
          Transparent Interconnection of Lots of Links (TRILL)

Abstract

   Fibre Channel over Ethernet (FCoE) and 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 MAC Media Access Control (MAC) addresses
   at each hop.  This document describes an architecture for the
   integrated deployment of these two protocols.

Status of this This Memo

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

   This is submitted a contribution to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents RFC Series, independently of the Internet Engineering
   Task Force (IETF), any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its areas, discretion and makes no statement about its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid value for a maximum of six months
   and may be updated, replaced,
   implementation or obsoleted deployment.  Documents approved for publication by other documents at
   the RFC Editor are not a candidate for any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 7, 2013.
   http://www.rfc-editor.org/info/rfc6847.

Copyright Notice

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

   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.

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 ....................................... 6 .................................... 5
         3.2.1. FCRB ............................................... 6 5
         3.2.2. Topology ........................................... 8 7
         3.2.3. The FCRB Flow ..................................... 10  8
            3.2.3.1. Example - ENode to ENode ..................... 10  8
               3.2.3.1.1. Forwarding from A to C - in Dense Mode ..... 10 ....  9
               3.2.3.1.2. Forwarding from A to C - in Sparse Mode .... 11 ...  9
            3.2.3.2. Example - ENode to Native FC Node ............ 12 10
            3.2.3.3. Example - ENode to ENode with non-FCRB Non-FCRB EoR ... 12 10
            3.2.3.4. Example - FCoE Control Traffic through an FCRB 13 11
   4. Security Considerations ..................................... 14 12
   5. IANA Considerations ......................................... 14
   6. Acknowledgments ............................................. 14
   7. 12
   6. References .................................................. 15
      7.1. 12
      6.1. Normative References ................................... 15
      7.2. 12
      6.2. Informative References ................................. 15 12

1.  Introduction

   Data center networks are rapidly evolving towards a consolidated
   approach, where 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), where in which native Fibre Channel (FC) FC packets are encapsulated with an
   FCoE encapsulation over an Ethernet header.  FCoE is specified in [FC-BB-5]
   [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.)

   Traffic between two FCoE end nodes (ENodes) is forwarded through one
   or more FCoE Forwarders (FCF). (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 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.

   TRILL [RFCTRILL] [TRILL] is a protocol for transparent least cost least-cost routing, where RBridges
   Routing Bridges (RBridges) forward traffic to their destination based
   on a least
   cost least-cost route, using a TRILL encapsulation header.  RBridges
   route TRILL-
   encapsulated TRILL-encapsulated packets based on the Egress egress RBridge Nickname 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,
   RBridge and decrementing a Hop Count field.

   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 per-
   hop basis.  Each of the protocols uses its own routing protocol
   rather than using any type of bridging protocol protocol, such as the spanning
   tree protocol [802.1Q] or the Shortest Path Bridging protocol [802.1aq].
   [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

   DCB     Data Center Bridging

   ENode   FCoE Node such as server or storage array

   EoR     End of Row

   FC      Fibre Channel

   FCF     Fibre Channel     FCoE Forwarder

   FCoE    Fibre Channel over Ethernet

   FCRB    Fibre Channel forwarder    FCF over RBridge

   FIP     FCoE Initialization Protocol

   FSPF    Fabric Shortest Path First

   LAN     Local Area Network

   RBridge Routing Bridge
   SAN     Storage Area Network

   ToR     Top of Rack

   TRILL   Transparent Interconnection of Lots of Links

   WAN     Wide Area Network

3.  FCoE over TRILL

3.1.  FCoE over a TRILL Cloud

   The simplest approach for running FCoE traffic over a TRILL network
   is presented in Figure 1.  The figure illustrates a TRILL-enabled
   network, where 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
            |   |________/
            |   |
            +---+
            Server
          (ENode B)

                  Figure 1 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 [TRILLDCB]. [TRILLPFC]
   [TRILLCN].

   The main drawback drawbacks of the Separate Cloud approach is are that RBridges
   and FCFs are separate nodes in the network, resulting in more cabling
   and boxes, and that communication between ENodes usually requires two
   traversing the TRILL cloud traversals with twice, so there are twice as many hops.
   As mentioned above, data center networking is converging towards a
   consolidated and cost
   effective cost-effective approach, where the same
   infrastructure and equipment is 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.

   The Separate Cloud approach is presented as a background and
   motivation. The next section introduces to clarify the
   motivation to develop an alternative approach with a higher level of
   integration.

3.2.  FCoE over an RBridge

3.2.1.  FCRB

   Rather than using the Separate Cloud approach discussed in the previous
   subsection, 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, FCRB and its main building blocks.  An FCRB
   can be functionally viewed as two independent entities:

   o An FCoE Forwarder (FCF) entity.

   o An RBridge entity.

   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 in this document slightly differently
   than defined in [FC-BB-5], [FC-BB-5] to emphasize the concept that an FCRB is
   logically similar to an RBridge cascaded to an FCF.  In the [FC-BB-5]
   terminology,
   terminology defined in [FC-BB-5], an FCRB would be referred to as an
   FCF, and the "FCF" FCF building block in Figure 2 would be referred to as a
   an FC switching element.

                          +-------------------+
                          |FCRB               |
                          |   +-----------+   |    Native FC
                          |   |    FCF    |------  Interface
                          |   +-----+-----+   |
                          |         |         |
                          |   +-----+-----+   |
                          |   |  RBridge  |   |
                          |   +-+-+---+-+-+   |
                          |     | |   | |     |
                          +-----|-|---|-|-----+
                 FCoE/          / |   | |
      +---+    Ethernet        /  /   | | FCoE / Ethernet
      |   |___________________/  /    | | over TRILL      ___   _
      |   |                     /     | |                /   \_/ \__
      +---+                    /      | \_____________ _/           \
   FCoE Storage               /       \_______________/    TRILL    /
      Array                  /                        \_   Cloud   /
    (ENode A)               /                          /           \
                           /                           \__/\_   ___/
      +---+               /                                  \_/
      |   |______________/
      |   |
      +---+
      Server
    (ENode B)

                    Figure 2 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.

   It is noted

   Note that FCoE traffic is always forwarded through an FCF, 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

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

      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

   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 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 3. FCoE over RBridge Topology
   Note that in the example in Figure 3 3, all the ToR, EoR 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 where in which FCRBs
   are interconnected through TRILL clouds.

3.2.3.  The FCRB Flow

3.2.3.1.  Example - ENode to ENode

   FCoE traffic sent between the two ENodes, ENodes A and B in Figure 3, 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.

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

   Figure 4 illustrates the traffic between ENodes A and C that 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.

 +--------+     +--------+     +--------+     +--------+     +--------+
 | 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 4. Traffic between two ENodes - Example

3.2.3.1.1.  Forwarding from A to C - in Dense Mode

   o  FCoE traffic from A is sent to the ToR 1 over the Ethernet interface.
      The destination MAC address is the address of the FCF entity at the ToR.
      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  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, forwarding layer.  The FCF entity at the
            ToR forwards the packet to the FCF entity in the EoR.

         o  The FCF then updates the destination MAC address of the
            packet to the address of the 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  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 point, the forwarding process is similar to
      the one described above for the ToR.

   o  A similar forwarding process takes place at the next hop next-hop ToR FCRB,
      where the FCRB finally forwards the FCoE packet to the target target,
      ENode C.

3.2.3.1.2.  Forwarding from A to C - in Sparse Mode

   o  Traffic is forwarded to ToR 1, as described in Section 3.2.3.1.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  The packet reaches the EoR.  The RBridge entity in the EoR routes
      the packet to the RBridge entity in ToR 2.

   o  The packet reaches ToR 2, and from 2.  From this point on on, the process is
      identical to the one described in Section 3.2.3.1.1.

3.2.3.2.  Example - ENode to Native FC Node

+--------+     +--------+     +--------+     +---------+     +--------+
|  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 5. Example of Traffic between an
                  ENode & and a Native FC Storage Array

   Figure 5 illustrates a second example, where traffic is sent between
   an ENode and an FC Storage Array, following 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
      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.

3.2.3.3.  Example - ENode to ENode with non-FCRB Non-FCRB EoR

   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 |     |        |
+--------+     +--------+     +--------+     +--------+     +--------+
|Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet|<===>|Ethernet|
+--------+     +--------+     +--------+     +--------+     +--------+
  Server          ToR 1          EoR            ToR 2      FCoE Storage
  ENode A         FCRB           FCRB           FCRB          Array
                                                             ENode C

            Figure 6 6. Example of Traffic between two Two ENodes - Example
   An FCoE packet sent from ENode A to C is forwarded as follows:

   o  The packet is sent to the FCF in ToR 1, as in the previous
      example.

   o  The FCF in ToR 1 takes a forwarding decision based on the FC
      addresses,
      addresses and forwards the packet to the next hop next-hop FCF, which
      resides in ToR 2.  This forwarding decision is taken at the FCF
      layer,
      layer and is based on the FSPF routing protocol.

   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  Once the packet reaches ToR 2, it is forwarded in a similar manner
      to the description in Section 3.2.3.1.

   This example demonstrates that it is possible to have a hybrid
   network, where in which some of the nodes are FCRBs, 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.

3.2.3.4.  Example - FCoE Control Traffic through an FCRB

   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 (FIP), (i.e., FIP), distributing routing information (FSPF), (i.e., FSPF),
   and fabric
   administration administering and management. managing fabric.

   The FCoE Initialization Protocol (FIP) uses Ethernet frames with a
   dedicated Ethertype, allowing the FCF to distinguish it 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:

   o  ENode A generates a multicast frame to a multicast MAC address
      representing
      that represents all the FCFs (All-FCF-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  Each of the FCRBs in turn then receives the packet, forwards a copy to its
      FCF entity, as well as forwarding and forwards the packet through the TRILL network,
      allowing all the FCFs to receive the packet.

   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

   For general TRILL Security Considerations security considerations, see [RFCTRILL]. [TRILL].

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

   There are no additional security implications imposed by this
   document.

5. IANA Considerations

   There are no IANA actions required by this document.

   RFC Editor: please delete this section before publication.

6.  Acknowledgments

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

   This document was prepared using 2-Word-v2.0.template.dot.

7. input.

6.  References

7.1.

6.1.  Normative References

   [RFCTRILL]

   [TRILL]    Perlman, R., Eastlake, Eastlake 3rd, D., Dutt, D., Gai, S., and A.
              Ghanwani, A., "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, July 2011.

   [FC-BB-5]  ANSI INCITS 462: Information "Information Technology - Fibre Channel -
              Backbone - 5 (FC-BB-5).

7.2. (FC-BB-5)", May 2010.

6.2.  Informative References

   [802.1Q]   "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks", IEEE
                 Std 802.1Q-2011, May 2011.

   [802.1aq]     "IEEE Standard for Local and metropolitan area
                 networks -
              Media Access Control (MAC) Bridges and Virtual Bridged
              Local Area Networks - Shortest Path
                 Bridging", Networks", IEEE Std 802.1aq-2012, June 802.1Q(tm), 2012 Edition,
              October 2012.

   [TRILLDCB]

   [TRILLPFC] Eastlake, 3rd., D., Wadekar, M., Ghanwani, A., Agarwal,
              P., and T. Mizrahi, T., "TRILL: Support of IEEE 802.1Qbb,
                 802.1Qaz, 802.1
              Priority-based Flow Control and Enhanced Transmission
              Selection", 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", draft-
                 eastlake-trill-rbridge-dcb, work Work in progress, 2012. Progress, January 2013.

Authors' Addresses

   David Melman
   Marvell
   6 Hamada St.
   Yokneam, 20692 Israel

   Email:

   EMail: davidme@marvell.com

   Tal Mizrahi
   Marvell
   6 Hamada St.
   Yokneam, 20692 Israel

   Email:

   EMail: talmi@marvell.com

   Donald Eastlake 3rd
   Huawei USA R&D
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-333-2270
   EMail: d3e3e3@gmail.com