FCoCEE Tutorial 07-343v1
Suresh Vobbilisetty Brocade
Abstract: This document provides a technical tutorial about the FCoCEE proposal.
1
Table of Contents
1 INTRODUCTION..................................................................................................... 3 1.1 1.2 1.3 2 3 4 5 6 7 8 9 HOW DOES THIS WORK: ........................................................................................ 5 MULTI SWITCH AND MULTI-FABRIC DEPLOYMENTS.............................................. 7 ZONING CONFIGURATION .................................................................................. 10
COST-PERFORMANCE....................................................................................... 12 SCALABILITY....................................................................................................... 12 SECURITY.............................................................................................................. 12 RELIABILITY, AVAILABILITY, SERVICEABILITY (RAS)........................ 13 5.1 FCOCEE ECHO REQUEST, ECHO RESPONSE ...................................................... 13 MANAGEABILITY ............................................................................................... 14 ARCHITECTURE.................................................................................................. 14 SAMPLE USE CASE ............................................................................................. 17 BENEFITS............................................................................................................... 19
Figure 1: FLOGI frames from the XN_Port to the FCoCEE Switch.................................. 6 Figure 2 FLOGI LS_ACC from the XF_Port to XN_Port ................................................. 6 Figure 3 Single FCoCEE and FC Fabric with FSPF routing .............................................. 8 Figure 4 Dual redundant FCoCEE and FC fabrics with FSPF ........................................... 9 Figure 5 Frame flow in a multi switch model with VE Ports in the path ......................... 11 Figure 6 Basic architectural model of FCE Switch .......................................................... 15 Figure 7 Directly Connected Model Figure 8 Indirectly connected Model................. 17
2
1 Introduction
The FCoCEE proposal can be summed up as follows:
N NL E XN XF FL
FC FC
VE VE
FCoCEE FCoCEE
F
E
FC
FCoCEE
FC
FC
FC
FCoCEE-SW FC Routing FC Services
FC
FC
FC
FC
FCoCEE
FC
FCoCEE
FC
FCoCEE
FCoCEE Switch
Definition of terms and concepts: • An FCoCEE switch is defined with FCoCEE_Ports and FC_Ports o An FCoCEE switch is an FC Switch with an FCoCEE Entity at each FCoCEE_Port. o An FCoCEE switch can have 2 or more FCoCEE_Ports. o It can also have 0 or more FC_Ports. FCoCEE_Ports are FC_Ports with CEE Interfaces: o They can be either XF_Ports or VE_Ports. o XN_Ports, XF_Ports and VE_Ports have a MAC Address as an additional attribute. Otherwise, they are same as N_Ports, F_Ports and E_Ports respectively. This MAC address is maintained in the Name Server for management purposes. o Each FCoCEE_Ports has an additional FCoCEE Entity XN_Port – A FC N-Port implementation on cHBA. Also referred to as FCoCEE N_Port in T11/07-292v1. XF_Port – A FC F-Port implementation on one of the FCoCEE switch ports. Also referred to as FCoCEE F_Port in T11/07-292v1. VE Port – A VE port defined in FC-BB-4, without the TCP, IP and other connection management functionality. 3
•
• • •
• •
• • •
FCoCEE Entity at the port provides: o Encapsulation and De-encapsulation of FC frames and FCoCEE frames XN_Ports connect to XF_Ports o Fabric assigns an XF_Port to an XN_Port when they are not connected directly. o An XN_Port can connect to a CEE fabric that connects to an XF_Port. VE_Ports connect to VE_Ports. FCoCEE switches can be connected together to form FCoCEE fabrics. FCoCEE switches can also be connected to FC SANs to join existing FC fabrics.
4
1.1 How does this work:
Here is a brief summary: 1. XN_Port sends its first FLOGI as a multi-cast. o The XN_Port uses it’s globally assigned MAC address as SA. o It uses an IEEE-SA assigned Multicast Group address for the F_Port controller as the DA. The F_Port Controllers’ FC WKA is 0xFFFFFE. 2. FCoCEE Switch(s) receives the FLOGI on one or more XF_Ports. o Technically, the FCoCEE Switch ports start out as G_Ports and start the transition into XF_Ports upon receiving these multicast frames from an XN_Port. 3. FCoCEE Fabric assigns one XF_Port for this XN_Port. o The actual assignment process is implementation dependent. These could be policy driven and the XN to XF relationship be expressed using the respective WWNs. Each FCoCEE Switch can co-ordinate with other FCoCEE switches over VE ports and share this policy information. This co-ordination will ensure that only one XF_Port is assigned for an XN_Port for a fabric There will be no need to specify this policy and/or the inter FCoCEE co-ordination when the XN_Port is directly attached to a FCoCEE switch. The switch port that XN_Port is directly attached to becomes the XF_Port for this XN_Port (this is similar to how it works today with N_Ports connected to FC switches). o The assigned XF_Port responds with FLOGI LS_ACC. The LS_ACC contains the FC address identifier for the XN_Port. This is a unicast response with XF_Ports’ MAC address as the SA and the XN_Port’s MAC address as the DA. 4. XN_Port receives the FLOGI LS_ACC from the assigned XF_Port. From this point on the XN_Port will talk to the assigned XF_Port for all communication. It may then send an FDISC to the XF_Port to support a virtualized server environment without any more multicasting. 5. Once, the FLOGI processing is done, the data path continues this way: • Traffic can come in on an XF_Port and go out on another XF_Port or an F_Port depending on the destination Area ID field of the FC address identifier • Traffic can come in on an XF_Port and go out on a VE_Port or an E_Port again depending on the Domain ID field of the FC address identifier. • In both cases, the forwarding is dictated by FSPF. 6. As mentioned before, FCoCEE Switches connect to other FCoCEE Switches via VE_Ports or E_Ports. • FSPF does inter switch routing. • The same destination domain can be reachable via a VE_Port or an E_Port. Link Cost will take care of which path to pick (this is similar to how this would work for FCIP ISLs). Note: There could be a CEE Switch between the XN_Port and XF_Port. The multi-cast scheme will still work for XF_Port assignment. See figure 1: 5
H1 XN_Port
1 CEE Network 2
3
FCoCEE Switch p1 p2 p3 4
Figure 1: FLOGI frames from the XN_Port to the FCoCEE Switch
1. XN_Port’s initial FLOGI request. a. IEEE MAC Header: i. DA = F_Port Controller’s Well Known Multicast Group Address (TBD). ii. SA = H1’s Globally assigned MAC address b. Encapsulated FC Header: i. D_ID = FF.FF.FE ii. S_ID = 00.00.00 2. The CEE Network forwards this multicast Ethernet frame to the appropriate entities in the network that have registered for F_Port controller’s group address. 3. Ports p1 and p2 receive and forward the frames to the F_Port Controller on the FCoCEE Switch. p1 and p2 each have a Globally Assigned IEEE MAC address. 4. FCoCEE-SW uses pre-determined configuration and decides to assign p1 as the port that will respond to this FLOGI. Note that if H1 is directly connected to one of the three ports, then the attached port is the XF_Port that will be assigned. There will be no extra configuration required when the H1 is directly connected to the switch.
H1 XN
7 CEE Network 6
5 XF
FCoCEE Switch p1 p2 p3
Figure 2 FLOGI LS_ACC from the XF_Port to XN_Port
6
5. The FLOGI LS_ACC is sent out as follow: a. IEEE MAC Header: i. DA = H1’s global MAC address ii. SA = XF_Port’s global uni-cast MAC address. b. Encapsulated FC Header: i. D_ID = 01.01.00 ii. S_ID = FF.FF.FE 6. The CEE Network forwards this frame to H1 as the network in Step 2 learned this address, above. 7. H1 receives the LS_ACC and learns its XF_Port MAC address from the received frame. 8. XN_Port uses the XF_Port’s MAC address in all subsequent communications. a. Note: If XN_Port is NPIV capable, then all subsequent FDISC requests are sent to the same XF_Port’s MAC address as the destination. The source MAC address is also the same as what had been used for the initial FLOGI request.
1.2 Multi switch and multi-fabric deployments
Definition of terms in the following pictures: • • • • • cHBA - A converged IO HBA implementing FCoCEE with a CEE MAC Dual HBA Server – A standard server with two cHBAs. CEE Port – A IEEE MAC 802.3 host port with proposed CEE enhancements CEE Switches – IEEE 802.3Q Ethernet Bridge with the proposed CEE enhancements. CEE Cloud – A network of one or more CEE switches.
The following two figures illustrate how FCoCEE switches can be introduced into existing SAN installations. Figure 3 illustrates how multiple FCoCEE switches can be connected to form an FCoCEE fabric via one or more VE ports. The FCoCEE fabric joins the existing fabric via E-Ports. Figure 4 illustrates the same concepts in a typical dual-fabric configuration. Figures 3 and 4 illustrate the simultaneous connectivity of F_Port attached storage (N1 & N2) and native FCoCEE storage (XN3 & XN4). Note that the FCoCEE Switches join the existing FC fabrics via the VE ports and E Ports and any/all existing configuration in the existing FC fabric is conveyed to the FCoCEE Switches using standard FC-GS protocols. This includes the Zoning configuration in the existing fabrics.
7
Dual HBA Server #1
Server #2
MPIO
cHBA
CEE M3 Port XN1
cHBA
CEE M4 Port XN2
cHBA
CEE M5 Port XN3
CEE Cloud (Switch1)
XF1 Assigned for M3 FCoCEE Switch #1 (FSPF)
XF2 Assigned for M4 AND M5 FCoCEE Switch #2 (FSPF)
VE3
VE4
VE1
VE2
VE5
VE6
FCoCEE
CEE Cloud
VE7
VE8
VE11 VE9 VE10
VE12
FCoCEE Switch #3 (FSPF)
FCoCEE Switch #4 (FSPF)
E1
XF3 XN3 XN4
XF4
E2
Data
FCoCEE Storage Platform E3 FC Fabric A F3 F1 N1 F2 N2 N3 Management Station E4
Data FC Storage Platform
Figure 3 Single FCoCEE and FC Fabric with FSPF routing
8
Blade Server Chassis Dual HBA Server Dual HBA Server
MPIO
cHBA
M3 CEE Port XN1
cHBA
M4 CEE Port XN2
CEE Cloud (Switch1)
CEE Cloud (Switch2)
XF1 Assigned for M3 FCoCEE Switch #1 (FSPF) VE1 VE2
XF2 Assigned for M4 FCoCEE Switch #2 (FSPF) VE5 VE6
CEE Cloud
VE7
VE8
VE11
VE12
FCoCEE Switch #4 (FSPF) E1 XF3 XN3 XN4
FCoCEE Switch #3 (FSPF) XF4 E2 Data
FCoCEE Storage Platform E3 FC Fabric A F1 N1 Data N2 E4 FC Fabric B F2 F3
FC Storage Platform
N3 Management Station
Figure 4 Dual redundant FCoCEE and FC fabrics with FSPF
9
1.3 Zoning Configuration
Zoning configuration for FCoCEE devices can be defined on FCoCEE Switches or on existing the FC switches in the FC fabrics. That zoning configuration is distributed and is made available to all the other switches within the fabric as defined by FC-GS defined Zoning rules. Port WWN based zoning configuration for both Figure 3 and Figure 4 are defined as below: cHBA connected to FC storage FCoCEE_FC_Zone1: (XN1_WWNP, N1_WWNP) FCoCEE_FC_Zone2 (XN2_WWNP, N2_WWNP) cHBA connected to native FCoCEE storage FCoCEE_only_Zone1: (XN1_WWNP, XN3_WWNP) FCoCEE_only_Zone2: (XN2_WWNP, XN4_WWNP) cHBA connected to FC storage and native FCoCEE storage using single-initiator zoning FCoCEE_only_Zone1: (XN1_WWNP, N1_WWNP, XN3_WWNP) FCoCEE_only_Zone2: (XN2_WWNP, N2_WWNP, XN4_WWNP)
10
An example frame flow in a multi-switch configuration is shown in figure 5.
H1
1 XN1 CEE Network
XF1 VE1
H1 FC_ID 01.01.00
CEE Network 2
VE3
F
N
T2
Domain = 1
Domain = 3
VE2
XF2
3
XN2
T1
Domain = 2
T1 FC_ID 02.01.00
1
:
2
:
Dest Src
3
:
Dest Global-MAC (XF1) Src Global-MAC (H1)
Dest Global-MAC (VE2) Src Global-MAC (VE1) Encaps. FC frame D_ID = 02.01.00 S_ID = 01.01.00
Global-MAC (XN2) Global-MAC (XF2)
Encaps. FC frame D_ID = 02.01.00 S_ID = 01.01.00
Encaps. FC frame D_ID = 02.01.00 S_ID = 01.01.00
Figure 5 Frame flow in a multi switch model with VE Ports in the path
Assumptions in the above picture: • XF1 is Area1 (or port1) on an FCoCEE switch with Domain ID 1. • XF2 is also Area1 (or port1) on an FCoCEE switch Domain ID 2.
11
2 Cost-Performance
One of the primary goals for FCoCEE is cost-effective connectivity between FCoCEE Initiators and FC SAN storage. This requires the boundary between the two networks have the highest performance possible. The encapsulation allows for cut-through protocol translation in the FC to FCoCEE direction by not requiring a “length” field. Having a “length” field in the protocol forces all implementations to wait until the entire frame is received before the transmission can begin. Requiring a store-and-forward behavior adds to the complexity of the switching ASIC design when the ingress is FC and the egress is FCoCEE. An FC_Port would normally be operating in a cut-through mode when it’s forwarding to another FC_Port, but it would have to be in a store-and-forward mode when it’s forwarding to another FCoCEE port. While cut-through and store-andforward behaviors can exist on a single ASIC, implementing different behaviors on a per port basis adds to the cost and complexity of the switching design. As a result we propose a frame format that supports cut-through.
3 Scalability
Maintaining the separation of the FC Address space and Ethernet Address space affords topological flexibility and improves the scalability of the network in a converged environment. 1. The FCoCEE technology does not impose any new requirements on IEEE 802.3 MAC. FCoCEE storage deployments do not increase the number of MAC addresses in the network or the number of VLANs that need to be managed. The approach requires no VLAN management in a pure storage deployment. 2. The addressing scheme allows for all the FC fabric topologies that end-users expect: • VLAN tags are not required in the FCoCEE frame. This allows the technology to operate in a non-VLAN environment. • The FCoCEE technology allows for simple one-to-one VLAN to VF mapping. This mapping does not require the deployment of IVLs (Independent VLAN Learning). • The FCoCEE technology allows multiple Virtual Fabrics to reside inside a single VLAN (many-to-one mapping). (See Section 5 (RAS). Therefore, FCoCEE fabrics can scale the same way that FC fabrics do today. This scaling does not require any additional VLAN management.
4 Security
The FCoCEE approach preserves the MAC address burned into the end-nodes. Since this does not change even when FCoCEE is enabled, any and all MAC based authentication and security systems may be used unchanged. IEEE 802.1X security applies to CEE links and FC-SP security applies between XN_Ports and XF_Ports. FC-SP can be skipped and
12
instead 802.1X, with its richer security framework, may be applied when XN_Ports are directly connected. Since multicasting based approaches are inherently not secure means of communicating and not all Ethernet gear completely manages multicast security, the FCoCEE design goal has been to avoid multicast based discovery mechanisms if there was a unicast alternative that met the requirements. Multicast frames are only used to allow XN_Ports to discover their XF_Ports. All other communication is authenticated and unicast. FCoCEE allows per VF FC-SP authentication as part of independent VF negotiation. This is essential in a non point-to-point connectivity scenario to prevent spoofing of already authenticated MAC or WWN by another device.
5 Reliability, Availability, Serviceability (RAS)
FCoCEE defines mechanisms to detect accessibility between XN-Ports and XF-Ports in cases where they are not directly attached. A multicast based discovery process initiated by each XN_Port ensures that all potential XF_Ports receive the initial FLOGI from the XN_Port. The fabric assigns the right XF_Port from the available XF_Ports. Therefore, only one F_Port is assigned for each physical fabric. If the XN_Port is connected to multiple physical fabrics through a common CEE fabric, then it’s possible that it receives one response from each of these separate fabrics. When an XN_Port receives multiple FLOGI LS_ACCs, it may pick the first one it receives and continue with that XF_Port. It could alternatively: • Decide to stop all processing FLOGI processing and invoke alert mechanisms to inform the administrator to make remedial steps. One remedial action could be to ensure all the fabrics are consistently configured or deploy VLANs to isolate the individual fabrics such that only one fabric responds back to the XN_Port. • Use the WWNN in the FLOGI LS_ACC response. This WWNN is the Node Name of the Principal Switch in each fabric. XN_Port can perform multiple FLOGIs, one per fabric. This would aid in multi path deployments and provide a new of dimension of scalability (one cHBA—to-many Fabrics). This optional extension could impact the cHBA device driver stack.
5.1 FCoCEE Echo Request, Echo Response
This is an extension that has been considered for inclusion in T11/07-292v1. The “type” field in the FCoCEE Header can be used to define a new FCoCEE frame. This feature aids in accessibility tests. It can be invoked by the XN_Port to test access to a specific XN_Port. It can also be implemented on an FCoCEE switch to test accessibility between two connected devices. This will also aid in HA and fail-over scenarios when the XN_Port and its assigned XF_Port are not directly attached. If the assigned XF_Port ever goes down (in a planned shutdown scenario) the fabric will initiate an ECHO Request to all the affected XN_Ports 13
indicating the new XF_Port’s MAC address they can use. This, of course, assumes that there is a network path between the new XF_Port to the XN_Port. The XN_Port can chose to perform a graceful shutdown of any outstanding exchanges and migrate it’s fabric connection to the newly assigned XF_Port. This capability is named “XF_Port reassignment”. Accessibility can be periodically verified using a “Link Keep Alive” ELS defined in FCLS.
6 Manageability
A primary goal of FCoCEE has been to require no additional FC related management at the Ethernet layer when FC is layered on the top. The proposal does not require any VLANs to be configured on the hosts or the switches, but does allow them to be configured if desired for other reasons. The proposal preserves the discovery, connectivity, fabric partitioning, security and change management practices currently utilized in FC SANs and extends these for FCoCEE devices. Management of FCoCEE devices is the same as the management of FC devices using all previously defined storage management interfaces (including FAL, SNMP, WebTools, Fabric Manager and CLI).
7 Architecture
CEE is treated as a pure Layer2 transport and the FC protocol is treated as a L3 protocol. One of the key characteristics of this architectural separation is the separation of L2 address space from the L3 address space i.e., the separation of how L2 MAC addresses are allocated and managed from how FC address identifiers are allocated and managed. This address space separation is similar to how MAC addresses are managed in relation to the IP addresses in traditional TCP/IP protocol architectures. Even when IP is layered on top of Ethernet, IP routing continues to rely on IP addresses. This separation allows for building efficient and scalable, and IETF defined, IP networks. This way IP routing is constrained by L2 Ethernet forwarding. Conversely, Ethernet forwarding protocols rely only the MAC addresses and IEEE 802.1Q defined forwarding protocols. This allows for Ethernet to be a generic L2 transport independent of the L3 protocol layered on top. Any L3 awareness at Ethernet layer denies the benefits of Ethernet’s generality for that L3 protocol. One key goal of FCoCEE is to define a functional model (illustrated in T11/07-292v1) that brings the architectural separation, and the associated benefits as described above, common in traditional LAN protocols. The proposed T11 standard defines only a FC forwarding device. This is the minimum functionality one would need to perform FCoCEE forwarding as shown in figure 7.
14
Inter Fabric Routing IFR for FCoCEE Traffic
L3
Fabric1 (VF-1) (FC-SW Forwarding)
Fabric-2 (VF-2) (FC-SW Forwarding)
P1
P2
P3
P4
P6
P7
P8
P9
MAC
MAC
MAC
MAC
FC Port
MAC
MAC
MAC
MAC
MAC MAC
Enet MAC FC MAC
FCoCEE Entity
FCoCEE Switch with 9 FCoCEE front-end ports (with FC front-end ports)
Figure 6 Basic architectural model of FCE Switch
This model in figure 6 illustrates the entity relationship between various components in the context of virtual fabrics. • • • • • The solid boundary represents a FCoCEE switch. The FCoCEE switch contains nine physical ports exposed in the front. Eight of the physical ports (green rectangles) are Ethernet with standard IEEE 802.3 MAC on each of the ports. For each physical Ethernet port there is one corresponding logical FC port. One physical port (red rectangle) is a Fibre Channel port implementing FC-PHY. The Ethernet ports have additional functionality attached to them. This additional functionality is the FCoCEE Entity. The FCoCEE Entity ties each physical Ethernet port to its logical FC port. The functional responsibility of this FCoCEE Entity is to encapsulate/de-capsulate FCoCEE frames to/from FC frames. FC
15
• • • •
Frames coming from the logical FC port are encapsulated and are then sent out on the corresponding Ethernet port. Conversely, FCoCEE frames coming from the Ethernet port are de-capsulated before they are placed on the corresponding logical FC ports. The standard FC-SW forwards the FC frames it receives from the logical FC ports. The FCoCEE Switch also contains a physical FC port. This FC port conforms to standard FC protocols and behaves as standard FC port. The lines shown above (both solid and dashed) express the containment relationships between the ports and their associated Virtual Fabrics they participating in. Port4 and Port6, and the physical FC port are configured to be in VF1 and VF2. The corresponding XF_Ports will include these two virtual fabrics ids as part of the EVFP exchange with the XN_Ports. A standard VF capable XN_Port negotiates these virtual fabric memberships with these XF_Ports and initializes one logical XN_Port per virtual fabric as described in Section 8 of FC-LS standard.
16
8 Sample Use Case
• • • Number of cHBAs: Number of Virtual Fabrics: Number of cHBAs in each Fabric: 600 6 100
The following configuration steps need to be performed with FCoCEE proposal. 1. Type of VLANs required: Protocol based VLANs. • In protocol based VLANs, the Ethernet frames are classified based on the “EType” value. This is a switch wide configuration, i.e., the configuration applies to all ports. 2. Number of VLANs required: 1 • One VLAN for “all” FCoCEE traffic: VID1 • Note: The cHBA is free to tag the frames accordingly, but this is not a standard practice, since this requires configuring each end node. It’s best if the VLAN tagging is left to the first hop switch. • Also note that all switches in the CEE cloud need to be configured this way. FCoCEE Virtual Fabrics:
H1 H2 H3
...
H600
H1
H2
H3
...
H600
CEE Network FCoCEE Fabric1
...
FCoCEE Fabric6 FCoCEE Fabric1
...
FCoCEE Fabric6
Data
Data
Figure 7 Directly Connected Model
Figure 8 Indirectly connected Model
3. Configure which FCoCEE switch ports need to participate in which Virtual Fabric (VF). This assigns specific XF_Ports to specific VFs. 4. Configure which XN_Port needs to be assigned to which XF_Port. This automatically ties the specific XN_Port to the VF configured for the XF_Port. This step can be skipped in the directly connected model as shown in figure 7.
17
• •
•
In the indirectly connected model, as shown in figure 8 above, the XN_Ports will receive one FLOGI LS_ACC response from each FCoCEE fabric. Each FLOGI LS_ACC response will have a distinct principal switch WWNN. The XN_Ports have the following two choices: I. It can perform a LOGO and alert the administrator to take a remedial action. The remedial action could be to deploy more VLANs to segregate both the FLOGI requests and the responses and there-by ensure only one FLOGI response is received by a single XN_Port. II. It can proceed to accept the FLOGI LS_ACC. This XN_Port now has multiple logical connections through the CEE Network to the FCoCEE fabrics. The FCoCEE proposal does not force an administrative task of assigning a VF for each VLAN to avoid multiple FLOGI response issue.
XN_Port FLOGI: 5. The initial FLOGI is multicast in FCoCEE VLAN: VID2. • This will contain the VF Bit set to 1 (as described in FC-IFR) • All FCoCEE switch ports participating in this VLAN receive this frame. If there are multiple FCoCEE switches, configuration in Step 3 and Step 4 is assumed to be consistent across all the FCoCEE switches. 6. XF_Port assignment works as configured in Step 4 7. The XF_Port responds with LS_ACC as defined in FC-IFR 8. VF negotiation i.e., EVFP exchange, and the subsequent VF tagged FLOGI between the XN_Port and the XF_Port continues as defined in FC-IFR. In cases where both CEE switching and FCoCEE switching are implemented in a single package, both VLAN and VF configuration happens on the same switch, but the VLAN configuration for basic Ethernet traffic and the VF configuration is for the storage traffic. Also note that if the same packaging contains FC switches, the VF configuration is common for FCoCEE cHBAs and FC HBAs. We recommend that the cHBAs be directly connected to the FCoCEE switches. But, there is no difference to the actual configuration steps described above whether the cHBAs are directly connected to the FCoCEE switches or connected to them via a CEE cloud. The only difference is “where” the configuration is applied. If there is a CEE cloud in between, then all 802.1Q (VLAN, Spanning Tree etc.,) configurations happen on the CEE switches in the CEE cloud and the VF, XF/XN configuration happens on the FCoCEE switches.
18
9 Benefits
• The FCoCEE proposal preserves the customer’s investment in FC SAN hardware, software, and administrative practices. The proposal provides the customer an evolutionary approach to managing future investments in FC and Ethernet server IO infrastructure. FC and Ethernet will evolve in speed, protocols, and features somewhat independently. FCoE gives the customer the freedom to choose the best solution for the application at the time of deployment. The need to rip and replace networking infrastructure will be minimized. The FCoCEE switch model allows for XN_Port connectivity into existing FC SANs through XF_Ports and, if desired, through VE_Ports for ISLs. Standard FC routing services and switch-based services may route SAN traffic on VE_Port ISLs or on existing E_Port ISLs. The switch resident FC services are the same services used for FC devices in multiprotocol, heterogeneous deployments. The testing and qualification for both FC and FCoCEE devices can be performed at the same time using common switch software. The proposal does not require HBA devices to implement VLAN management and Ethernet frames tagging. The first hop switch can implement this function using standard VLAN management practice. FCoCEE Entities may provide RA_TOV enforcement services allowing FC switches with internal enforcement of Fibre Channel timeout protocols to operate transparently with Ethernet attached devices. The FCoCEE proposal provides additional diagnostics capabilities that HBA vendors can add as a value add service. The FCoCEE architecture provides for automatically steering XN_Ports to new XF_Ports using the basic echo request/reply mechanism above. An XN_Port destines its frames to its XF_Port’s MAC address. In cases where this XF_Port goes away, and/or is known to be going away, FCoCEE Echo Request/Reply can be used to steer the XN_Port to a different XF_Port provided there is connectivity.
•
• • • • • •
19