Friday, March 7, 2014

Exam - Questions

http://hsi.web.cern.ch/hsi/fcs/spec/exam.htm#b1_3

Erik van der Bij (Erik.van_der_Bij@cern.ch)


Fibre Channel Examination

I have written this document to help me improving my knowledge on Fibre Channel. I started by writing down questions which seem to be reasonable to ask and found the answers afterwards. I allowed myself to use the specification when making the exam.
As I am not a specialist and don't have much practical experience, the information in this document is not necessarily correct; it merely shows my understanding of the Fibre Channel specifications I had at 7 April 1994.
If you find any errors in it, I would appreciate if you send me an e-mail.
Erik (Erik.van_der_Bij@cern.ch)
Updates
21/09/95 Jean-Francois GILLOT found error in 1.1.2. He earned a coffee with it!
Table of Contents

1. Physical and Signaling Interface (FC-PH)
FC-PH version 4.2

1.1 Hierarchy

1.1.1 Which handshakes are performed before the first frame can be sent?

  1. FC-0: In case of Laser Links: Open Fibre Control state machine.
    [Disconnect state, Stop State, Reconnect State, Active State]
    This is to make sure that a laser link when open can be classified as a Safety Class 1 laser product. The protocol works on the level of switching on and off the laser.
  2. FC-1: Receiver and Transmitter state machines.
    These are to achieve bit and word synchronization on a link. It is not a real handshake between the Receiver and Transmitter.
    Transmitter: [Not Enabled, Working, Failure, Open Fibre]
    Receiver: [Reset, Loss-of-Sync, Sync Acquired]
    The methodology to acquire bit and word synchronization is not specified in FC-PH. It works on detection of three Ordered Sets with a Comma character in their leftmost bit positions (Comma character: 7 bits that in the absence of transmission errors cannot appear in any other location of a Transmission Character).
  3. Primitive Sequence Protocol (16.4)
    [NOS: Not-Operational, OLS: Offline Sequence, LR: Link Reset, LRR: Link Reset Response, Operational link]
    The Primitive Sequence Protocol is uses to indicate specific conditions within a Port or conditions encountered by the Receiver logic of a Port. It is based on sending continuously Primitive Sequences (K28.5 + 3 specific words) until a response (at least three times the correct Primitive Sequence received) from the other port is received. The protocol ends with each port sending Idles.

1.1.2 Which handshakes are performed before the first data can be sent?

Fabric login and N-port login. The logins are started by sending a FLOGI or a NLOGI frame in which the payload contains the service parameters. The responses are coming back in ACC frames (LS_Command code of ACC). The logins are done in seperate Exchanges.
In class 1 connections, the first frame must have a frame starting with SOFc1 to open a dedicated connection to the Destination port. The first frame can contain data as well.

1.1.3 Which parameters are exchanged during those handshakes?

The parameters are split up in: Common Service Parameters and Service Parameters for the different classes (23.6).
  1. N-port Common Service Parameters
    1. FC-PH version: lowest and highest
    2. Buffer to buffer credit
    3. Continuously Increasing and/or Random Relative Offset
    4. N-port / F-port
    5. Buffer to buffer Receive Data Field Size
    6. N-port total Concurrent Sequences
    7. Relative Offset by Info Category
    8. R_A_TOV
    9. E_D_TOV
  2. N-port Class Service Parameters
    1. Class validity
    2. Intermix mode
    3. Stacked connect requests
    4. Sequential delivery
    5. Initiator control
      1. X_ID reassignment
      2. Inititial Responder Process_Associator
      3. ACK_0 capable
      4. ACK_N capable
    6. Recipient control
      1. ACK_0 capable
      2. ACK_N capable
      3. X_ID interlock
      4. Error policy support
      5. Categories per Sequence
    7. Receive Data Field Size
    8. Concurrent Sequences
    9. N-port End-to-end Credit
    10. Open Sequences per Exchange

1.1.4 What is an Exchange, what is a Sequence?

An Exchange is the mechanism for coordinating the interchange of information and data between two N_Ports or nodes.
A Sequence is a set of one or more related Data frames transmitted unidirectionally from one N_Port to another. There may be only one Sequence active in an Exchange. However, there may be many Exchanges open between two N_Ports.

1.1.5 How are the ports called in an Exchange and in a Sequence?

Exchange: Originater and Responder
Sequence: Sequence Initiator and Sequence Recipient

1.1.6 What is the Error recovery hierarchy?

Abort Exchange Abort Exchange Protocol-frames
Abort Sequence Abort Sequence Protocol-frames
This is a frame that is sent with the same SEQ_ID as the last frame sent.
Link Reset Link Reset Protocol-primitives
Link Initialization Link Init Protocol-primitives
Link Failure Link Failure Protocol-primitives
Those recovery primitives are going less or further back in the Primitive Sequence protocol. Link Failure is the worst, Link Reset is the most gentle recovery in the hierarchy (see 4.15).
Back to Table Of Contents

1.2 Sequence Qualifier

1.2.1 What is the Sequence_Qualifier?

S_ID, D_ID, OX_ID, RX_ID, SEQ_ID.
  • S_ID (Source Identifier) gets assigned by the fabric at fabric login if the fabric supports it, otherwise it is known implicitly.
  • D_ID (Destination Identifier) see S_ID, but sent by Source. (23.4.1): Can be collected from - the fabric; - a name server; - implicit definition.
  • OX_ID (Originator Exchange ID) is filled in by the Originator. FFFF means that the field is not used. Note that FFFF is not allowed in the FCSI profiles.
  • RX_ID (Responder Exchange ID) (18.10), OX_ID, but responder fills it in. RX_ID is set to FFFF by the Originator. RX_ID gets filled in when the first ACK frame gets filled in by the Responder (see X_ID interlock 23.6.8.4). RX_ID may be FFFF if not used in the FCSI profiles.
  • SEQ_ID (Sequence ID), gets assigned by the Sequence Initiator.

1.2.2 Which fields in the Sequence_Qualifier change and when?

All fields are fixed for a given Sequence. All but RX_ID are known by the Originator at the start of the Sequence. RX_ID will be known after reception of the first ACK.

1.2.3 Which fields in the frame header exist and when do they change?

  • Fields in the Sequence_Qualifier, see above.
  • R_CTL, Routing control: can change within a Sequence (18.2). It can change if several information categories are sent within a Sequence. During login an N-port can restrict the number of information categories it can accept in a single Sequence.
  • Type: is the same with each frame in a Sequence.
  • F_CTL, Frame control: changes basically only on the second and last frame in a Sequence and in an Exchange (18.5). If fill bytes are used (if data is sent in an amount that is not a multiple of 4 bytes), the Fill Data Bytes field can change on the last frame.
  • DF_CTL, Date Field Control: it shows if there are any optional headers before the payload in the frame. It does not change between frames in a Sequence (?).
  • SEQ_CNT, Sequence Count: is a 16 bit number that gets incremented on each frame in a Sequence. See 18.8 on values of SEQ_CNT at the beginning of a first Sequence of an Exchange.
  • Parameter: for Link Control frames (20.3), it contains a fixed value for a frame. E.g. for an ACK_N it gives the N value. For P_RJT it gives the reason code etc. For Data Frames, Parameter defines the Relative Offset. It depends on if it is supported by both N-ports if this field is used or not (defined at N-port Login).

1.2.4 Where does an N-port get its S_ID from?

S_ID (Source Identifier) gets assigned by the fabric at fabric login if the fabric supports it. Otherwise it is known implicitly.
Back to Table Of Contents

1.3 F_Port login

1.3.1 Give four examples of when a fabric login can fail

  1. F_Login with S_ID=0 does not result in an ACC with a D_ID set by the fabric, but it gives back a F_RJT with reason code Invalid S_ID (23.3.1). In this case the fabric does not support N_Port Identifier assignment.
  2. if a retry is done after a) a F_Login with an S_ID < > 0, and the fabric still responds with a F_RJT with reason code Invalid S_ID.
  3. F_Login responds with F_RJT class not supported.
  4. F_Login responds with a LS_RJT with a reason code

1.3.2 What to do in those cases?

  1. Retry F_Login with S_ID < > 0.
  2. Retry F_Login with another value of S_ID.
  3. Retry F_Login in another class.
  4. The Service Parameters were logically inconsistant or in error. Correct and retry.
Back to Table Of Contents

1.4 N_Port login

1.4.1 Give two examples of when an N-port login can fail

  1. P_Login responds with P_RJT class not supported.
  2. P_Login responds with LS_RJT with reason code. E.g. the Originator doing the P_Login does not support X_ID reassignment while the Responder N_Port requires it.

1.4.2 What to do in those cases?

  1. Retry P_Login with another class.
  2. Originator should support X_ID reassignment or else it cannot communicate to this port.
Back to Table Of Contents

1.5 Flow control

1.5.1 Which flow control is used in the different classes?

          Buffer-to-buffer   End-to-End
[R_RDY]          [ACK]
Class 1     SOFc1: yes
other frames: no       yes
Class 2         yes             yes
Class 3         yes             no

1.5.2 Do Link Control frames participate in the flow control?

Link Control frames such as ACK_x, P_RJT, P_BSY, do not participate in end-to-end flow control (20.3.4). An N_Port shall not transmit P_BSY response frames for them either (20.3).
How can an N_Port make sure that it will not get an overflow in class 1 because of those Link Control frames? The N_Port should have enough resources to receive one Link Control frame in response to each data frame sent. This means that the N_Port should have at least as many receive buffers as it has sent Data Frames in addition to the End-to-end credit that it has given at P_Login.

1.5.3 How are the fields in the ACK frames filled in?

  • R_CTL: fixed: ACKxx
  • D_ID: comes from S_ID of data frame
  • S_ID: comes from D_ID of data frame or from Recipient
  • TYPE: reserved (0?)
  • F_CTL: Sequence and Exchange context bits inverted from
  • F_CTL from Source. Some bits such as
  • Sequence_Initiative may be set by the ULP.
  • SEQ_ID: comes from data frame
  • DF_CTL: 0
  • SEQ_CNT: same as data frame
  • OX_ID: same as data frame
  • RX_ID: set by ULP, stays the same for all ACKs in exchange
  • Parameter: if no errors: stays the same for ACK_0 and ACK_1. In ACK_N it will contain N.
(See 20.3.2.2)
Back to Table Of Contents

1.6 Exchanges and Sequences

1.6.1 Which frames are not part of an Exchange or a Sequence?

Link Control Command frames such as Link Credit Reset (LCR) are not part of an Exchange or a Sequence (20.3.4).
Back to Table Of Contents

1.7 Sequence recovery

1.7.1 What happens if a frame is missing or in error?

In case of a missing frame, the recipient of the Sequence will find this by either timing out after E_D_TOV, or in case of class 1, by having a missing 'SEQ_CNT' value between two frames. In this case, the Recipient will transmit an ACK corresponding to the missing frame with the Abort Sequence bits set to (01).
In case of errors in a frame, it could be found by the CRC that is located at the end of a frame. The Recipient will send a P_RJT when it has detected a frame in error.
The Sequence will be aborted by the Initiator (24.3.10) after he has detected the error or has received the P_RJT frame or has received an ACK with the Abort Sequence bits set to (01). It will do so by sending the Abort Sequence (ABTS) Basic Link Service command.

1.7.2 Is it possible that FC-4 still receives a good frame in case of errors?
If yes, is it possible in all classes?

There are four different ways of handling errors. The Policy used, is decided by the Exchange Originator, which has to take into account the Error Policy supported by the Responder, which is shown at N_Port login (29.6.1). The method chosen will be shown in the F_CTL field in the data frame. The discard policies will deliver a complete Sequence or, it will not be delivered to FC-4 at all.
  1. Discard multiple Sequences: a Sequence will be delivered only if it is complete and received and all previous Sequences are delivered as well.
  2. Discard a single Sequence: a Sequence will be delivered only if it is complete. So there is no requirement that the previous Sequences were delivered as well.
  3. Discard multiple Sequences with retransmission: in this case the Sequence Recipient may request for a retransmission of a Sequence. This policy is only possible in Class 1. Note that the Retransmission Protocol is prohibited in the FCSI profiles.
  4. Process with infinite buffering: frames will be delivered to FC-4 even if there is a frame in error. This method can be useful for frame buffers and such.

1.7.3 Is there a maximum number of exchanges between N-ports?
If no, why not? If yes, how is this determined?

At N_Login the following parameters are defined:
  • Total Concurrent Sequences (Common Service)
  • Concurrent Sequences (Class Service)
  • Open Sequences per Exchange (Class Service)
As there can be maximum one Sequence Open per Exchange, the maximum number of Exchanges is limited to Total Concurrent Sequences.
The Open Sequences per Exchange parameter is used only in case of Streamed Sequences, where a Sequence Initiator can send several Sequences without waiting for the ACK on the last frame of the Sequence. Note that there is a difference between Streamed Sequences (18.6) and Chained Sequences(18.5, see as well question 2.2.4.).
Back to Table Of Contents

2. FCSI Common FC-PH Feature Sets
Used in Multiple Profiles
FCSI - 101 Revision 2.0

2.1 General

2.1.1 What does the "FCSI Common FC-PH Feature Sets" define?

The "Common Feature Sets" document makes certain selections from the FC-PH specification. The Profiles, such as SCSI and IP prescribe which Feature Sets to use and define also other, extra features. A device that is compliant to a certain Profile will interoperate with another device that is defined in the same Profile document, but there still are different options within each profile document, such as the physical layer and usage of Class 1 and Class 2.
The "Common Feature Sets" document defines as well the procedures to follow for error recovery. Here as well it defines a subset from the possibilities that the FC-PH document allows.
Furthermore the document specifies certain Features that a Fabric should have to be able to interoperate with N_Ports that operate according to the FCSI profiles. Also Complementary Fabric Profiles and Name Server Cooperating Profiles are defined.
Back to Table Of Contents

2.2 FC-2 Layer Feature Sets for Normal Operations

2.2.1 Which classes are used in the "Common FC-PH feature sets"?

Only Class 1 and Class 2 are used in the Profiles. The F-FC2-C2 Feature Set defines features and behaviour required when all Exchanges are performed in Class 2 only. F-FC2-CM defines the features required when both Class 1 and Class 2 are used in the same Exchange. In F-FC2-CM intermix mode support (sending Class 2 frames within a Class 1 connection), is required for both Transmission and Reception.

2.2.2 Which ACK types are used in the "Common FC-PH feature sets"?

The usage of ACK_N is prohibited in both Class 1 and Class 2. In Class 1 usage, only ACK_1 may be used. In Class 2 usage, both ACK_1 and ACK_0 may be used.

2.2.3 How is Relative offset used in the "Common FC-PH feature sets"?

Only Continuous Relative Offset is needed to be supported. This means that when the frames are put in order, the data can be put in the memory in the same order. Random Relative Offset is therefore prohibited.

2.2.4 Are Chained Sequences allowed in an Exchange?

Chained Sequences, which is that the Sequence Initiator requires a reply Sequence from the Sequence Recipient within the existing Dedicated Connection, is not allowed in FCSI compliant devices. This to prevent that Dedicated Connections stay open too long.
Back to Table Of Contents

2.3 FC-2 Layer Feature Sets for Error Detection and Recovery

2.3.1 Which Error Recovery mechanisms are used?

The Error Recovery mechanisms used do not resend the data (Process policy is prohibited). The recovery procedures are only to recover from failures such as lost frames or frames in error. The mechanisms as defined in FC-PH are used (sending ABTS, see question 1.7.1.) with additional specifications such as time-out usage, SEQ_CNT, RX_ID assignment and such.
If the ABTS protocol fails, different Second-Level Error Recovery mechanisms are defined for Class 1 and Class 2.
Back to Table Of Contents

2.4 Fabric Profiles

2.4.1 Which Fabric Profiles are defined?

Two fabric profiles are defined: P-FAB-C1, which has Full Class 1 and Limited Class 2 capability, and P-FAB-BC, which has Full Class 1 and Full Class 2 capability. The difference is on the Buffer-to- Buffer Data Field size (128 and 512 byte respectively) and that the -BC version can support Class 2 operations in full duplex at the speed of the N_Port technology. The -BC version is also required to do Class 2 speed matching, which is that if both N_Ports support different link speeds. Class 3 is allowed, but not required and Intermix support is required.

2.4.2 Which Complementary Fabric Profiles are defined?

The following four Complementary Fabric Profiles are defined in the "Common FC-PH Feature Sets" document:
  1. P-CFAB-H1 : Host support for Full Class 1 / Limited Class 2 fabric
  2. P-CFAB-P1 : Peripheral support for Full Class 1 / Limited Class 2 fabric
  3. P-CFAB-HB : Host support for Full Class 1 / Full Class 2 fabric
  4. P-CFAB-PB : Peripheral support for Full Class 1 / Full Class 2 fabric
These Profiles specify extra features needed, such as Local Mapping of N_Port IDs and World-Wide- Names and Stacked Connect Requests. It is not clear what is the difference between -H1 and -HB Complementary Fabric Profiles and -P1 and -PB.

2.4.3 Which Cooperating Profiles are defined?

  1. P-COP-NSR : Name server registration functions
  2. P-COP-NSQ : Name server query plus registration functions
These two Cooperating Profiles are needed in a Name Server is being used in an environment with a fabric. Those profiles are not yet defined. Also the Name Server Logical Profile is not yet defined.
Back to Table Of Contents

3. FCSI SCSI Profile
FCSI - 201 Revision 2.0

3.1 FCSI SCSI Profile

3.1.1 How many different types of FCSI SCSI implementations are possible?

Physical layer: 3 versions: 25/50/100-M5-SL-I (all laser, multi-mode).
SCSI Application Logical Profiles: 4:
  1. PSCSI-HD2 : Multi-drive Mass Storage Host using Class 2
  2. PSCSI-HDM : Multi-drive Mass Storage Host using Mixed mode
  3. PSCSI-PD2 : Multi-drive Mass Storage Peripheral using Class 2
  4. PSCSI-PDM : Multi-drive Mass Storage Peripheral using Mixed mode
So there are two possibilities for each Host and Peripheral, of which each one has three possible physical options. Note that electrical versions will be defined later.

3.1.2 Which implementations interoperate?

The -HD2 and PD-2 will interoperate in point-to-point connections, and with a Full Class1 / Full Class 2 fabric (P-FAB-BC). In the latter case the Class 2 speed matching makes that even the different physical layers will interoperate. They won't work with a Limited Class 2 fabric as the limited Class 2 bandwidth and Class 2 frame Receive Data Field Size make them unsuitable.
The -HDM and -PDM will interoperate when the physical layers are matched.
Back to Table Of Contents

4. FCSI IP Profile
FCSI - 202 Revision 1.0

4.1 FCSI IP Profile

4.1.1 How many different types of FCSI IP implementations are possible?

Physical layer: 3 versions: 25/50/100-M5-SL-I (all laser, multi-mode).
IP Application Logical Profiles: 4:
  1. P-IP-H2 : IP Host using Class 2
  2. P-IP-HM : IP Host using Mixed mode
  3. P-COP-ARPC : Cooperating profile for ARP Client (using Class 2)
  4. P-ARP-SRVR : ARP Server (using Class 2)
So there are two possibilities for the Hosts, of which each one has three possible physical options. Note that electrical versions will be defined later. If needed, the ARP Server or ARP Client profiles have to be added to the host.

4.1.2 Which implementations interoperate?

The -H2 hosts will interoperate in point-to-point connections, and with a Full Class1 / Full Class 2 fabric (P-FAB-BC). In the latter case the Class 2 speed matching makes that even the different physical layers will interoperate. They won't work with a Limited Class 2 fabric as the limited Class 2 bandwidth and Class 2 frame Receive Data Field Size make them unsuitable.
The -HM and -PM will interoperate when the physical layers are matched.
Posted by at No comments:

FC Zoning


Hard zoning versus soft zoning in a FC/FCoE SAN
Over the past few weeks, I’ve answered a bunch of questions that have asked something along the lines of “Should I use Hard Zoning or Soft Zoning?”  And no, I have no idea why these questions are coming up now…    
The short answer
If you’re familiar with FC Zoning as well as the FC protocol and don’t require a detailed explanation, the short answer is; “You no longer have a choice.  As of today, all of the FC/FCoE switches supported by EMC provide hardware enforcement for both “WWPN” and “Domain, Port” based zones”.  For the sake of completeness, there are some situations where hardware enforcement is effectively disabled but as long as your fan-in and fan-out ratios remain below 1:64 or 64:1 and/or you're not using NPIV, you won’t need to worry about this.  
Read on if you’d like a bit more detail.
The long answer...
As I started writing this section it quickly became apparent that I would need to provide an introduction to zoning and this leads to a discussion about FC Login, discovery, etc.  So I’ll start with the basics first and then get a bit more detailed as I go.  To start with, let’s assume a configuration similar to the following.    
Zoning_one
Starting from the left, the configuration consists of:
1)      A Host containing a single HBA/CNA port that has a WWPN (World Wide Port Name) of 10:00:00:00:00:00:00:00 and was assigned an FCID (Fibre Channel IDentifier) of 030100 during the Fabric login process.  
2)      A FC Fabric containing two FC switches:
  • FC/FCoE Switch Domain 3; and
  • FC/FCoE Switch Domain 4
3)      A Storage array containing a port that has a WWPN of 50:00:09:71:20:30:40:50 and was assigned an FCID of 040200 during the Fabric login process.   
A few points to take note of:
  • This configuration could be all FC, all FCoE or a combination of both.
  • The HBA/CNA and Storage Array ports both have a WWPN that is assigned to the port in some vendor specific way AND an FCID that is assigned to each port by the switch during Fabric Login.
  • The middle byte of the FCIDs that I have shown correspond to the physical interface and this is not always the case (especially in Cisco environments)
  • I will only be talking about Open Systems hosts in this post.  Apologies to FICON users, you’ll have to wait for FC-SB-5 to be finished before any of this applies to you.
What is a zone, zone set, configuration, etc
A zone is a collection of WWPNs, FCIDs or both that have been associated with one another for the purpose of allowing them to freely access one another.  Zones have to be added to a zone set or configuration and then activated onto a fabric in order for the access defined in the zone to become effective.  For example in the diagram below, I’ve updated the example topology so that it now shows a single zone named “TEST” that is a part of the Zone set/configuration “Test CFG” and contains two WWPN members. 
Zoning_two  
A couple of important points to note:
1)      For all practical purposes, the zone set “Test CFG” could have been activated on any switch in the Fabric.  This is because when a zone set is activated it is pushed to every switch in the fabric simultaneously. 
2)      As soon as the zone set has been activated, the zone members will be allowed to discover one another.  This is where the difference between hard zoning and soft zoning starts but before I dive into those details let’s talk about FC discovery first.
The FC Discovery process
 In order for an HBA/CNA or storage port to use a fabric, it has to login, perform registration and then perform discovery.  This process is illustrated in the following diagram and explained in more detail in the text that follows.
Zoning_three
Each time an FC port initializes, it must perform some kind of login process in order for it to be able to use the fabric.  In practice each HBA/CNA uses a slightly different login process but they all have certain things in common.  One example is the need to transmit FLOGI (Fabric Login) and receive an ACC (accept) from the fabric before attempting to do anything else.  I point this out because although in practice all of the HBA/CNA or storage port implementations that I am familiar with will perform the same basic steps, the order of steps 5, 7 and 9 may be slightly different and the exact commands used within each step may vary as well.
Step 0 (Not shown in diagram)
Assuming a port is initializing from the power off or loss of signal/sync state, speed negotiation and Link Initialization will be performed.  At the end of the Link Initialization process, the HBA/CNA or Storage port that is initializing will just be passing IDLE frames back and forth with the switch port it has been connected to and both ports will be considered to be in the ACTIVE state.
Step 1 (FLOGI)
FLOGI (Fabric Login) is the first frame transmitted by an end device that is attempting to attach to a switch.  The FLOGI contains many bits of information about this initializing end device (N_Port), but for the sake of the discussion on zoning, we only need to recognize that the initializing N_Port’s WWPN (World Wide Port Name) is included in the FLOGI.  As shown previously, this WWPN can be used in a zone to allow the initializing N_Port to access another N_Port.
Step 2 (FLOGI ACC)
Assuming the switch is functioning properly, is not too busy and there are no configuration parameters set on the switch that would prevent a particular N_Port from logging in, the switch will respond to the FLOGI with an FLOGI ACC.  The format of the FLOGI ACC is identical to the FLOGI request but the information contained within it will be specific to the responding switch/switch port.  Also, a VERY IMPORTANT piece of information that is relevant to zoning enforcement known as the FCID (Fibre Channel IDentifier) is provided to the N_Port in the FLOGI ACC.  Unlike the WWPN, this FCID will be present in every frame that will be transmitted by the N_Port and as you will see, the FCID effectively becomes the N_Port’s identity while logged into the fabric.  The relationship a WWPN has with the FCID it has been assigned by the fabric is one of the factors that allows for zoning to be enforced in hardware.
Step 3 (PLOGI NS)
One the FLOGI has been accepted by the switch, the N_Port will login with the Name Server.  Again, this has to be done in order for the N_Port to be able to register with and send queries to the Name Server.
Step 4 (PLOGI ACC)
 Assuming the switch is functioning properly and is not too busy, it will respond to the PLOGI with PLOGI ACC.  The format of the PLOGI ACC is identical to the PLOGI request but the information contained within it will be specific to the responding switch/switch port.
Step 5 (Register with the Name Server)
Once the attaching N_Port is logged into the Name Server it may register with it.  There are many different registration commands that an N_Port could use but a typical one is RFT_ID or in plain English “Register the specified FC-4 Type for the provided FCID”.  In this case we will assume that all N_Ports involved either have or will register an FC-4 Type of “SCSI-FCP”.  Note, although it’s a bit out of scope for this post, I will mention that this isn’t usually the case.  Many N_Ports (especially targets) choose to register with the Name Server in multiple ways, the purpose for doing so is to ensure that no matter what Name Server query an initiator uses, the target will always be discoverable.  
Step 6 (Name Server Accepts registrations)
 Assuming the switch is functioning properly and is not too busy, it will accept the registrations.  If this fails, an attaching N_Port should retry.
Step 7 (SCR - State Change Registration)
The attaching N_Port will perform a full registration for RSCNs.  By doing so, the N_Port is requesting the switch to send it a Registered State Change Notification (RSCN) every time something in the fabric changes.  These changes currently include events like the addition and removal of a Domain (e.g., switch) as well as a zoning change being made to the fabric that impacts the device.
Step 8 (Fabric Controller accepts the State Change Registration)
Assuming the switch is functioning properly and is not too busy, it will accept the SCR
Step 9 (Query the Name Server)
At this point in the login process the attaching N_Port will query the Name Server in an attempt to discover what other devices are logged into the fabric and available for it to communicate with.  Since I stated that we would assume all N_Ports in the fabric would register an FC-4 type of SCSI-FCP (see step 5), we’ll assume that the attaching N_Port will use a Name Server query called GID_FT or in plain English “Get Port Identifiers for the devices that registered the specified FC-4 type” and will specify an FC-4 of SCSI-FCP.
And finally … information directly relevant to the topic of Hard Zoning versus soft zoning.
Step 10 (Name Server response to queries)
In response to the Name Server query, the switch will return a list of port identifiers (i.e., 030100 and 040200).  More specifically, the switch will only return the Port IDs for other FC devices that:
  1. have registered an FC-4 of SCSI-FCP (since that is what we queried for); AND
  2. share a common zone with the device that queried the Name Server. 
For example, in the following diagram Host 1, Storage 1A and Storage 1B are all in the same Zone.  If any of these devices were to query the Name Server, they should only get 3 Port IDs back.  In the case of a switch that only supports “soft zoning”; zoning is enforced by allowing N_Ports to discover only those Port IDs that are associated with N_Ports that they have been granted access to (via zoning).  Port IDs associated with N_Ports that do not share a common zone with the querying N_Port will not be returned in Name Server responses.    
The downside of soft zoning is the switch does nothing to prevent a rogue host from transmitting frames directly to another N_Port’s Port ID.  To some this represents a serious security flaw and it’s hard to argue against this point.  However, in practice, this behavior is more of a problem when you had a malfunctioning adapter or an incorrectly programmed driver that would insist on communicating with another device even if access to that device was removed via a zoning change.  
Zoning_four
Step 11+ (End to End PLOGI) see diagram below
Once an N_Port discovers the other port IDs it can communicate with, it will perform an end to end PLOGI with them.  In practice only Hosts (Initiators) end up performing this PLOGI and they are usually smart enough to not PLOGI themselves.
When the initiator transmits the PLOGI, it will set the D_ID (Destination ID ) of the frame to be equal to one of the Port IDs returned from the Name Server and it will set the S_ID (Source ID) of the frame to be equal to its own Port ID (assigned in FLOGI ACC). 
When the switch receives the end to end PLOGI, if it supports Hard zoning, it will check the D_ID of the frame and make sure that the specified S_ID is allowed to access (is zoned to have access) the specified D_ID.  If yes, the PLOGI is forwarded on to the destination if not, the PLOGI is dropped.  This is what is commonly referred to as Hard Zoning or Hardware enforced zoning.   Since the PLOGI is dropped, the login process never continues past this point.  I’ve heard but have not been able to confirm in the lab that some switch vendors implement hard zoning by trapping all PLOGIs from N_Ports at the fabric ingress port and forwarding them to the control plane of the switch.  The control plane then only forwards those PLOGI frames that should be allowed.      
Zoning_five
Additional considerations
There is so much more that could be said on the topic of hardware enforced zoning.  One point that I should mention is that not all switches supported by EMC today enforce zoning at the fabric ingress port.  In fact, some of the earlier Brocade products would enforce at the fabric egress port.   The net result was, for all practical purposes, the same as if the frame was dropped at the ingress but if I didn’t mention it someone else would have…

http://brasstacksblog.typepad.com/brass-tacks/2012/01/hard-zoning-versus-soft-zoning-in-a-fcfcoe-san.html
Courtesy: Erik Smith
Posted by at No comments:
Subscribe to: Posts (Atom)