FIBRE CHANNEL - QLogicqgt.qlogic.com/Hidden/support/Current Answer Attachments/00-468v… · Fibre Channel — Methodologies for Interconnects (FC-MI) 1 Introduction and Scope This

Copies of this document may be purchased from: TR-XX-200xGlobal Engineering, 15 Inverness Way East, T11/Project 1377-D/Rev 0.3Englewood, CO 80112-5704Phone: (800) 854-7179 or (303) 792-2181 Fax: (303) 792-2192

FIBRE CHANNELMETHODOLOGIES for INTERCONNECTS

(FC-MI)

REV 0.3

NCITS working draft proposedAmerican National Standardfor Information Technology

August 1, 2000

Secretariat: Information Technology Industry Council

NOTE:This is a working draft American National Standard of Accredited Standards Committee NCITS. Assuch this is not a completed standard. The T11 Technical Committee or anyone else may modifythis document as a result of comments received anytime, or during a future public review and itseventual approval as a Standard. Use of the information contained herein is at your own risk.

Permission is granted to members of NCITS, its technical committees, and their associated taskgroups to reproduce this document for the purposes of NCITS standardization activities withoutfurther permission, provided this notice is included. All other rights are reserved. Any duplicationof this document for commercial or for-profit use is strictly prohibited.

POINTS OF CONTACT:

Kumar Malavalli (T11 Chair)Brocade Communications Systems, Inc.1901 Guadalupe ParkwaySan Jose, CA 95131Voice: (408) 487-8156Fax: (408) 487-8101EMail: [email protected]

David Peterson (Facilitator)StorageTek Network Business Group7600 Boone Ave. N.Brooklyn Park, MN 55428(763) 391-1008Fax: (763) 424-2853E-Mail: [email protected]

Ed Grivna (T11 Vice Chair)Cypress Semiconductor2401 East 86th StreetBloomington, MN 55425Voice: (952) 851-5046Fax: (952) 851-5087E-Mail: [email protected]

Craig W. Carlson (Technical Editor)QLogic Corporation6321 Bury DriveEden Prairie, MN 55346(952) 932-4064Fax: (952) 932-4037E-Mail: [email protected]

TR-XX-200x Methodologies for Interconnects Rev 0.3 August 1, 2000

ii

Release Notes for version 0.3:

– Reorganized document layout.

– Added fabric requirements section (T11/00-427v2).

– Made minor change, as requested, to loop section.

– Added introductory material.

– Added FC-TAPE addressing table.

Release Notes for version 0.2:

– First release.


iii

BSR TR-XX-200x

American National Standardfor Information Technology

Fibre Channel —Methodologies for Interconnects (FC-MI)

Secretariat

Information Technology Industry Council

Approved (not yet approved)

American National Standards Institute, Inc.

Abstract

This Technical Report specifies common methodologies for both Arbitrated Loop and Switched envi-ronments. It is the intention of this Technical Report that the methodologies described herein facilitateinteroperability between N/NL_Port devices whether they are connected in a loop or fabric topology.


iv

This Technical Report is one in a series produced by the American NationalStandards Committee, NCITS, Information Technology. The secretariat for NCITSis held by the Information Technology Industry Council (ITI), 1250 Eye Street, NWSuite 200, Washington DC 20005.

As a by-product of the standards development process and the resources ofknowledge devoted to it, NCITS from time to time produces Technical Reports.Such Technical Reports are not standards, nor are they intended to be used assuch.

NCITS Technical Reports are produced in some cases to disseminate thetechnical and logical concepts reflected in standards already published or underdevelopment. In other cases, they derive from studies in areas where it is foundpremature to develop a standard due to a still changing technology, orinappropriate to develop a rigorous standard due to the existence of a number ofviable options, the choice of which depends on the user's particular requirements.These Technical Reports, thus, provide guidelines, the use of which can result ingreater consistency and coherence of information processing systems.

When the draft Technical Report is completed, the Technical Committee approvalprocess is the same as for a draft standard. Processing by NCITS is also similar tothat for a draft standard.

CAUTION NOTICE: This Technical Report may be revised or withdrawn at anytime. The procedures of the American National Standards Institute require thataction be taken periodically to reaffirm, revise, or withdraw this Technical Report.Purchasers of American National Standards may receive current information on allstandards by calling or writing the American National Standards Institute.

NCITSTechnicalReportSeries

Published by

American National Standards Institute11 West 42nd Street, New York, NY 10036

Copyright © 200x by Information Technology Industry Council (ITI)All rights reserved.

No part of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permission of ITI, 1250 Eye Street NW,Washington, DC 20005.

Printed in the United States of America

CAUTION: The developers of this standard have requested that holders of patents that may berequired for the implementation of the standard disclose such patents to the publisher. However,neither the developers nor the publisher have undertaken a patent search in order to identify which,if any, patents may apply to this standard. As of the date of publication of this standard andfollowing calls for the identification of patents that may be required for the implementation of thestandard, no such claims have been made. No further patent search is conducted by the developeror publisher in respect to any standard it processes. No representation is made or implied thatlicenses are not required to avoid infringement in the use of this standard.

Foreword (This Foreword is not part of American National Standard TR-XX-200x.)

The Fibre Channel Methodologies for Interconnects (FC-MI) Technical Report de-scribes common methodologies for facilitating interoperability in both loop and fab-ric environments.

This Technical Report was developed by Task Group T11 of Accredited StandardsCommittee NCITS during 1999-2000. The standards approval process started in2000. This document includes annexes which are informative and are not consid-ered part of the Technical Report.

Requests for interpretation, suggestions for improvements or addenda, or defectre-ports are welcome. They should be sent to the NCITS Secretariat, InformationTechnology Industry Council, 1250 Eye Street, NW, Suite 200, Washington, DC20005-3922.

This Technical Report was processed and approved for submittal to ANSI by theNational Committee for Information Technology Standards (NCITS). Committeeapproval of the standard does not necessarily imply that all committee membersvoted for approval.

At the time it approved this Technical Report, NCITS had the following members:

(to be filled in by NCITS)

v

Technical Committee T11 on Lower Level Interfaces, which reviewed this stan-dard, had the following members:

Kumar Malavalli, ChairEdward Grivna, Vice-ChairNeil Wanamaker, Secretary

(Membership P&A list to be added for final draft prior to T11 approval)

vi

Task Group T11.3 on Fibre Channel Stuff, which developed and reviewed thisstandard, had the following members:

Jeff Stai, ChairGeorge Penokie, Vice-ChairCraig Carlson, Secretary

(Membership P&A list to be added for final draft prior to T11.3 approval)

vii

viii

Introduction

(UPDATE THIS BEFORE FORWARDING)

FC-MI is one of the Fibre Channel family of standards. This family includes ANSIX3.230, FC-PH, which specifies the Physical and Signalling Interface. ANSIX3.297, FC-PH-2, and ANSI X3.303, FC-PH-3, specify enhanced functions addedto FC-PH. ANSI X3.289, FC-FG, and ANSI X3.321, FC-SW, are documents relatedto Fabric requirements. ANSI X3.272, FC-AL, specifies the arbitrated loop topolo-gy.

Acknowledgements

The technical editor would like to thank the following individuals for their specialcontributions to this standard:

– TBD

ix

x


1 Introduction and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Normative References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.1 Approved references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 References under development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Other references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Definitions and conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Editorial Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.1 Hexadecimal notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Abbreviations, acronyms and symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.4 Applicability and use of this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Structure and Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1 Interoperability Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Public and Private Loop addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Loop Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.1 Loop Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1.1 Power On Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.1.2 Loop Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.1.3 Initialization at Power-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.1.4 Device Time-out during Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.1.5 Response to LIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.1.6 Origination of LISM Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.1.7 Forwarding of LISM frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.1.8 Address Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.1.9 Dual Port Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.1.10 Loop Map Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.1.11 Availability after LIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.2 Post Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.2.1 Lip Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Fabric Behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.1 Switched Fabric Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.1.1 Switch-to-switch (E_Port) Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.1.2 Nx_Port Fabric Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.1.3 Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.1.4 Registered State Change Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 Discovery and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Annex A: SANMark Level 1(Informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

A.1 SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.3 Approved references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29A.4 Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A.4.1 Loop Initialization effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30A.4.2 Events that should not cause LIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.4.3 Reception of CLS in response to OPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A.4.4 Lack of response to OPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

xi


Annex B: Private Device Fabric Bridging(Informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37B.2 Common Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

B.2.1 Public-Private Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37B.2.2 Hub Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

B.3 Nx_Port Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

xii


xiii


xiv

Figures Page

Figure 1 – Conceptual Interoperability Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

xv

xvi

Tables Page

Table 1 – ISO and American Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Table 2 – Public and Private Loop addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Table 3 – FC-SW-2 Fabric Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Table 4 – ELP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Table 5 – Flow Control Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Table 6 – NS-NS Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Table 7 – FC-GS-3 Fabric Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Table 8 – Name Server Query Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Table 9 – Zoning Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

xvii

Tables Page

xviii

Tables Page

xix

Tables Page

xx

AMERICAN NATIONAL STANDARD ANSI NCITS xxx-200x

American National Standardfor Information Technology —

Fibre Channel —Methodologies for Interconnects (FC-MI)

1 Introduction and Scope

This Technical Report is intended to document interoperability behavior for private loop devices (Pri-vate NL_Port), fabric attached loop devices (Public NL_Port) and point-to-point fabric attached devic-es (N_Port). The scope of this report is to include a wide range of issues from link initialization toerror detection and recovery to zoning.

This report is intended to serve as an implementation guide whose primary objective is to maximizethe likelihood of interoperability between conforming implementations. This report prohibits or re-quires features that are optional, and prohibits the use of some non-optional features in the refer-enced ANSI standards.

A second objective of this Technical Report is to simplify implementations and their associated docu-mentation, testing, and support requirements. This means that there will be some optional featureswhich are not mutually exclusive, but are still prohibited or required solely for the purpose of this sim-plification.

Internal characteristics of conformant implementations are not defined by this Technical Report. ThisTechnical Report incorporates features from the standards described below. Where needed, chang-es are or have been proposed to the appropriate ANSI NCITS technical committees to ensure thisTechnical Report remains a strict subset of ANSI standards.

1


2 Normative References

The following Standards contain provisions which, through reference in the text, constitute provisionsof this Standard. At the time of publication, the editions indicated were valid. All Standards are sub-ject to revision, and parties to agreements based on this Standard are encouraged to investigate thepossibility of applying the most recent editions of the Standards listed below.

For electronic copies of some standards, visit ANSI’s Electronic Standards Store (ESS) at www.an-si.org. or printed versions of all standards listed here, contact Global Engineering Documents, 15 In-verness Way East, Englewood, CO; 80112-5704, (800) 854-7179.

Additional availability contact information is provided below as needed.

2.1 Approved references

[1] ANSI X3.230:1994, Information Technology - Fibre Channel Physical and Signaling Interface(FC-PH).

[2] ANSI X3.297:1997, Information Technology - Fibre Channel - Physical and Signalling Inter-face-2 (FC-PH-2).

[3] ANSI X3.272:1996, Information Technology - Fibre Channel - Arbitrated Loop (FC-AL).

[4] ANSI X3.289:1996, Information Technology - Fibre Channel - Fabric Generic (FC-FG).

[5] ANSI X3.303:1998, Fibre Channel - Physical and Signalling Interface-3 (FC-PH-3).

[6] ANSI NCITS 321-1998, Fibre Channel - Switch Fabric (FC-SW).

[7] ANSI NCITS TR-20-1998, Fibre Channel - Fabric Loop Attachment (FC-FLA).

[8] ANSI NCITS 332-1999, Fibre Channel - Arbitrated Loop (FC-AL-2).

2.2 References under development

At the time of publication, the following referenced standards were still under development. For infor-mation on the current status of the documents, or regarding availability, contact the relevant stan-dards body or other organization as indicated.

[9] ANSI NCITS xxx-199x, Fibre Channel - Backbone (FC-BB), T11/Project 1238D/Rev 4.7

[10] ANSI NCITS xxx-199x, Fibre Channel - Switch Fabric - 2 (FC-SW-2), T11/Project 1305D/Rev4.4

[11] ANSI NCITS xxx-199x, Fibre Channel - Virtual Interface (FC-VI), T11/Project 1332D/Rev 1.61

[12] ANSI NCITS xxx-199x, Fibre Channel - Framing and Signaling Interface (FC-FS), T11/Project1331D/Rev 0.3

[13] ANSI NCITS xxx-199x, SCSI Fibre Channel Protocol - 2 (FCP-2), T10/Project 1144D/Rev 4

[14] ANSI NCITS xxx-200x, Fibre Channel - Generic Services - 3 (FC-GS-3), T11/Project 1356-D/Rev 6.42

2


2.3 Other references

The following document is available from the Fibre Channel Industry Association (FCIA), 2570 WestEl Camino Real, Ste. 304, Mountain View, CA 94040-1313; (800) 272-4618 or (650) 949-6730(phone); or at www.fibrechannel.com.

[15] FCSI-101, FCSI Common FC-PH Feature Sets Used in Multiple Profiles, Rev 3.1

The following documents are available from the RFC Editor, Information Sciences Institute, Universi-ty of Southern California, 4676 Admiralty Way, Suite 1001, Marina del Rey, CA 90292-6695; (310)822-1511 or (310) 823-6714 (fax); http://www.isi.edu/.

[16] RFC 768, User Datagram Protocol, August1980.

[17] RFC 1157, A Simple Network Management Protocol (SNMP), May 1990.

[18] RFC 1155, Structure and Identification of Management Information for TCP/IP-based Internets,May 1990.

[19] RFC 1901, Introduction to Community-based SNMPv2, January 1996.

[20] RFC 1902, Structure of Management Information for version 2 of the Simple Network Manage-ment Protocol (SNMPv2), January 1996.

[21] RFC 1903, Textual Conventions for Version 2 of the Simple Network Management Protocol(SNMPv2), January 1996.

[22] RFC 1905, Protocol Operations for version 2 of the Simple Network Management Protocol(SNMPv2), January 1996.

[23] RFC 1906, Transport Mappings for version 2 of the Simple Network Management Protocol(SNMPv2), January 1996.

[24] RFC 2373, IP Version 6 Addressing Architecture, July 1998.

[25] RFC 2625, IP and ARP over Fibre Channel, June 1999.

3


3 Definitions and conventions

For FC-MI, the following definitions, conventions, abbreviations, acronyms, and symbols apply.

3.1 Definitions

3.1.1 address identifier: An address value used to identify source (S_ID) or destination (D_ID) of aframe.

3.1.2 alias address identifier (alias): One or more address identifiers which may be recognized byan N_Port in addition to its N_Port Identifier. An alias address identifier is Fabric unique and may becommon to multiple N_Ports.

3.1.3 Application: An entity that makes requests of a Service.

3.1.4 Common Transport: A protocol defined by this Standard which provides access to Servicesand their related Servers.

3.1.5 Directory: A repository of information about objects which may be accessed via the DirectoryService.

3.1.6 fabric: Any interconnect between two or more N_Ports, including point-to-point, loop, andSwitched Fabric.

3.1.7 Generic Services: The collection of Services defined by this Standard.

3.1.8 Link Service Facilitator: The entity at well-known address hex ‘FFFFFE’; known as the“Fabric F_Port” in FC-PH, the address identifier to which Fabric Login is directed.

3.1.9 N_Port: A hardware entity which includes a Link_Control_Facility. It may act as an Originator,a Responder, or both.

3.1.10 N_Port Identifier: A Fabric unique address identifier by which an N_Port is uniquely known.The identifier may be assigned by the Fabric during the initialization procedure. The identifier mayalso be assigned by other procedures not defined in FC-PH. The identifier is used in the S_ID andD_ID fields of a frame.

3.1.11 Name_Identifier: A 64 bit identifier, with a 60 bit value preceded with a four bitNetwork_Address_Authority_Identifier, used to identify physical entities in Fibre Channel such asN_Port, Node, F_Port, or Fabric.

3.1.12 Network_Address_Authority (NAA): An organization such as CCITT or IEEE whichadministers network addresses.

3.1.13 Network_Address_Authority Identifier: A four bit identifier defined in FC-PH to indicate aNetwork_Address_Authority (NAA).

3.1.14 Server: A Server is an entity which accepts CT requests and provides CT responses. AServer is accessed via a Service. For example, the Name Server is accessed using the DirectoryService.

3.1.15 Service: A Service is provided by a Node, accessible via an N_Port which is addressed by aWell-Known Address. Examples of a Service include the Directory Service and the Alias Service. AService provides access to one or more Servers.

4


3.1.16 Switched Fabric: A fabric comprised of one or more Switches (see FC-SW, reference [6]).

3.1.17 Symbolic Name: A user-defined name for an object, up to 255 characters in length. TheDirectory does not guarantee uniqueness of its value.

3.1.18 Unidentified N_Port: An N_Port which has not yet had its N_Port identifier assigned by theinitialization procedure.

3.1.19 Well-Known Address: An address identifier defined in FC-PH to access a Service.

3.1.20 Zone: As defined in FC-FG, reference [4].

3.2 Editorial Conventions

In FC-MI, a number of conditions, mechanisms, sequences, parameters, events, states, or similarterms are printed with the first letter of each word in uppercase and the rest lowercase (e.g., Ex-change, Class). Any lowercase uses of these words have the normal technical English meanings.

Numbered items do not represent any priority. Any priority is explicitly indicated.

The ISO convention of numbering is used (i.e., the thousands and higher multiples are separated bya space and a comma is used as the decimal point.) A comparison of the American and ISO con-ventions are shown in table 1.

In case of any conflict between figure, table, and text, the text, then tables, and finally figures takeprecedence. Exceptions to this convention are indicated in the appropriate sections.

In all of the figures, tables, and text of this document, the most significant bit of a binary quantity isshown on the left side. Exceptions to this convention are indicated in the appropriate sections.

The term “shall” is used to indicate a mandatory rule. If such a rule is not followed, the results are un-predictable unless indicated otherwise.

If a field or a control bit in a frame is specified as not meaningful, the entity which receives the frameshall not check that field or control bit.

3.2.1 Hexadecimal notation

Hexadecimal notation is used to represent fields. For example, a four-byte Process_Associator fieldcontaining a binary value of 00000000 11111111 10011000 11111010 is shown in hexadecimal for-mat as hex ‘00 FF 98 FA’.

Table 1 – ISO and American Conventions

ISO American

0,6 0.6

1 000 1,000

1 323 462,9 1,323,462.9

5


3.3 Abbreviations, acronyms and symbols

Abbreviations and acronyms applicable to this standard are listed. Definitions of several of theseitems are included in 3.1.

AS Alias ServiceCT Common TransportCT_IU Common Transport Information UnitD_ID Destination address identifierELS Extended Link ServiceFCS Fabric Configuration ServerGS Fibre Channel Generic ServiceIN_ID Initial IdentifierIP Internet ProtocolIPA Initial Process AssociatorIU Information UnitMS Management ServiceNAA Network Address AuthorityNS Name ServerNSM Native SNMP MappingRNID Request Node Identification Data Extended Link ServiceRTIN Request Topology Information Extended Link ServiceSI Sequence InitiativeS_ID Source address identifierSNMP Simple Network Management ProtocolTS Time ServiceUDP User Datagram ProtocolULP Upper Level ProtocolsWKA Well-Known Address

3.4 Applicability and use of this document

Since the nature of this document is a profile, the usual definitions of the following words do not ap-ply! Please read these definitions carefully!

Prohibited: If a feature is Prohibited, it means that it shall not be used between compliant implemen-tations. An implementation may use the feature to communicate with non-compliant implementations.This document does not prohibit the implementation of features, only their use between compliant im-plementations. However, interoperability is not guaranteed if Prohibited features are used.

Required: If a feature or parameter value is Required, it means that it shall be used between compli-ant implementations. Compliant implementations are required to implement the feature. An imple-mentat ion may use the feature or other features to communicate with non-compliantimplementations. Interoperability is not guaranteed if Required features are not implemented.

Allowed: If a feature or parameter value is Allowed, it means that it may be used between compliantimplementations. Compliant implementations are not required to implement the feature, but if theydo, the feature shall be implemented as described in this document. Typically, the potential user of afeature may determine if the potential recipient supports that feature via a Required discovery pro-cess.

Invocable: If a feature or parameter value is Invocable, it means that it may be used between compli-ant implementations. Compliant implementations are required to implement the feature, and make

6


available the use of the feature. Invocable is different than Allowable or Required in that an originatormay invoke the feature if needed, but the originator is not required to invoke it, and may never needto. Typically, an Invocable feature is Required for implementation by the recipient of the feature.

The tables in the following clauses list features described in the various standards specific to the op-erations described in the clause. These tables indicate whether the feature is Required, Prohibited,Invocable, or Allowed for compliance with this report; or whether a parameter is Required to be a par-ticular value for compliance with this report.

The following legend is used for table entries in these clauses:

‘P’ the implementation is Prohibited from using the specified feature‘R’ the implementation is Required to support the specified feature‘A’ use of the specified feature is Allowed‘I’ the implementation may Invoke the specified feature‘n’ the parameter shall be set to this value‘X’ this parameter has no required value; any value is allowed‘-’ this parameter or feature is not meaningful

7


8


4 Structure and Concepts

4.1 Interoperability Environment

Figure 1 – Conceptual Interoperability Environment

The goal of this Technical Report is to define an Interoperability Environment. WIthin this Environ-ment, a compliant device would adhere to certain sets of behavior that allow for interoperabilityacross a wide variety of topologies and management methods. Figure 1 shows a conceptual diagramof this Interoperability Environment. This Environment encompasses three areas:

– Management Behavior – The set of behaviors required to create an interoperable managementenvironment.

– Loop Behavior – The set of behaviors required to create an interoperable Arbitrated Loop envir-ment.

– Fabric Behavior – The set of behaviors required to create an interoperable fabric environment.

Also, as depicted by the diagram, the Loop Behavior and Fabric Behavior taken together defines aset of Nx_Port behaviors.

It is important to note that a device may be non-compliant with this Technical Report, but still compli-ant with any of the various referenced Fibre Channel Standards. Of course, a non-compliant device isnot may not be interoperable.

Nx_PortBehavior

LoopBehaviors

FabricBehaviors

ManagementBehaviors

LoopBehavior

FabricBehavior

ManagementBehavior

Nx_PortBehavior

9


4.2 Public and Private Loop addressing

The table below describes the required addressing behavior for Public and Private loops.

Table 2 – Public and Private Loop addressing

Frame sent from(note 1)

Frame received by

(note 1)

OPN AL_PD S_ID (note 1) D_ID (note 1)source

loopdest.loop

23:8 7:0 23:8 7:0

PublicNL_Port

Fabric-AttachedN_Port

hex ’00’ - Local

D&ASourceAL_PA Address Identifier

Fabric-AttachedN_Port

PublicNL_Port - D_ID

7:0 Address Identifier RemoteD&A

Dest.AL_PA

Local PublicNL_Port

Remote PublicNL_Port

hex ’00’

D_ID7:0

LocalD&A

SourceAL_PA

RemoteD&A

Dest.AL_PA

Remote PublicNL_Port

Local PublicNL_Port

hex ’00’

D_ID7:0

RemoteD&A

SourceAL_PA

LocalD&A

Dest.AL_PA

Local PublicNL_Port

Local PublicNL_Port

D_ID7:0 (note 2) Local

D&ASourceAL_PA

LocalD&A or

hex’0000’(note 3)

Dest.AL_PA

Local PublicNL_Port

Local PrivateNL_Port

D_ID7:0

LocalD&A

SourceAL_PA

hex ’0000’

Dest.AL_PA


Local PublicNL_Port

D_ID7:0

hex ’0000’

SourceAL_PA

LocalD&A or

hex’0000’(note 3)

Dest.AL_PA



D_ID7:0

hex ’0000’

SourceAL_PA

hex ’0000’

Dest.AL_PA

NOTES:

1 “D&A” refers to the Domain and Area; “Local” means the Domain and Area on the Local Loop, “Remote”means the Domain and Area of the Remote Loop.

2 The behavior of an FL_Port when it receives a unicast frame from a Local NL_Port destined for anotherLocal NL_Port is not defined by this report.

3 A Public NL_Port shall process PLOGI, LOGO, and ABTS frames with D_ID equal to hex ‘0000’ AL_PAregardless of whether the NL_Port has a valid Domain and Area from a Fabric Login. This behavior al-lows Private NL_Ports to discover Public NL_Ports on the same loop and Public NL_Ports to use a com-mon process for logging into Private and Public NL_Ports on the same loop. Public NL_Ports may discardany other frames addressed to hex ‘0000’ AL_PA.

10


5 Loop Behaviors

5.1 Loop Initialization

5.1.1 Power On Behavior

During power on, after the transmitter has been enabled and 200 usec of valid 1.0625 GHz signal ator above FC-PH minimum amplitude levels has been driven by the transmitter, an L_Port shall notdisrupt the operation of the loop for more than 95 msec and shall begin forwarding transmissionwords or begin initialization within 95 msec.

NOTE – Note: This disruption event is caused by the minimum criteria of hubs to cut devices in. This minimumcriteria is a minimum of 200 usec of 1.0625 GHz signal at FC-PH minimum amplitude.

NOTE – Note: This allows most existing implementations to meet this specifications. There are requirementsfor GLM operation to assert Lock_Ref for 10 msec after power on. This may produce a lower bound on thisnumber; however, devices should attempt to make this value as low as possible. a future revision of this spec-ification may lower this number significantly from the current 95 msec, since with bypass circuits and properdesign this should be easily achievable. Bypassing a device during the reset time of a device and then en-abling the device and originating LIP at some later time is a valid method for limiting the loop disruption atpower on.

5.1.2 Loop Failure

Loop failure is defined in FC-AL-2 as loss of synchronization for >100 msec. or loss of signal. AL_Port shall not issue a LIP for loop failure prematurely.

5.1.3 Initialization at Power-on

Devices shall request only one loop initialization at power up, unless the device attempts to enterOLD-PORT state, after which only one additional loop initialization may be requested.

5.1.4 Device Time-out during Initialization

Under some circumstances, it may be necessary for a device to request loop initialization multipletimes. If loop initialization has not completed within 2 seconds, the device may request initializationagain given the following rules:

– The next time the device shall increase the time-out to greater than 24 sec.;

– The third and subsequent times the device shall increase the time-out to greater than 128 sec.

5.1.5 Response to LIP

A device shall recognize and forward 12 of the LIPs received within 5 msec, unless it is already inOPEN_INIT and ignoring LIPs for AL_Time.

5.1.6 Origination of LISM Frames

A device which supports LIM and has not received a higher priority LISM shall originate LISM frameswith a maximum of 5 msec. between LISM frames. FC-AL-1 devices will source IDLEs for 15 msecbefore they begin sourcing LISMs. After this 15 msec of IDLES they shall follow this rule.

11


5.1.7 Forwarding of LISM frames

A device which has received a higher priority LISM shall forward the last LISM recognized with a gapof no more than the maximum of either 5 msec or the delay between received LISM frames betweenthe transmitted frames.

5.1.8 Address Selection

During the first initialization after power on or on reception of LIPr, a device shall take an address dur-ing the LIHA or LISA phase, if an address is available. There are three reasons that the device shalllose its address:

a) Power cycle of the device

b) LIPr directed to the device

c) Another device takes the address in the LIFA or LIPA phase before that device could take itsaddress (This would happen if two loop segments were joined with overlapping addresses).

In subsequent initialization cycles prior to the device succeeding in FLOGI, the device shall take itsaddress in the LIPA phase if its address is available. After FLOGI has completed, the device shalltake its address in the LIFA phase if its address is available. If a device is using SCSI Mode page 19with the "Disable Soft Address" (DSA) bit set then it shall exit initialization as non-participating if itshard address is unavailable.

5.1.9 Dual Port Initialization

In order to minimize disruptions, a dual port device has the following initialization requirements:

– A LIP, other than LIPr, on one port shall not cause a LIP on the other port.

– Initialization on one port shall not cause the other port to lose any frames or state.

– Initialization on one port should not cause the other port to impact traffic on its loop.

– Traffic on a dual ported device shall not impact traffic on the other port. {Editor: This is not reallya initialization issue, move to a different section.}

– Because a Reset LIP is the equivalent of a power on reset, it may impact both ports on a dualported device.

5.1.10 Loop Map Support

Loop map support has the following rules:

– FC-AL-2 requires Loop Map; therefore loop map support shall be provided by all FC-AL-2 devic-es.

– Since non AL-2 devices may be present on the loop, devices shall not rely on Loop Map supportfor functionality.

– If all devices on a loop support Loop Map, then Loop Map shall be used determine what devicesare available. Polling is not allowed in this case.

12


5.1.11 Availability after LIP

In order to minimize disruptions on a loop after LIP, a L_Port has the following requirements:

– L_Ports which have acquired an address in a previous initialization cycle, shall not become non-participating after a LIP is received if their address or another address is still available and it isnot the intention of the port to go non-participating.

– If an L_Port goes non-participating when a LIP is received and does not participate in loop ini-tialization and discovery after loop initialization, the L_Port will be assumed to be gone and allpending I/Os to that L_Port shall be discarded. The L_Port is assumed to be gone until it takesan address in a subsequent loop initialization.

5.2 Post Initialization

5.2.1 Lip Generation

Once a device has initialized, an L_Port should use restraint in the generation of LIPs. Situations un-der which it is clearly proper for an L_Port to generate a LIP are as follows:

– Unable to win arbitration after LP_TOV.

– Loss of word sync for greater than R_T_TOV.

– A loss of signal is detected.

– A CLS in response to CLS has not been received within LP_TOV.

– The device receives its’ own open.

– A management station determines that a LIP must be generated in order to facilitate error re-covery.

Situations in which a LIP is not allowed are:

– Link error counter overrun.

– CRC error detection.

– Reception of an unexpected frame.

13


6 Fabric Behaviors

6.1 Switched Fabric Requirements

This section defines the interoperability requirements for a Switched fabric. A Switched fabric con-sists of a fabric containing 1 or more Switches connected via E_Ports. The purpose of this section isto define the minimum functionality that needs to be supported in order to deploy a Switched fabric.

This section is concerned with two aspects of Switched fabric behavior:

– Required switch-to-switch (E_Port) behaviors. These are based primarily on functions definedin FC-SW-2.

– Required fabric services provided to an attached Nx_Port. These are based primarily on func-tions defined in FC-GS-3.

6.1.1 Switch-to-switch (E_Port) Requirements

Table 3 specifies support requirements for features defined in FC-SW-2. A compliant device shall im-plement all features as specified in this table.

NOTE – At the time of the publication of this report, the FC-SW-2 Standard continues to be a work in progress.Therefore, care should be taken with regards to the clause numbers referenced in table 3.

Table 3 – FC-SW-2 Fabric Support

FC SW-2 Clauses Description Support Notes

1,2,3 Introduction, Normative References, Definitions and Conventions

R

4.1 Structure and Concepts R

5 - 5.4 SW Operational Layer R

5.5.1 F_Port R

5.5.2 FL_Port A

5.5.3 E_Port R

5.5.4 B_Port A

5.6 - 5.7 Fabric Addressing, Class F Service R

5.8 Path Selection - FSPF R

5.9 Distributed Services R

5.10 Relationship Between this Standard and FC-FG

R

6 - 6.2 Switch Ports, Model Elements and F_Port operation

R

14


6.3 FL_port operation A

6.4 - 6.6 E_port Operation, B_port Operation, Class F Service

R

7 Switch Fabric Services R

7.1.1 SW_ACC R

7.1.2 Switch Reject (SW_RJT) R

7.1.3 Exchange Link Parameters (ELP) R

7.1.4 Exchange Fabric Parameters (EFP) R

7.1.5 Announce Address Identifier (AAI) R

7.1.6 Request Domain_ID (RDI) R

7.1.7 Build Fabric (BF) R

7.1.8 Reconfigure Fabric (RCF) P

7.1.9 Disconnect Class 1 (DSCN) P

7.1.10 Detect Queued Class 1 Connection Request Deadlock (LOOPD)

P

- Hello (HLO) R

- Link State Update (LSU) R

- Link State Acknowledge (LSA) R

8 Fabric Configuration R

8.1 Switch Port Initialization R

8.2 Principal Switch Selection R 1

8.3-8.4 Address Distribution, E_port and Fabric Isolation

R

9 Enhancements to the SW Operational Layer

-

9.1 Exchange Switch Capabilities A

9.2 Switch Extensions to support B_port Operation

A

10 DMP Fabric Operational Layer P

Table 3 – FC-SW-2 Fabric Support (Continued)


15


6.1.1.1 Exchange Link Parameters (ELP)

The ELP SW_ILS as defined in FC-SW-2 shall be used with the parameters specified in table 4.

11 DMP-Fabric Initialization P

12 DMP Protocol P

13 Domain Manager Protocol Message Formats

P

14 Distributed Servers R

15.4 Merge Request R 2

15.5.1.5 Acquire Change Authorization R

15.5.3 Stage Fabric Configuration R 2

15.5.4 Update Fabric Configuration R

15.5.2 Release Change Authorization R

- Items not in current SW-2 draft - -

- Switch State Change Notification R 3

Notes: 1 A Switch is required to support Principal Switch selection, but not required to

be capable of assuming the role of Principal Switch. A Switch which cannotbecome a Principal Switch shall set it’s Principal Switch_Priority to hex’FF’as specified in FC-SW-2.

2 Object Model and data format to be extended to contain zone data beyondthe contents of only the Active zone set.

3 A technique defined for notifying switches within a fabric asynchronously ofevents within a switch. This differs from Register State Change as defined inFLA in that switch state change notification is not propagated outside theswitched fabric.

Table 4 – ELP Parameters

Item Value Notes

Revision 1

Flags 0 1

R_A_TOV 10000 2

E_D_TOV 2000 2

Table 3 – FC-SW-2 Fabric Support (Continued)


16


Class F Params Class Valid 1 3

X_ID Interlock 0

Receive Data FIeld Size 2112

Concurrent Sequences 1

End-to-End Credit 1

Open Sequences per Exchange

1

Class 1 Params 0 4

Class 2 Params Class Valid X

Sequential Delivery 1 5

Receive Data Field Size 2112

Class 3 Params Class Valid 1

Sequential Delivery 1 5

Receive Data Field Size 2112

ISL Flow Control Mode 1 6

Flow Control Parameter Length hex ‘80’ 6

Flow Control Parameters (Table 5)

Notes:1 B_Port functionality is allowed, but it’s use is outside the scope of

this Report.

2 These fields are specified in milliseconds.

3 Support of Class F for an E_Port is required as specified by FC-SW-2.

4 Used of Class 1 is Prohibited by this Report.

5 While FC-PH may require that the frames travel a “fixed route”across the fabric, this document does not particularly care howthe function is implemented, as long as it is performed correctly.

6 Check these values, they seem incorrect.

Table 4 – ELP Parameters (Continued)

Item Value Notes

17


6.1.1.1.1 Flow Control Parameters

Required values for the Flow Control Parameters field of the ELP are shown in table 5. It is importantto note that these values only apply to the ISL Flow Control Mode values as specified in table 4. Theparameter values and format for any other ISL Flow Control Mode are outside the scope of this docu-ment. Comment: The format specified below has not yet been included in FC-SW-2, but can be foundin T11/00-427v2.

6.1.1.2 NS-NS commands

Switch-to-switch Name Server requests shall be supported as shown in table 6. All ‘GE’ responsesshall use the Small Name Server Object as defined in FC-SW-2.

Table 5 – Flow Control Parameters

Item Value Notes

BB_Credit X 1

Data Field SIze 2112 2

R_A_TOV 10000 2

E_D_TOV 2000 2

Operating Mode ???

Notes:1 BB_Credit can be set to any value

suppor ted by the Or ig ina t ingE_Port. It is important to note thatthis BB_Credit value shall be usedonly after the ELP and LR havebeen completed. Before that, theBB_Credit shall be 1 as specifiedby FC-SW-2.

2 These values are present for back-ward compatibility reasons.

Table 6 – NS-NS Requests

Feature Support Notes

Get Entry based on Port Identifier (GE_ID) R

Get Entry based on Port Name (GE_PN) R

Get Entry based on Node Name (GE_NN) A

Get Entries based on IP Address - Node (GE_IP)

Get Entries based on FC-4 TYPEs (GE_FT) A

Get Entries based on Port Type (GE_PT) R

Get Entries based on Zone Member (GE_ZM)

18


Get Entries based on Zone Name (GE_ZN)

Get Entries based on IP Address - Port (GE_IPP)

Remove All (RA)

Get All Next (GA_NXT)

Get Identifiers - Scope (GI_A)

Get Port Name (GPN_ID)

Get Node Name (GNN_ID)

Get Class of Service (GCS_ID)

Get FC-4 Types (GFT_ID)

Get Symbolic Port Name (GSPN_ID)

Get Port Type (GPT_ID)

Get IP address (GIPP_ID)

Get Fabric Port Name (GFPN_ID)

Get Hard Address (GHA_ID)

Get FC-4 Descriptors (GFD_ID)

Get FC-4 Features (GFF_ID)

Get Port Identifier (GID_PN)

Get IP Address (GIPP_PN)

Get Port Identifiers (GID_NN)

Get Port Names (GPN_NN)

Get IP Address - Node Name (GIP_NN) R

Get Initial Process Associator (GIPA_NN) R

Get Symbolic Node Name (GSNN_NN)

Get Node Name (GNN_IP) R

Get Initial Process Associator (GIPA_IP) R

Get Port Identifiers (GID_FT) R

Get Port Names (GPN_FT) R

Table 6 – NS-NS Requests (Continued)


19


NS-NS commands shall be processed independent of zoning. All filtering of Name Server data tosupport zoning shall be done at the Entry Switch.

Get Node Names (GNN_FT) R

Get Port Identifiers (GID_PT) R

Get Port Identifier (GID_IPP)

Get Port Name (GPN_IPP)

Get Port Identifiers (GID_FF)

Register Port Name (RPN_ID)

Register Node Name (RNN_ID)

Register Class of Service (RCS_ID)

Register FC-4 Types (RFT_ID)

Register Symbolic Port Name (RSPN_ID)

Register Port Type (RPT_ID)

Register IP Address - Port (RIPP_ID)

Register Fabric Port Name (RFPN_ID)

Register Hard Address (RHA_ID)

Register FC-4 Descriptor (RFD_ID)

Register FC-4 Features (RFF_ID)

Register IP Address - Node (RIP_NN)

Register Initial Process Associator (RIPA_NN)

Register Symbolic Node Name (RSNN_NN)

Remove All (DA_ID)

Table 6 – NS-NS Requests (Continued)


20


6.1.2 Nx_Port Fabric Requirements

Table 7 specifies support requirements for features defined in FC-GS-3. A compliant device shall im-plement all features as specified in this table.

NOTE – As of this writing, a complete first public review of the first FC-GS-3 draft is not complete.

6.1.2.1 Name Server Query Support

Nx_Port originated Name Server requests shall be supported as shown in table 8.

Table 7 – FC-GS-3 Fabric Support

FC GS-3 Clauses Description Support Notes

1,2,3 Scope, Normative References, Definitions and Conventions

R

4 Common Transport for FC services (CT) R 1

5 Overview of directory (name) service R

5.1 - 5.13 Name Server, NS Protocol, Transportation of NS IU’s, FC-PH constructs, Name Server

Objects, FS_RJT reason code explanations

R 2

5.2 IP Address Server

6 Management Service R

6.1 Fabric Configuration Server A

6.2 Unzoned Name Server A

6.3 Fabric Zone Server A

7 Time Service P

8 Alias Server P

9 Key distribution service P

Notes:1 Synchronous mode only.

2 For supported Name Server Objects, see specific queries supported in table 8.

Table 8 – Name Server Query Support


Get All Next (GA_NXT) R

Get Identifiers - Scope (GI_A) ?

Get Port Name (GPN_ID) R

21


Get Node Name (GNN_ID) R

Get Class of Service (GCS_ID) R

Get FC-4 Types (GFT_ID) R

Get Symbolic Port Name (GSPN_ID) R

Get Port Type (GPT_ID) R

Get IP address (GIPP_ID) R

Get Fabric Port Name (GFPN_ID) R

Get Hard Address (GHA_ID) R

Get FC-4 Descriptors (GFD_ID) ?

Get FC-4 Features (GFF_ID) ?

Get Port Identifier (GID_PN) R

Get IP Address (GIPP_PN) R

Get Port Identifiers (GID_NN) R

Get Port Names (GPN_NN) ?

Get IP Address - Node Name (GIP_NN) R

Get Initial Process Associator (GIPA_NN) R

Get Symbolic Node Name (GSNN_NN) R

Get Node Name (GNN_IP) R

Get Initial Process Associator (GIPA_IP) R

Get Port Identifiers (GID_FT) R

Get Port Names (GPN_FT) R

Get Node Names (GNN_FT) R

Get Port Identifiers (GID_PT) R

Get Port Identifier (GID_IPP) ?

Get Port Name (GPN_IPP)

Get Port Identifiers (GID_FF)

Register Port Name (RPN_ID) R

Table 8 – Name Server Query Support (Continued)


22


6.1.2.2 Name Server Implementation Notes

Whenever possible, NS-NS communication as defined in FC-SW-2 should be used for distributedname server communication.

If a request is sent to another switch and it's rejected, then one of the following behaviors may be ex-hibited:

a) The original request is rejected if that request is a “direct” query; e.g. GPN_ID Comment: Whatdoes this mean?

b) The original request is rejected if there is no answer to a “search” associated with that request;query; e.g. GID_FT, GID_PN

c) A response is generated for an original request if there is an answer (maybe partial) to a“search” query. e.g. GID_FT

d) ‘GE’ switch-to-switch responses shall use the Small Name Server Object as defined in FC-SW-2.

Register Node Name (RNN_ID) R

Register Class of Service (RCS_ID) R

Register FC-4 Types (RFT_ID) R

Register Symbolic Port Name (RSPN_ID) R

Register Port Type (RPT_ID) R

Register IP Address - Port (RIPP_ID) R

Register Fabric Port Name (RFPN_ID) R

Register Hard Address (RHA_ID) R

Register FC-4 Descriptor (RFD_ID)

Register FC-4 Features (RFF_ID)

Register IP Address - Node (RIP_NN) R

Register Initial Process Associator (RIPA_NN)

R

Register Symbolic Node Name (RSNN_NN) R

Remove All (DA_ID) R

Table 8 – Name Server Query Support (Continued)


23


6.1.3 Zoning

6.1.3.1 Minimum Zoning Configuration Rules

Zoning, as defined in FC-SW-2, shall be supported as shown in table 9.

NOTE – Administration of zones may be vendor specific and is therefore outside the scope of this document.

6.1.3.2 Zone Name

6.1.3.2.1 Name Format

The name field shall contain the ASCII characters that actually specify the name, not including anyrequired fill bytes. Names shall adhere to the following rules:

– A name shall be between 1 and 64 characters in length.

– All characters shall be 7 bit ASCII characters.

– The first character of a given name shall be a letter. A letter is defined as either an upper case(A-Z) character or a lower case (a-z) character.

Table 9 – Zoning Support

Item Support Notes

Soft Zoning based on Name Server R 1

World Wide Port Name Zoning R

World Wide Node Name Zoning P

Overlapping Zones R

Single Active Zone Set R

Full Zone Set Object List A 2

Acquire Change Authorization (ACA)

A 3

Release Change Authorization (RCA)

A 3

Notes:1 Soft Zoning shall be implemented via segmentation of

the Name Server database at the Entry Switch.

2 A Switch which does not support the Full Zone Set Ob-ject List may set the Full Zone Set Object List Lengthfield to 0.

3 If there is a single point of control for management ofthe fabric then a locking mechanism is not required butfabric stability is not guaranteed. The recommendedlocking mechanism is as specified in FC-SW-2, butother locking mechanisms are not prohibited.

24


– Any character other than the first character shall be a lower case character (a-z), an upper casecharacter (A-Z), a number (0-9), or one of the following symbols ($-^_).

6.1.3.2.2 Fill Bytes

In order to ensure that the length of the active zone set name is a multiple of four, fill bytes are addedto the end of the name if required. Fill bytes shall be nulls (hex ‘00’). The number of fill bytes (m) iszero, one, two, or three depending on the length of the name (n). The formula for the number of fillbytes is:

m = (64-n) Modulo 4

6.1.4 Registered State Change Notification

Registered State Change notification shall be supported as per FC-FLA.

6.1.4.1 RSCN (Registered State Change Notification) Notes

SCR and RSCN as described in Fabric Loop Attach (FC-FLA) will be supported. The only restrictionis that there be only a single Effected N_Port ID page per RSCN, i.e. the payload length is fixed at 8bytes.

An RSCN will be delivered to a Nx_Port if and only if:

– the Nx_Port has registered to receive RSCNs (using the SCR ELS);

– the Nx_Port is still logged in to the Fabric (has not gone offline since the SCR);

– the Nx_Port supports Class 2 or Class 3;

– the registration function matches the RSCN type (Fabric detected or Nx_Port detected);

– the domain and area fields of the Affected Nx_Port ID are different from the destination Nx_Port(RSCNs are not delivered to the originating N_Port or to the originating loop);

– zoning is not in effect, or the RSCN is a Fabric format, or the Affected Nx_Port ID is in the samezone as the destination Nx_Port (port and area format RSCNs are filtered by zoning).

If the destination Nx_Port supports Class 3, the RSCN will be sent in Class 3, otherwise it will be sentin Class 2.

6.1.4.2 Fabric Detected RSCNs

An RSCN will be delivered to Nx_Ports that specified registration function 1 (Fabric detected) underthe following conditions:

– Format 0 (port address format, DDAAPP): an N_Port logs in or re-logs in with the Fabric, or im-plicitly logs out (goes offline). The RSCN will be issued after the Name Server database hasbeen updated.

– Format 1 (area address format, DDAA00): loop initialization is complete. The RSCN will be is-sued after the Name Server database has been updated.

25


– Format 2 (domain address format, DD0000): used to indicate a switch management change(change of ethernet IP address, FC-IP address, or symbolic switch name).

– Format 3 (Fabric address format, 000000): a Fabric reconfiguration has occurred (switch or ISLadded to, or removed from the Fabric) or zoning has changed (cfgEnable or cfgDisable issued).

6.1.4.3 Nx_Port Detected RSCNs

An RSCN will be delivered to Nx_Ports that specified registration function 2 (Nx_Port detected) underthe following conditions:

– An RSCN ELS is received from an Nx_Port. The payload will be taken from the received RSCN.

26


7 Discovery and Management

NOTE – Proposal T11/180vX will be rolled into this section when ready.

27


28

TR-XX-200x Methodologies for Interconnects Rev 0.2 February 15, 2000

Annex A: SANMark Level 1(Informative)

A.1 SCOPE

SANMark is a program to facilitate interoperation between FC-4 layer applications. It will address de-vices that are FC-AL or FC-AL-2, FC-PH-3, FC-PLDA Revision 2.1, and FC-FLA revision 2.7 compli-ant. It will enhance the FC-TAPE, FC-FLA, and FC-PLDA profiles addressing areas where thesespecifications are silent or leave optional behaviors which impact application layer interoperability.These guidelines will address FC-2 error and event handling in an FC-4 independent way, such thatit will enhance multiple FC-4 applications, including but not limited to FCP, FC-VI, and IPFC, withouttrying to define FC-4 or FC-2 operations where they are already defined. It will include managementfunctions utilizing the framework presented in IETF MIBs as those MIBs are defined in the near fu-ture. There are three levels of SANMark. Level 1 is to provide guidance to current devices such thatthey do not interfere with existing and future SAN Applications. Level 2 and 3 will be defined at a fu-ture time. Devices that desire to operate in a heterogeneous environment need to meet SANMark re-quirement. Devices that are used in a proprietary configuration or on the backend of a device thathas a FC connection to the SAN environment, and a FC connection to a proprietary/non-SAN backend do not need to follow this standard for the proprietary configuration or the backend connection.

A.2 References

Copies of the following documents can be obtained from ANSI: Approved ANSI standards, approvedand draft international and regional standards (ISO, IEC, CEN/CENELEC, ITUT), and approved anddraft foreign standards (including BSI, JIS, and DIN). For further information, contact ANSI CustomerService Department at 212-642-4900 (phone), 212-302-1286 (fax), or via the World Wide Web at ht-tp://www.ansi.org.

A.3 Approved references

ANSI X3.272:1996, Information Technology - Fibre Channel - Arbitrated Loop (FC-AL)

ANSI X3.230:1994, Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH)

ANSI X3.297:1997, Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH-2)

ANSI X3.303:1998, Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH-3)

ANSI X3.289:1996, Information Technology - Fibre Channel - Fabric Requirements (FC-FG)

ANSI X3.321:1998, Information Technology - Fibre Channel - Switch Topologies and Switch Control(FC-SW)

ANSI X3.TR-18:1997, Information Technology - Fibre Channel - Private Loop Direct Attach (FC-PL-DA)

ANSI X3.TR-20:1998, Information Technology - Fibre Channel - Fabric Loop Attachment (FC-FLA)

ANSI X3.269.1998, Information Technology - SCSI - Fiber Channel Protocol for SCSI (FCP)

3. References under development

29


At the time of publication, the following referenced standards were still under development. For infor-mation on the current status of the documents, or regarding availability, contact the relevant stan-dards body or other organization as indicated.

X3 Project 1305-D, Information Technology - Fibre Channel - Switch Topologies and Switch Control(FC-SW-2)

X3 Project 1315-DT, Information Technology - Fibre Channel - Tape (FC-TAPE)

X3 Project 1133-D, Information Technology - Fibre Channel - Arbitrated Loop (FC-AL-2)

X3 Project 1144-D, Information Technology - SCSI- Fibre Channel Protocol for SCSI Second Revi-sion (FCP-2)

A.4 Guidelines

The following sections detail guidelines related to LIP generation, LIP processing, and error recoverythat are common among all FC-4 Fibre Channel implementations. These guidelines are clarificationsof optional or undefined behaviors in the above associated specifications.

A.4.1 Loop Initialization effects

Loop initialization can cause many undesirable side effects. This section gives guidelines for whatshould and should not be done upon receipt of a LIP. The only exception to the guidelines in thisclause is what should be done on receipt of a Reset LIP addressed to this node.

A.4.1.1 Power On Behavior

A.4.1.1.1 Requirement

During power on, after the transmitter has been enabled and 200 msec of valid 1.0625 GHz signal ator above FC-PH minimum amplitude levels has been driven by the transmitter, an L_Port shall notdisrupt the operation of the loop for more than 95 msec and shall begin forwarding transmissionwords or begin initialization within 95 msec.

Note: This disruption event is caused by the minimum criteria of hubs to cut devices in. This minimumcriteria is a minimum of 200msec of 1.0625 GHz signal at FC-PH minimum amplitude.

Note: This allows most existing implementations to meet this specifications. There are requirementsfor GLM operation to assert Lock_Ref for 10 msec after power on. This may produce a lower boundon this number; however, devices should attempt to make this value as low as possible. A future revi-sion of this specification may lower this number significantly from the current 95 msec, since with by-pass circuits and proper design this should be easily achievable. Bypassing a device during the resettime of a device and then enabling the device and originating LIP at some later time is a valid methodfor limiting the loop disruption at power on.

A.4.1.1.2 Measurement process

If a known bit stream is sent to the receiver of a device and the transmitter of the device is monitored,the time observed between the first valid 10bit character and duplication of the input bit stream or val-id operation of the initialization process shall be less than 95 msec.

30


A.4.1.2 Loop Failure test

Loop failure is defined in FC-AL-2 as loss of synchronization for >100 msec. or loss of signal.


A Port shall not issue a LIP for loop failure prematurely.

A.4.1.2.2 Measurement Process

If loss of synchronization is sent to the device for less than 100msec, the device shall not generate aLIP.

A.4.1.3 Requests for Initialization at power on


Devices shall request only one loop initialization at power up, unless the device attempts to enterOLD-PORT state, after which only one additional loop initialization may be requested


Only one initialization process originated by this port shall be observed, unless the device attempts toenter OLD-PORT state, after which one additional loop initialization may be effected.

A.4.1.4 Device time-out during loop initialization


Some devices may "hang" while trying to effect loop initialization. Because of this, it may be neces-sary for a device to request loop initialization multiple times. If loop initialization has not completedwithin 2 sec., the device may request initialization again. The next time the device shall increase thetime-out to greater than 24 sec. and the third and subsequent times the device increase the time-outto greater than 128 sec. Since FC-AL-2 times out loop initialization in each phase, it is not necessaryfor the device to time-out the initialization; however, if a common driver is written it shall follow thisspecification in timing out the entire initialization process.


For FC-AL-1 devices, upon receipt of LIPs from the device, 12 LIPs are generated to the device, andthen Idles are generated until LIP is again generated. After the first LIP sequence is seen, anotherLIP should not be originated by this device for a minimum of 2 sec. After the second LIP sequence isreceived, 12 LIPs are generated to the device, followed by IDLEs. Another LIP should not be originat-ed by this device for a minimum of 24 sec. After the third and for each subsequent LIP sequence re-ceived, 12 LIPs are generated to the device, followed by IDLEs. Another LIP should not be seen fromthe device for a minimum of 128 sec.

A.4.1.5 Response to LIP


A device shall recognize and forward 12 of the LIPs received within 5 msec, unless it is already inOPEN_INIT and ignoring LIPs for AL_Time.

31



After a device has forwarded ARB(f0) or CLS in the initialization process, send a stream of LIPs to it.Within 5 msec a minimum of 12 LIPs shall be seen at the output of the device. Loop initialization shallbe allowed to complete normally. The device shall be in the participating state if an address wasavailable. The device shall not generate a subsequent LIP.

A.4.1.6 Origination of LISM frames


A device which supports LIM and has not received a higher priority LISM shall originate LISM frameswith a maximum of 5 msec. between LISM frames. FC-AL-1 devices will source IDLEs for 15 msecbefore they begin sourcing LISMs. After this 15 msec of IDLES they shall follow this rule.


Source 12 LIPs to device followed by a continuous stream of IDLEs. Observe the rate at which thedevice originates LISM frames and ensure that they are originated within 5 msec.

A.4.1.7 Forwarding of LISM frames


A device which has received a higher priority LISM shall forward the last LISM recognized with a gapof no more than the maximum of either 5 msec or the delay between received LISM frames betweenthe transmitted frames.


Source 12 LIPs to the device followed by a LISMs with WWN of hex '0000000000000000' inter-spersed with 6 Idles, and a second test interspersed with 1 msec of Idles. Observe the forwardedLISM frames and ensure that they are LISMs with WWN of hex'0000000000000000' and no morethan 5 msec between the forwarded LISM frames.

A.4.1.8 Address Selection


During the first initialization after power on or on reception of LIPr, a device shall take an address dur-ing the LIHA or LISA phase, if an address is available. There are three reasons that the device shalllose its address:

1) Power cycle of the device

2) LIPr directed to the device

3) Another device takes the address in the LIFA or LIPA phase before that device could take its ad-dress (This would happen if two loop segments were joined with overlapping addresses).

In subsequent initialization cycles prior to the device succeeding in FLOGI, the device shall take itsaddress in the LIPA phase if its address is available. After FLOGI has completed, the device shalltake its address in the LIFA phase if its address is available. If a device is using SCSI Mode page 19

32


with the "Disable Soft Address" (DSA) bit set then it shall exit initialization as non-participating if itshard address is unavailable.


After loop initialization has completed, source 12 LIPs to the device and allow the device to completeinitialization and verify that it takes its address in the LIPA phase. If the device has a hard address,complete initialization with another device becoming the LIM and acquiring the DUTs hard address.Initiate loop initialization with no other devices claiming an address and ensure that the DUT takes itspreviously acquired address (not its desired hard address) in the LIPA phase. If the device is publiccapable, repeat the above with a fabric controller on the loop and ensure that the device takes its ad-dress in the LIFA phase, including when the device does not get its hard address in its initial loop ini-tialization.

A.4.1.9 Extent of Initialization on Dual Port devices


On a dual port device a LIP, other than LIPr, on one port shall not cause a LIP on the other port. Ini-tialization on one port shall not cause the other port to lose any frames or state. Initialization on oneport should not cause the other port to impact traffic on its loop. Traffic on a dual ported device shallnot impact traffic on the other port.

Because A Reset LIP is the equivalent of a power on reset, it may impact both ports on a dual porteddevice.


On a dual ported device, after both ports have initialized, originate a LIP to one of the ports, and mon-itor the other port to ensure that there are no LIPs.

A.4.1.10 Loop Map Support


FC-AL-2 requires Loop Map; therefore loop map support shall be provided by all FC-AL-2 Level 1 de-vices. Since non AL-2 devices may be present on the loop, devices must not rely on Loop Map sup-port for functionality. If all devices support Loop Map, then Level 1 devices shall use the Loop Map todetermine what devices are available rather than polling.


A.4.1.11 Device availability after LIP


Ports which have acquired an address in a previous initialization cycle, shall not become non-partici-pating after a LIP is received if their address or another address is still available. If a Port goes non-participating when a LIP is received and does not participate in loop initialization and discovery afterloop initialization, the Port will be assumed to be gone, until the port takes an address in a subse-quent loop initialization, and all pending IOs to that Port will be lost.

33



After the loop has initialized, originate a LIP. Ensure that after loop initialization has completed thePort will respond to an ELS addressed to it.

A.4.2 Events that should not cause LIP

Once the device has initialized and is operational the L_Port should use restraint in generation ofLIPs. The only time in which it is clearly proper to LIP is when the device has been unable to succeedin winning arbitration for > LP_TOV, has experienced loss of word synchronization for greater thanR_T_TOV, Loss of Signal is detected, or has not received a CLS in response to CLS within LP_TOV.A management device that is aware of removal of a device from the loop may LIP to facilitate errorrecovery. The following are specific events that should not cause a LIP.

A.4.2.1 Requirement

The following events shall not result in a LIP being generated on the loop:

Link Error counter overrun (e.g. bad transmission words, CRC errors, etc.);

Unexpected frame reception(e.g. ADISC, ACC, LOGO);

A.4.2.2 Measurement Process

Generate the above events and ensure that no LIP is generated. On an unexpected frame either ofthe following are acceptable responses: Discard frame, send LOGO.

A.4.3 Reception of CLS in response to OPN

A Port may respond to an OPN with an immediate CLS if it has no buffers to allow it to receiveframes.

A.4.3.1 Requirement

If an OPN originator receives a CLS in response to the OPN, it shall give up the loop and may arbi-trate for the loop and attempt the OPN again. The OPN originator shall not originate LIP due to re-ceipt of the CLS.


Generate a CLS in response to an OPN and ensure that the OPN originator does not LIP.

A.4.4 Lack of response to OPN

When an OPN is sent, the responder should in a reasonable time respond with either R_RDYs or aCLS.

A.4.4.1 Requirement

If an OPN responder does not return either R_RDY or CLS within 2xAL_Time the OPN originatorshould originate a CLS. It shall NOT originate a LIP.

34



Generate the above events and ensure that no LIP is generated.

35


36


Annex B: Private Device Fabric Bridging(Informative)

B.1 Introduction

A recent development in Fibre Channel switching has been the introduction of switches which allowprivate Arbitrated Loop devices to operate over a fabric. While this fabric bridging function is currentlyoutside the scope of existing Fibre Channel Standards, these bridging functions typically supportstandard FC-AL or FC-AL-2 private device behavior.

It is the intention of this Annex to introduce some general concepts common to many Private DeviceFabric Bridging implementations. It is not the intention of this Annex to provide detailed specifics onhow these bridging functions are implemented. Nor, is it the intention of this Annex to exhaustivelyexplore all possible behaviors of private device bridging.

B.2 Common Methods

There are two common methods of private device fabric bridging; Public-Private Translation, andHub Emulation.

B.2.1 Public-Private Translation

In public-private translation, the switch performs a function which allows public Nx_Ports to communi-cate with private L_Ports. Typically, in order to perform such a function, a switch does the following:

– Perform translation between public and private addresses.

– Provide a proxy entry in the Name Server for private devices.

– Provide a proxy AL_PA in the loop for public devices.

B.2.2 Hub Emulation

In hub emulation, the switch masquerades as a Fibre Channel hub yet still provides advantages in-herent in a switched environment. These advantages include:

– Increased aggregate bandwidth.

– Fault isolation.

– Increased management access.

B.3 Nx_Port Issues

Even though these features are generally designed to be transparent to an Nx_Port there are stillpossible ramifications introduced by a switch. The following is a list of some of these ramifications. Itis important to note that not every private device bridging implementation has any particular ramifica-tion.

– Data rate. Because of aggregation possible in a switch, an increased data rate may be seen.

– Open exchanges. Because of aggregation possible in a switch, an increased number of openexchanges may be seen.

37


– Intermixed sequences. Depending on the switch implementation, sequences may be intermixedin a way not typically seen on a private loop.

– Authentication. {Editor’s note: We may need to put more substance behind authentication be-tween public and private devices.}

38