0% found this document useful (0 votes)

154 views126 pages

FC PH 3 - 9.1

FC-PH-3_9

Uploaded by

tlidia

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

154 views126 pages

FC PH 3 - 9.1

FC-PH-3_9

Uploaded by

tlidia

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 126

Copies of this document may be purchased from:

Global Engineering, 15 Inverness Way East,

Englewood, CO 80112-5704
Phone: (800) 854-7179 or (303) 792-2181 Fax: (303) 792-2192

dpANS X3.xxx-199x
X3T11/Project 1119D/Rev 9.1

FIBRE CHANNEL
PHYSICAL AND SIGNALLING
INTERFACE - 3 (FC-PH-3)
REV 9.1

working draft proposed

American National Standard
for Information Systems
October 15, 1996
Secretariat:
Information Technology Industry Council
ABSTRACT: This standard describes the enhancement to the ANSI X3.230, Fibre Channel Physical and
Signalling Interface (FC-PH) and to the ANSI X3.297, Fibre Channel Physical and Signalling Interface - 2
(FC-PH-2) and is an addendum to both these documents.
NOTE:
This is a draft proposed American National Standard of Accredited Standards Committee X3. As
such, this is not a completed standard. The X3T11 Technical Committee may modify this document
as a result of comments received during public review and its approval as a standard.
POINTS OF CONTACT:
Roger Cummings (X3T11 Chairman)
Distributed Processing Technology
140 Candace Drive
Maitland, FL 32751
(407) 830-5522 x348 Fax: (407) 260-5366
E-Mail:[email protected]
I. Dal Allan
(Fibre Channel Working Group Chairman)
ENDL
14426 Black Walnut Court
Saratoga, CA 95070
(408) 867-6630
Fax: (408) 867-2115
E-Mail: [email protected]

Carl Zeitler (X3T11 Vice Chairman)

IBM Corporation - AWD, MS 9440
11400 Burnet Road, Austin, TX 78758
(512) 838-1797 Fax: (512) 838-1852
E-Mail: [email protected]
Bryan Cook (Editor)
IBM Corporation, MS P323
522 South Road, Poughkeepsie, NY 12601
(914) 435-7914 Fax: (914) 432-9417
E-Mail: [email protected]

Changed from Revision 9.0:

Revised Clauses 7, 9, and Annex F as a result of the X3T11 Letter Ballot.

Changed BER definition in 5.1 to reflect FC-PH-2.

ANSI
dpANS X3.xxx-199x

draft proposed American National Standard

for Information Technology

Fibre Channel Physical and Signalling Interface - 3
(FC-PH-3)

Secretariat

Information Technology Industry Council

Approved

,199

American National Standards Institute, Inc.

Abstract
This standard describes the enhancement to the ANSI X3.230, Fibre Channel Physical and Signalling Interface (FC-PH) and to the ANSI X3.297, Fibre Channel Physical and Signalling Interface - 2 (FC-PH-2)
and is an addendum to both these documents.

iii

American
National
Standard

Approval of an American National Standard requires verification by ANSI that the

requirements for due process, consensus, and other criteria for approval have
been met by the standards developer.
Consensus is established when, in the judgement of the ANSI Board of Standards
Review, substantial agreement has been reached by directly and materially
affected interests. Substantial agreement means much more than a simple
majority, but not necessarily unanimity. Consensus requires that all views and
objections be considered, and that a concerted effort be made towards their
resolution.
The use of American National Standards is completely voluntary; their existence
does not in any respect preclude anyone, whether he has approved the standards
or not, from manufacturing, marketing, purchasing, or using products, processes,
or procedures not conforming to the standards.
The American National Standards Institute does not develop standards and will in
no circumstances give interpretation on any American National Standard.
Moreover, no person shall have the right or authority to issue an interpretation of
an American National Standard in the name of the American National Standards
Institute. Requests for interpretations should be addressed to the secretariat or
sponsor whose name appears on the title page of this standard.
CAUTION NOTICE: This American National Standard may be revised or
withdrawn at any time. The procedures of the American National Standards
Institute require that action be taken periodically to reaffirm, revise, or withdraw this
standard. Purchasers of American National Standards may receive current
information on all standards by calling or writing the American National Standards
Institute.

Published by

American National Standards Institute

11 W. 42nd Street, New York, New York 10036

Copyright 199x by American National Standards Institute

All rights reserved
No part of this publication may be reproduced in any
form, in an electronic retrieval system or otherwise,
without prior written permission of the publisher.

Printed in the United States of America

INSERT CODE HERE

Contents
Page

Foreword

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction
1 Scope

xviii

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Normative References

. . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 Approved references

xix
1
1

. . . . . . . . . . . . . . . . . . . . . . . . .

2.2 References uder development . . . . . . . . . . . . . . . . . . . . .

3 Definitions and conventions

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1 FC-4 Region . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.2 Profile

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Editorial conventions . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Abbreviations, acronyms and symbols

. . . . . . . . . . . . . . . .

3.3.1 Acronyms and other abbreviations

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

4.16 FC-4 Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 FC-0 functional characteristics . . . . . . . . . . . . . . . . . . . . . . .

3.1 Definitions

4 Structure and concepts

5.1 General Characteristics

. . . . . . . . . . . . . . . . . . . . . . . .

6 Optical fibre interface specification . . . . . . . . . . . . . . . . . . . . .

Electrical cable interface specification . . . . . . . . . . . . . . . . . . .

7.1 Electrical data links

. . . . . . . . . . . . . . . . . . . . . . . . . .

7.2 Reference locations

. . . . . . . . . . . . . . . . . . . . . . . . . .

7.2.1 Intercabinet references

. . . . . . . . . . . . . . . . . . . . . .

7.2.2 Intracabinet references

. . . . . . . . . . . . . . . . . . . . . .

7.3 75 W unbalanced data links

. . . . . . . . . . . . . . . . . . . . . .

7.3.1 ECL compatible driver characteristics . . . . . . . . . . . . . . .

7.3.2 ECL compatible receiver characteristics

7.3.3 Unbalanced cable characteristics

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

7.3.4 Unbalanced cable connectors . . . . . . . . . . . . . . . . . .

7.3.4.1 Intercabinet connectors for unbalanced cable

. . . . . . .

7.3.4.2 Style-1 unbalanced cable connector

. . . . . . . . . . . .

7.3.4.3 Style-2 unbalanced cable connector

. . . . . . . . . . . .

7.3.4.4 Intracabinet connectors for unbalanced cable

. . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

7.4.1 ECL compatible driver characteristics . . . . . . . . . . . . . .

7.4 150W balanced data links

Page

7.4.2 ECL compatible receiver characteristics . . . . . . . . . . . . .

7.4.3 Balanced cable characteristics

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

7.4.4 Balanced cable connectors

7.4.4.1 Intercabinet connectors for balanced cable

. . . . . . . . .

7.4.4.2 Style-1 balanced cable connector . . . . . . . . . . . . . .

7.4.4.3 Style-2 balanced cable connector . . . . . . . . . . . . . .

7.4.4.3.1 Style-2 plug

. . . . . . . . . . . . . . . . . . . . . . .

7.4.4.3.2 Style-2 receptacle . . . . . . . . . . . . . . . . . . . .

7.4.4.4 Optional intercabinet connector pins

. . . . . . . . . . . .

7.4.4.5 Intracabinet connectors for balanced cable

. . . . . . . . .

7.4.4.6 Intracabinet connectors for balanced cable

. . . . . . . . .

8 Optical fibre cable plant specification . . . . . . . . . . . . . . . . . . .

9 Electrical cable plant specification

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

9.1 Unbalanced cable plant

9.1.1 LV (long-video) cable plant specification

9.1.1.1 LV-type
9.1.1.2 Shielding

. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

9.1.2 TV (video) cable plant specification

9.1.2.1 TV-type
9.1.2.2 Shielding

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

9.1.3 MI (miniature) cable plant specification

9.1.3.1 MI-type
9.1.3.2 Shielding

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

9.1.4 Unbalanced cable interoperability

. . . . . . . . . . . . . . . .

9.2 Balanced cable plant . . . . . . . . . . . . . . . . . . . . . . . . .

9.2.1 TP (shielded twisted pair) cable plant specification

. . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

9.2.2 TW cable plant specification . . . . . . . . . . . . . . . . . . .

9.2.1.1 TP-type
9.2.1.2 Shielding

9.2.2.1 TW-type
9.2.2.2 Shielding

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

9.2.3 Balanced cable interoperability

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

10 Optical interface connector specification

11 FC-1 8B/10B Transmission Code

Page

12 FC-1 receiver and transmitter description

. . . . . . . . . . . . . . .

13 Loopback mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14 Diagnostic mode

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 Transmitter safety . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 Ordered sets

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 Frame formats

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18 Frame_Header

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18.3 Address identifiers

. . . . . . . . . . . . . . . . . . . . . . . . .

18.4 Data Structure (TYPE)

. . . . . . . . . . . . . . . . . . . . . . .

18.5 Frame Control (F_CTL)

. . . . . . . . . . . . . . . . . . . . . .

18.6 Sequence_ID (SEQ_ID)

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18.7 DF_CTL

18.9 Word 4, Bits 31-16

. . . . . . . . . . . . . . . . . . . . . . . . .

18.9.1 Originator Exchange_ID (OX_ID)

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

19.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19.2 Expiration_Security_Header

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

18.9.2 Priority
19 Optional headers

19.3 Network_Header

19.3.1 D_NAA or S_NAA

. . . . . . . . . . . . . . . . . . . . . . .

19.3.2.5 CCITT 60-bit address

. . . . . . . . . . . . . . . . . . .

19.4 Association Header . . . . . . . . . . . . . . . . . . . . . . . . .

20 Data frames and responses

20.3 Link_Control

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

20.3.3.2 N_Port Busy (P_BSY)

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20.3.3.3 Reject (P_RJT, F_RJT)

21 Link Services

21.1.1 Default Login values

. . . . . . . . . . . . . . . . . . . . . .

21.2 Basic Link Service commands

. . . . . . . . . . . . . . . . . . .

21.2.7 Dedicated Connection Preempted (PRMT)

21.3 Extended Link Services

31
31

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

21.4 Extended Link Service requests

. . . . . . . . . . . . . . . . . .

21.4.13 Read Timeout Value (RTV) . . . . . . . . . . . . . . . . . .

21.5 Extended Link Service reply Sequences

. . . . . . . . . . . . . .

vii

Page

21.5.2 Link Service Reject (LS_RJT)

. . . . . . . . . . . . . . . . .

21.20 Report Node Capabilities Information (RNC)

22 Classes of Service

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

22.6 Class 6 - Uni-Directional Dedicated Connection

. . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

22.6.1 Class 6 function

22.6.2 Class 6 rules

22.6.3 Class 6 delimiters

. . . . . . . . . . . . . . . . . . . . . . .

22.6.4 Class 6 frame size

. . . . . . . . . . . . . . . . . . . . . . .

22.6.5 Class 6 flow control . . . . . . . . . . . . . . . . . . . . . . .

22.6.6 Stacked Connect-requests

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

23.1 Introduction

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23.2 Applicability

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23.3 Fabric Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23 Login and Service Parameters

23.3.1 Explicit Fabric Login

. . . . . . . . . . . . . . . . . . . . . .

23.3.2 Responses to Fabric Login . . . . . . . . . . . . . . . . . . .

23.3.2.1 FLOGI with S_ID = 0 or 0000yy

. . . . . . . . . . . . . .

23.6 N_Port Service Parameters . . . . . . . . . . . . . . . . . . . . .

23.6.1 N_Port Common Service Parameters

. . . . . . . . . . . . .

23.6.2 N_Port Common Service parameters - Fabric Login . . . . . .

23.6.2.1 FC-PH-3 version

. . . . . . . . . . . . . . . . . . . . . .

23.6.2.2 Buffer-to-buffer credit

23.6.2.3 Common features

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

23.6.2.4 Buffer-to-buffer Data_Field size

. . . . . . . . . . . . . .

23.6.3 N_Port Common Service Parameters - N_Port Login

23.6.3.1 FC-PH-3 version

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

23.6.3.4 Buffer-to-buffer Data_Field size

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

23.6.3.7 Point-to-point E_D_TOV value . . . . . . . . . . . . . . .

23.6.3.5 Total Concurrent Sequences

23.6.3.6 Relative Offset by category

23.6.6 N_Port Class Service Parameters

. . . . . . . . . . . . . . .

23.6.7 N_Port Class Service Parameters - Fabric Login

viii

. . . . .

23.6.3.2 Buffer-to-buffer credit

23.6.3.3 Common features

. . . . . . .

50
52

Page

23.6.7.1 Class Validity (V)

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

23.6.7.3 Initiator control . . . . . . . . . . . . . . . . . . . . . . .

23.6.7.4 Recipient control . . . . . . . . . . . . . . . . . . . . . .

23.6.7.5 Receive Data_Field Size

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

23.6.7.8 Open Sequences per Exchange . . . . . . . . . . . . . .

23.6.7.2 Service Options

23.6.7.6 Concurrent Sequences

23.6.7.7 N_Port End-to-end Credit

23.6.8 N_Port Class Service Parameters - N_Port Login

. . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

23.6.8.3 Initiator control . . . . . . . . . . . . . . . . . . . . . . .

23.6.8.4 Recipient control . . . . . . . . . . . . . . . . . . . . . .

23.6.8.5 Receive Data_Field Size

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

23.6.8.8 Open Sequences per Exchange . . . . . . . . . . . . . .

23.6.8.9 Class 6 Multicast RX_ID . . . . . . . . . . . . . . . . . .

23.6.8.1 Class Validity (V)

23.6.8.2 Service Options

23.6.8.6 Concurrent Sequences

23.6.8.7 N_Port End-to-end Credit

23.6.9 Vendor Version Level

. . . . . . . . . . . . . . . . . . . . .

23.6.10 Services Availability

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

23.7 F_Port Service Parameters

23.7.1 F_Port Common Service Parameters

. . . . . . . . . . . . .

23.7.1.1 FC-PH-3 version . . . . . . . . . . . . . . . . . . . . . .

23.7.1.2 Buffer-to-buffer (F_Port) Credit

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

23.7.1.3 Common features

23.7.1.4 Buffer-to-buffer Data_Field size

. . . . . . . . . . . . . .

23.7.1.5 E_D_TOV

. . . . . . . . . . . . . . . . . . . . . . . . .

23.7.1.6 R_A_TOV

. . . . . . . . . . . . . . . . . . . . . . . . .

23.7.2 F_Port Name . . . . . . . . . . . . . . . . . . . . . . . . . .

23.7.3 Fabric Name

. . . . . . . . . . . . . . . . . . . . . . . . . .

23.7.4 F_Port Class service Parameters

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

23.7.4.3 Initiator control . . . . . . . . . . . . . . . . . . . . . . .

23.7.4.1 Class Validity

23.7.4.2 Service Options

Page

23.7.4.4 Recipient control

. . . . . . . . . . . . . . . . . . . . . .

23.7.4.5 Receive Data_Field Size . . . . . . . . . . . . . . . . . .

23.7.4.6 Concurrent Sequences

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

23.7.4.7 N_Port End-to-end Credit

23.7.4.8 Open Sequences per Exchange

23.7.4.9 C_R_TOV

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

23.7.5 Vendor Version Level

23.7.6 Services Availability

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

23.8 Procedure to estimate end-to-end Credit

. . . . . . . . . . . . . .

24 Exchange, Sequence, and sequence count management

24.3 Summary rules

. . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

24.3.1 Exchange management

. . . . . . . . . . . . . . . . . . . .

24.3.7 Normal ACK processing

. . . . . . . . . . . . . . . . . . . .

24.3.11 Sequence errors - Class 3

. . . . . . . . . . . . . . . . . .

24.3.11.1 Rules common to all Discard policies

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

24.8.1 Exchange Status Block . . . . . . . . . . . . . . . . . . . . .

24.8.2 Sequence Status Block . . . . . . . . . . . . . . . . . . . . .

24.3.11.2 Process with infinite buffers Error Policy

24.8 Status blocks

25 Association Header management and usage

. . . . . . . . . . . . . .

26 Flow control management . . . . . . . . . . . . . . . . . . . . . . . .

27 Segmentation and reassembly

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28.4 Connect/disconnect rules . . . . . . . . . . . . . . . . . . . . . .

28 Connection management
28.1 Introduction

28.4.1 Connect-request rules

. . . . . . . . . . . . . . . . . . . . .

28.4.1.1 Source of connect-request . . . . . . . . . . . . . . . . .

28.5 Establishing a Connection

. . . . . . . . . . . . . . . . . . . . .

28.5.4 Destination of a connect-request . . . . . . . . . . . . . . . .

28.9 Connection Preemption . . . . . . . . . . . . . . . . . . . . . . .

28.9.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . .

28.9.2 Topology Model

. . . . . . . . . . . . . . . . . . . . . . . .

28.9.3 Rules for Preemption . . . . . . . . . . . . . . . . . . . . . .

28.9.3.1 Preemptor (P)

. . . . . . . . . . . . . . . . . . . . . . .

Page

28.9.3.2 Preempted Source (PS)

. . . . . . . . . . . . . . . . . .

28.9.3.3 Preempted Destination(s)(PD)

. . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

28.9.3.4 Preemption Destination(s) (PnD)

28.9.4 Connection Rules

28.9.5 Remove Connection Rules

. . . . . . . . . . . . . . . . . .

28.10 Establishing a Connection Using Preemption . . . . . . . . . . .

28.10.1 Connection Initiator

. . . . . . . . . . . . . . . . . . . . . .

28.10.2 Preemption Destination . . . . . . . . . . . . . . . . . . . .

29 Error detection and recovery

. . . . . . . . . . . . . . . . . . . . . .

29.2.1.2 E_D_TOV

. . . . . . . . . . . . . . . . . . . . . . . . .

29.6 Exchange integrity

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31.2 Class 6 Multicast

30 Hunt Group
31 Multicast

. . . . . . . . . . . . . . . . . . . . . . . . . .

31.2.1 Class 6 Multicast Routing

. . . . . . . . . . . . . . . . . . .

31.2.2 Class 6 Multicast Rules

. . . . . . . . . . . . . . . . . . . .

31.2.3 Class 6 Multicast Server

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

31.2.4 Class 6 Multicast recovery

31.3 Class 3 Multicast

31.3.1 Registration and De-registration

. . . . . . . . . . . . . . . .

31.3.2 Multicast Routing . . . . . . . . . . . . . . . . . . . . . . . .

31.3.3 Class 3 Multicast rules

. . . . . . . . . . . . . . . . . . . . .

31.4 Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31.5 Moviecast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31.6 Other

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32 Aliases

33 Dedicated Simplex

. . . . . . . . . . . . . . . . . . . . . . . . . . .

34 Class 4- Fractional

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35 Camp-On

36 Stacked Connect Request

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

37 Buffered Class 1 Service

38 Data Compression

39 Clock synchronization service

. . . . . . . . . . . . . . . . . . . . .

Page

39.1 Introduction

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39.1.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . .

39.1.2 Function

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

39.2 Communications Model . . . . . . . . . . . . . . . . . . . . . . .

39.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39.3.1 Server Rules

. . . . . . . . . . . . . . . . . . . . . . . . . .

39.3.2 Client Rules

. . . . . . . . . . . . . . . . . . . . . . . . . .

39.4 Clock Synchronization Control

. . . . . . . . . . . . . . . . . . .

39.4.1 Use of FC-PH Constructs

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

39.4.1.1 Login/Logout

39.4.1.1.1 Initiator Capability

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

39.4.1.3 Information Units . . . . . . . . . . . . . . . . . . . . . .

39.4.1.4 Common Required FC Parameters

. . . . . . . . . . . .

39.4.1.5 Common Optional FC Parameters . . . . . . . . . . . . .

39.4.1.6 CT_HDR

39.4.1.1.2 Recipient Capability

39.4.1.2 Exchanges

. . . . . . . . . . . . . . . . . . . . . . . . . .

39.4.2 Clock Control Request

. . . . . . . . . . . . . . . . . . . . .

39.4.3 Clock Control Link Service

. . . . . . . . . . . . . . . . . . .

39.4.3.1 Clock Control (CSS_CC) . . . . . . . . . . . . . . . . . .

39.5 Synchronize Clock Request

. . . . . . . . . . . . . . . . . . . .

39.5.1 Primitive Signal Service

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

39.5.1.1 Terms

39.5.1.2 Synchronize Clock Request

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

39.5.1.4 Primitive Signal Insertion . . . . . . . . . . . . . . . . . .

39.5.1.3 Synchronize Clock Accept

39.5.2 ELS Service

. . . . . . . . . . . . . . . . . . . . . . . . . .

39.5.2.1 Synchronize Clock Link Service

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

40 Data Encryption

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40.1 Introduction

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

39.5.2.2 Synchronize Clock (CSS_SC)

40.2 N_Port Login

40.2.1 Initiator Capability

40.2.2 Recipient Capability

xii

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

Page

40.2.3 F_CTL

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40.4 Decryption

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Annexes

100

xiii

Page

xiv

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

102

Page

Tables
1

FC-0 physical links for electrical cable classes

. . . . . . . . . . . . . .

FC-0 physical links for electrical cable classes (continued)

Eye diagram mask at point-S

. . . . . . . . . . . . . . . . . . . . . .

Eye diagram mask at point-R

. . . . . . . . . . . . . . . . . . . . .

Optional intercabinet contact uses

. . . . . . .

6
7

. . . . . . . . . . . . . . . . . . .

LV-style cable plant

. . . . . . . . . . . . . . . . . . . . . . . . . . .

TV-style cable plant

. . . . . . . . . . . . . . . . . . . . . . . . . . .

MI-style cable plant

. . . . . . . . . . . . . . . . . . . . . . . . . . .

TP-style cable plant

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

TW-style cable plant

Well-known Address identifiers

Type codes - FC-4 (Device_Data and Link_Data)

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

(Page 1 of 2) - F_CTL field

. . . . . . . . . . . . . . . . . . . . . .

(Page 2 of 2) - F_CTL field

. . . . . . . . . . . . . . . . . . . . . .

Data encryption status

. . . . . . . . . . . . . . . . . . . . . . . .

DF_CTL bit definition

. . . . . . . . . . . . . . . . . . . . . . . . .

Priority/Preemption enabled

Priority/Preemption not enabled

NAA identifiers

Association_Header Validity bits (Bits 63-56)

P_BSY Reason Codes

P_RJT or F_RJT Reason Codes

Basic Link Service Commands

Extended Link Service Commands

. . . . . . . . . . . . . . . . . .

Extended Link Service Commands

. . . . . . . . . . . . . . . . . .

RTV Payload

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RTV Accept Payload

LS_RJT reason code explanation

RNC/ACC Payload

Capability Entry

Document Identifiers

Responses to FLOGI frame (S_ID = 0 or 0000yy) - Fabric Login

N_Port Common Service Parameter Applicability

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . .

. . . . . . . . . . .

Page

FC-PH-3 Version

N_Port Class Service Parameter Applicability

. . . . . . . . . . . . .

N_Port Class Service Parameter Applicability

. . . . . . . . . . . . .

Exchange Status Block

. . . . . . . . . . . . . . . . . . . . . . . .

Sequence Status Block

. . . . . . . . . . . . . . . . . . . . . . . .

Responses to Preemption Requests

CSS_CC Payload

CSS_CC Accept Payload

Data Character Translation

CSS_SC Payload

CSS_SC Accept Payload

xvi

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

Page

Figures
1

Document relationship

. . . . . . . . . . . . . . . . . . . . . . . . .

Fabric Regions

FC-4 Regions

FC-0 with 75W unbalanced cable

. . . . . . . . . . . . . . . . . . . .

Unbalanced transmitter test circuit

. . . . . . . . . . . . . . . . . . . .

Eye diagram mask at point-S

. . . . . . . . . . . . . . . . . . . . . .

Eye diagram mask at point-R

. . . . . . . . . . . . . . . . . . . . .

FC-0 with 150W balanced cable link

Balanced transmitter test circuit

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

Style-1 balanced connector pin assignments

. . . . . . . . . . . . .

Style-2 plug

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Style-2 receptacle

Style-2 balanced connector receptacle pin locations

Balanced cable wiring

Optional headers order

Association_Header

FLOGI, PLOGI, or ACC Payload

N_Port Common Service Parameters - Fabric Login

. . . . . . . . .

N_Port Common Service Parameters - N_Port Login

. . . . . . . . .

N_Port Class Service Parameters - Fabric Login

. . . . . . . . . . .

N_Port Class Service Parameters - N_Port Login

. . . . . . . . . .

F_Port Common Service Parameters - Fabric Login

. . . . . . . . .

F_Port Class Service Parameters - Fabric Login

. . . . . . . . . . .

Class 6 Multicast Routing

. . . . . . . . . . . . . . . . . . . . . . .

Class 3 Multicast Routing

. . . . . . . . . . . . . . . . . . . . . . .

Clock Synchronization Model

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

Real Time Loop Topology

. . . . . . . . . . . . . . . . . . . . . . .

Real Time Protocol Stack

. . . . . . . . . . . . . . . . . . . . . . .

Failure Detect and Re-routing

TDM Window

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xvii

Foreword

(This Foreword is not part of dpANS X3.xxx-199x.)

This Fibre Channel, Physical and Signalling Interface - 3 standard (FC-PH-3) describes the enhancements to the ANSI X3.230 FC-PH and X3.297 FC-PH-2 and
is an addendum to both these documents.
This standard was developed by Task Group X3T11 of Accredited Standards
Committee X3 during 1995-6. The standards approval process started in 1996.
This standard includes annexes, which are informative, and are not considered
part of the standard.
Requests for interpretation, suggestions for improvement or addenda, or defect
reports are welcome. They should be sent to the X3 Secretariat, Information
Technology Industry Council, 1250 Eye Street, NW, Suite 200, Washington, DC
20005.
NOTE: The developers of this standard have requested that holders of patents that may be
required 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. No position is taken with respect
to the validity of any claim or any patent rights that may have been disclosed. Details may
be obtained from the publisher concerning any statement of patents and willingness to
grant a license on a nondiscriminatory basis and with reasonable terms and conditions to
applicants desiring to obtain such a license.

This standard was processed and approved for submittal to ANSI by Accredited
Standard Committee on Information Processing Systems, X3. Committee approval of the standard does not necessarily imply that all committee members voted
for approval. At the time it approved this standard, the X3 Committee had the following members:
TBD, Chair
TBD, Vice-Chair
TBD, Secretary
Organization Represented
Name of Representative
TBD ............................................................................................. TBD
TBD

Task Group X3T11 on Device Level Interfaces, which developed this standard,
had the following participants:
Roger Cummings, Chair
Carl Zeitler, Vice-Chair
Bryan Cook, FC-PH-3 Technical Editor

xviii

Introduction

Introduction
A set of advanced capabilities to FC-PH and FC-PH-2 are provided in FC-PH-3 to
support some sophisticated application requirements.The advanced capabilities
include features such as:
Class 3 process policy
Time distribution and clock synchronization
E_D_TOV resolution enhancement
Addition of new Extended Link Services:
Report Node Capability information
Expanded copper media variants
Class 6 service (Uni-directional Dedicated Connection)
Priority and Preemption capabilities
and others
These capabilities are accomplished by defining FC-3 Common Services, and
enriching and complementing FC-2 Signaling protocol and FC-0 physical media
and transceivers defined in FC-PH and FC-PH-2:
FC-3 defines a set of services which are common across multiple ports of a
node.
FC-2 enhancements include E_D_TOV resolution refinements, Process error
policy extensions, especially for Class 3, Time distribution, Clock synchronization, new Extended Link Service commands, and others.
FC-0 enhancements define new variants for the copper media
Figure shows the relationship of this American National Standard (the highlighted
rectangle) with other Fibre Channel standards and draft proposed standards. FCPH-3 specifies the enhanced functions added to FC-PH, FC-PH-2. FC-FG and
FC-SW are related to Fabric requirements. FC-AL specifies the arbitrated loop topology. FC-GS is related to Fibre Channel Services requirements. FC-IG provides
some implementation guidance. FC-SB; ANSI X3.254, FC-FP; FC-LE; FC-ATM;
IPI-3 Disk revision; IPI-3 Tape revision and SCSI-FCP are FC-4 standards.

xix

FC-SB
Mapping to Single Byte
Command Code Sets

FC-LE
Link
Encapsulation

IPI-3 Disk
Revision to
IPI-3 Disk Std.

Other
FC upper-layer
protocols

FC-FP
Mapping to HIPPI
Framing Protocol

FC-ATM
Mapping of
ATM/AAL5

IPI-3 Tape
Revision to
IPI-3 Tape Std.

SCSI-FCP
SCSI-3 Fibre
Channel Protocol

FC-PH-3
Fibre Channel Physical
and Signalling Interface - 3
FC-PH-2 (ANSI X3.xxx)
Fibre Channel Physical
and Signalling Interface - 2
FC-PH (ANSI X3.230)
Fibre Channel Physical
and Signalling Interface
FC-IG
Fibre Channel
Implementation Guide

FC-AL
Arbitrated Loop
FC-SW
Switch Topology

FC-FG
Fabric Generic requirements
FC-GS
Generic Services

Document relationship

dpANS X3.xxx-199x

draft proposed AMERICAN NATIONAL STANDARD

draft proposed American National Standard

for Information Technology

Fibre Channel
Physical and Signalling Protocol - 3 (FC-PH-3)

Scope

FC-PH-3 describes the enhancement to the

ANSI X3.230, FC-PH and to the ANSI X3.xxx,
FC-PH-2 and is an addendum to the FC-PH
and FC-PH-2 documents.

Normative References

The following standards contain provisions

which, through reference in this text, constitute
pro visio ns of th is s tan da rd. At th e time of
publication, the editions indicated were valid. All
standards are subject to revision, and parties to
agreements based on this standard are encouraged to investigate the possibility of applying the
most recent editions of the standards listed below.
Copies of the following documents can be obtained from ANSI: Approved ANSI standards, approved and draft international and regional
standards (ISO, IEC, CEN/CENELEC, ITUT),
an d a pp ro ved a nd dra ft for eign stan d ard s
(including BSI, JIS, and DIN). For further information, contact ANSI Customer Service Department at 212-642-4900 (phone), 212-302-1286
(fax) or via the World Wide Web at http://www.ansi.org.
2.1

Approved references

ANSI X3.230-1994, Fibre Channel Physical and

Signalling Interface (FC-PH)

This document is an extension to the FC-PH

and FC-PH-2 standards and describes a set of
advanced capabilities beyond both FC-PH and
FC-PH-2 to support more advanced and specialized applications.

X3.702D-199x - High Performance Parallel Interface Framing Protocol (HIPPI-FP)

2.2

References uder development

At the time of publication, the following referenced standards were still under development. For information on the current status of
the documents, or regarding availability, contact the relevant standards body or other organization as indicated.2
ANSI X3.xxx-199x, Fibre Channel Physical and
Signalling Protocol - 2 (FC-PH-2)
ANSI X3.xxx-199x, Fibre Channel-Fabric Requirements (FC-FG)
ANSI X3.xxx-199x, Fibre Channel-Arbitrated
Loop (FC-AL)
ANSI X3.xxx-199x, Fibre Channel-Switch Topology (FC-SW)
ANSI X3.xxx-199x, Fibre Channel-SBCC Mapping Protocol (FC-SB)
ANSI X3.xxx-199x, Fibre Channel-Link Encapsulation (FC-LE)

ANSI X3T10/995D, SCSI-3 Primary Commands

ANSI X3.131-199x - Small Computer System Interface (SCSI-2)
X3.132-1990 - Intelligent Peripheral Interface
(IPI-3)

For information about obtaining copies of

these documents or more information on the
current status of these documents, contact
the X3 Secretariat at: http://www.x3.org or
202-626-5738.
1

dpANS X3.xxx-199x

Definitions and conventions

For F C-PH -3 , the follo wing de fin itions,

conventions, abbreviations, acronyms, and
symbols apply, in addition to those defined in
X3.230-1994 (FC-PH) and X3.xxx-1995 (FC-PH2).
3.1

Definitions

3.1.1

FC-4 Region

A set of N_Ports connected either point-to-point

or to a common Fabric, such that any N_Port in
the set can successfully complete the N_Port Login procedure with all other N_Ports in the set
and successfully maintain an Exchange for a
particular FC-4.
3.1.2

Profile

An interoperability specification that provides implementation guidelines for systems maufacturers, system integrator s, component
manufacturers, and users seeking to design and
select interoperable Fibre Channel peripherals,
hosts, and components. A Profile specifies particular settings for various Fibre Channel physical, link-level, and upper-level protocol options to
enhance interoperability.
3.2

Editorial conventions

En h a n c e me n t s t o co n v e n t io n s d e fi n e d i n
X3.230-1994 (FC-PH) and X3.xxx-1995 (FC-PH2) are specified.
3.3

Abbreviations, acronyms and symbols

Abbreviations, acronyms and symbols applicable

to this standard are listed. Definitions of several
of these items are included in 3.1 The index at
the back of the document is an aid to help locate
these terms in the body of the document.
3.3.1

Acronyms and other abbreviations

NTP

Network Time Protocol

REQCS

Request Clock Synchronization

RNC

Report Node Capability

P_AS

Process_Associator

O_AS

Operation_Associator

dpANS X3.xxx-199x

Structure and concepts

This clause provides an overview of the structure, concepts, and mechanisms used in FCPH-3 and is intended for informational purposes only.

4.16

FC-4 Regions

FC-FG defines a Region as a section of a SubFabric such that all the N_Ports in that Region
operate at the same data rate and the same
Class of Service. Additionally, the N_Ports within the Region share the same Regional Service
Parameters, e.g., address assignment mode,
in-order frame delivery. Essentially, this means

that all N_Ports within a Region are able to successfully perform the PLOGI procedure with
each other. Figure 110 illustrates a set of N_
Ports across 2 Regions: N_Ports A, B, C, and D
are in Region 1 because they all support Class
1 at 1 Gbit/second. N_Ports D, E, and F are in
Region 2 because they all support Class 2 at 1
Gbit/second. Note that N_Port D is in both Regions.
However, just because a pair of N_Ports can
execute a PLOGI-ACC with each other does
not guarantee that they can successfully perform an FC-4 Exchange. For example, N_Port
B that requires an Initial Process_Associator is
not capable of communicating with N_Port A
that does not support the Initial Process_Associator.

Region 2

Region 1
N_Port A
Class 1
1 GB/sec
P_AS not supported

N_Port D
Class 1 & 2
1 GB/sec
P_AS Supported

N_Port E
Class 2
1 GB/sec
P_AS not supported

N_Port B
Class 1
1 GB/sec
P_AS Required

N_Port C
Class 1
1 GB/sec
P_AS Supported

N_Port F
Class 2
1 GB/sec
P_AS not supported

Figure 110 Fabric Regions

dpANS X3.xxx-199x
Therefore, the term FC-4 Region is used to define a set of N_Ports within a Fabric Region
which can successfully communicate via FC-4
Exchanges. That is, all their PLOGI Service Parameters are such that they can successfully
originate an Exchange for the purpose of supporting an FC-4 protocol. Figure 111 illustrates
the same set of N_Ports, now in 3 FC-4 Regions: N_Ports A, C, and D are in Region 1 because they all support Class 1 at 1 Gbit/second
and they all will not use the Initial Process Associator, as determined by PLOGI. N_Ports D,

E, and F are in Region 2 because they all support Class 2 at 1 GBit/second and they all will
not use the Initial Process Associator, as determined by PLOGI. N_Ports B, C, and D are in
Region 3 because they all support Class 1 at 1
Gbit/second and they all will use the Initial Process Associator, as determined by PLOGI.

Region 2
Region 1
N_Port A
Class 1
1 GB/sec
P_AS not supported

N_Port D
Class 1 & 2

N_Port E
Class 2

1 GB/sec
P_AS Supported

1 GB/sec
P_AS not supported

N_Port B

N_Port C

N_Port F

Class 1
1 GB/sec
P_AS Required

Class 1
1 GB/sec
P_AS Supported

Class 2
1 GB/sec
P_AS not supported

Region 3

Figure 111 FC-4 Regions

dpANS X3.xxx-199x

FC-0 functional characteristics

The third unordered list item in 5.1 is replaced

as described.
5.1

General Characteristics

FC-0 has the following general characteristics:

No change from FC-PH.

No change from FC-PH-2.

The FC-2 protocol is designed to operate

across connections having a BER detected at
the receiving node of 10 -12 . It shall be the
combined responsibility of the component
vendors and the system integrator to ensure
that this level of service is provided in a given
Fibre Channel installation.

Optical fibre interface specification

No enhancements from X3.230-1994 (FC-PH)

or x3.xxx-1995 (FC-PH-2).

dpANS X3.xxx-199x

7 Electrical cable interface specification

This clause defines the interfaces of the serial
electrical signal at the interconnect receptacles.
Each conforming electrical FC attachment shall
be compatible with this serial electrical interface
to allow interoperability within an FC environment. All Fibre Channel links described in this
clause shall operate within the BER objective
(10-12). The parameters specified in this clause

support meeting that requirement under all conditions including the minimum input and output
amplitude levels. The corresponding cable plant
specifications are described in clause 9.
The link distance capability specified in table 10
is based on insuring interoperability across multiple vendors supplying the technologies (both
link transceivers and cable plants) under the tolerance limits specified in the document. Links

Table 10 FC-0 physical links for electrical cable classes

FC-0

Units

100-LV-EL-S
100-TV-EL-S
100-MI-EL-S
100-TP-EL-S
100-TW-EL-S

Data Rate
Nominal Bit Rate
Tolerance

MB/s.
MBaud
ppm

100
1 062,5
100

50
531,25
100

25
265,625
100

12,5
132,812 5
100

meters
meters
meters
meters
meters

0-24
0-20
0-5.6
0-11
0-13

0-33
0-28
0-7.6
0-16
0-18

0-47
0-40
0-11
0-22
0-26

0-67
0-56
0-16
0-32
0-37

meters
meters
meters
meters
meters

0-59
0-50
0-14
0-28
0-33

0-84
0-71
0-19
0-40
0-46

0-100
0-100
0-28
0-57
0-66

0-100
0-100
0-42
0-80
0-93

(nom.)
(nom.)
(nom.)
(nom.)
(nom.)

75
75
75
150
150

ps
ps

100
800

200
1000

400
1200

800
1400

7515
15030

755
15010

Operating Distance
Intracabinet
LV
TV
MI
TP
TW
Intercabinet
LV
TV
MI
TP
TW
Cable Impedance
LV
TV
MI
TP
TW
Link Impedance @ S
TDR Rise Time
Exception Window
Through Connection
Unbalanced
Balanced
Cable
Unbalanced
Balanced

50-LV-EL-S
50-TV-EL-S
50-MI-EL-S
50-TP-EL-S
50-TW-EL-S

25-LV-EL-S
25-TV-EL-S
25-MI-EL-S
25-TP-EL-S
25-TW-EL-S

12-LV-EL-S
12-TV-EL-S
12-MI-EL-S
12-TP-EL-S
12-TW-EL-S

dpANS X3.xxx-199x
Table 10 FC-0 physical links for electrical cable classes (continued)
100-LV-EL-S
100-TV-EL-S
100-MI-EL-S
100-TP-EL-S
100-TW-EL-S

50-LV-EL-S
50-TV-EL-S
50-MI-EL-S
50-TP-EL-S
50-TW-EL-S

25-LV-EL-S
25-TV-EL-S
25-MI-EL-S
25-TP-EL-S
25-TW-EL-S

FC-0

Units

Transmitter (S)

Output characteristics at the cable connector

(when transmitting any primitive signal or sequence)

Type
Amplitude
Intracabinet
Max
Min
Intercabinet
Max
Min
Deterministic Jitter
Random Jitter
Rise/Fall Time 20-80%
maximum
minimum
Imbalance
Skew
Receiver (R)
Minimum Sensitivity
Input Impedance @ R
TDR Rise Time
Exception Window
Through Connection
Unbalanced Inputs
Balanced Input
At Termination
Unbalanced Inputs
Balanced Inputs
Differential Skew

12-LV-EL-S
12-TV-EL-S
12-MI-EL-S
12-TP-EL-S
12-TW-EL-S

ECL/PECL

mV(p-p)
mV(p-p)

1600
600

mV(p-p)
mV(p-p)
%(p-p)
%(p-p)

2000
1100
10
12

2000
1100
10
8

ps
ps

385
100

772
200

1540
400

3020
800

100

200

Input characteristics at the cable connector

(when receiving any primitive signal or sequence)
mV(p-p)

400

ps
ps

100
800

200
1000

400
1200

800
1400

7515
15030

755
15010
200

755
15010
400

755
15010
800

755
15010
1600

operating at these maximum distances may require some form of equalization in the cable
plant to meet all link requirements. Greater link
distances may be obtained by specifically engineering a link based on knowledge of the technology characteristics and the conditions under
which the link is installed and operated. However, such link distance extensions are outside the
scope of this standard.
The user needs to take care that their use conditions at least conform to the specified signal
conditions of the document

7.1

Electrical data links

The electrical data link definitions apply to all

styles of unbalanced cable (the 75 LV, TV, and
MI style coax), and balanced cable (the 150
TP and TW cables). The electrical characteristics of these links are defined in tables 10, 11,
and 12, and in figures 29 and 30.
The operating distance limits listed in table 10
are based on the minimum launch amplitude,
delivered to a receiver requiring the minimum input amplitude, through a cable having the loss
characteristics listed in clause 9.

dpANS X3.xxx-199x
b

BNC

75
COAX

TX
TRANSMIT
NETWORK

RX
TNC

RECEIVE
NETWORK

Figure 27 FC-0 with 75 unbalanced cable

NOTE All specifications, unless specifically listed
otherwise, are based on differential measurements.
NOTE All times indicated for TDR measurements are recorded times. Recorded times are
twice the transit time of the TDR signal.
NOTE The transmit imbalance skew and receiver differential skew are the maximum allowed time
difference (on both low-to-high and high-to low
transitions) between the true and complement signals. This time difference is measured at the midway point on the signal swing of the true and
complement signals. These are single ended measurements.
NOTE The transmitter imbalance skew measurement is only valid for balanced driver configurations. It defines the maximum timing difference, as
measured at point-S, of the true and complement
signals generated by the balanced media driver.
The differential skew specification at the receiver
consists of this same measurement made at pointR. The receiver skew requirement assumes a
combined maximum transmitter and maximum cable skew.
NOTE The link impedance measurement identifies the impedance mismatches present in the cable plant when terminated in its characteristic
impedance. This measurement includes mated
connectors at both ends of the cable (points S/S
and R/R) and any intermediate connectors or
splices between these locations. The link termination shall match that shown in figures 28 and 32.
NOTE The exception window used with specific
impedance measurements identifies the maximum
time period during which the measured impedance
is allowed to exceed the listed impedance tolerance.
NOTE The maximum excursion within the exception window at points-S and -R shall not exceed 33% of the nominal cable impedance.
NOTE The link impedance at point-S, for the cable, shall be recorded 4,0 ns following the reference location determined by an open connector
between point-S and S.

NOTE The input impedance at point-R, for the

termination, shall be recorded 4,0 ns following the
reference location determined by an open connector between point-R and R
NOTE The transmitter amplitude maximum
specification identifies the maximum p-p signal
that can be delivered into a resistive load matching
that shown in figures 28 and 32.
NOTE The transmitter amplitude minimum specification identifies the minimum allowed p-p eye
amplitude opening that can be delivered into a resistive load matching that shown in figures 28 and
32.
NOTE The transmitter jitter specifications are
presently under review and may change in a future
release of this standard.
NOTE The receiver sensitivity identifies the minimum p-p eye amplitude at point-R to meet the
BER objective.
NOTE The maximum operable distance for a
specific link type is calculated by dividing the loss
per meter at the half-Baud frequency (listed in
clause 9), into the available link-loss budget. This
loss budget is calculated as 20log(output_amplitude/min_input_amplitude) for a specific link implementation.

All styles of unbalanced (coaxial) cables are interoperable; i.e., electrically compatible with minor impact on link-length capability when
intermixed. The balanced (TP and TW) cables
are also interoperable. Interoperability implies
that the transmitter and receiver level specifications, as measured in figures 27 and 31, and defined in tables 10, 11, and 12, are preserved with
the trade-off being distance capability in an intermixed system. Other electrically compatible,
interoperable unbalanced or balanced cables
may be used to achieve goals of longer distance, higher data rate, or lower cost as desired
in the system implementation, provided that
they are connector, impedance, and propagation mode compatible.

dpANS X3.xxx-199x
The balanced cables are incompatible with unbalanced cables in terms of characteristic impedance, mode of connection to the transceiver,
and other electrical and mechanical parameters.
Different connectors are specified for balanced
and unbalanced cables to avoid user mixing.
Schematics in the diagrams in this clause are for
illustration only and do not represent the only
feasible implementation. The links described in
this clause shall be applied only to homogenous
ground applications such as between devices
within a cabinet or rack, or between cabinets interconnected by a common ground return or
ground plane. This restriction minimizes safety
and interference concerns caused by any voltage differences that could otherwise exist between equipment grounds.
The recommended interface to electrical transmission media is via transformer coupling for intercabinet connections and via capacitive
coupling for intracabinet connections.
7.2

Reference locations

All interface specifications are only valid at the

point of entry and exit from the equipment.
These points are identified as point-S, -S, -R,
and -R in all related tables and figures. This assumes that all measurements are made after a
mated connector pair, relative to the source or
destination.
7.2.1

Intercabinet references

The reference points for all connections between cabinets are those points-S, -S,- R, and R where the cabinet Faraday shield transitions
between the cabinet and the cable shield. If sections of transmission line exist within the Faraday shield, they are considered to be part of the
associated transmit or receive network, and not
part of the cable plant.
7.2.2

Intracabinet references

The reference points for all connections within a

cabinet are those points-S, -S, -R, and -R
where the serial data signal passes through its
first mateable connector.
7.3
7.3.1
tics

75 unbalanced data links

ECL compatible driver characteris-

TX
TY

TRANSMIT
NETWORK

75 1%

Figure 28 Unbalanced transmitter test

circuit
ic (ECL), as mea sured at point-b. Fo r all
intercabinet links, the output driver shall be AC
coupled to the cable through a transmission network, and have output levels, measured at the
input to the cable (point-S), as listed in table 11,
when terminated as shown in figure 28. For all
intracabinet links the driver my be either AC or
DC-coupled to the media.
The mask of the transmitter eye diagram is given in figure 29. The normalized transmitter outp ut timing and diffe ren tial amp litu de
requirements are specified in tables 10 and 11.
The Y1 and Y2 amplitudes in table 11 are set to
allow signal overshoot of 10% and undershoot
of 20%, relative to the amplitudes determined to
be a logic 1 and 0.
NOTE The normalized 1 is that amplitude determined to be the average amplitude when driving a
logic 1. The normalized 0 is that amplitude determined to be the average amplitude when driving a
logic 0.

7.3.2
tics

ECL compatible receiver characteris-

The receiver shall be AC-coupled to the media

through a receive network located between
points-R and -c as shown in figure 27. The receive network shall terminate the link by an
equivalent impedance of 75.
An optional equalizer network, when present in
a link, shall exist and operate as part of the cable
plant. It shall be used to correct for frequency
selective attenuation loss of the transmitted signal, as well as timing variations due to the differences in propagation delay time between higher
and lower frequency components. An equalizer
should need no adjustment. A more detailed discussion of an equalizer is found in Annex F.

The output driver is assumed to have output levels approximating those of Emitter Coupled Log9

dpANS X3.xxx-199x
Table 11 Eye diagram mask at point-S
Normalized
Time

Normalized
Amplitude

132,818 5

0,09

0,29

0,2

0,1

300 mV

800 mV

550 mV

1000 mV

265,625

0,09

0,29

0,2

0,1

300 mV

800 mV

550 mV

1000 mV

531,25

0,11

0,30

0,2

0,1

300 mV

800 mV

550 mV

1000 mV

1 062,5

0,11

0,30

0,2

0,1

300 mV

800 mV

550 mV

1000 mV

Bit rate
(MBaud)

Intracabinet
Differential Amplitude

A (minimum) B (maximum) A (minimum) B (maximum)

The receiver shall operate within the BER objective (10-12) when an unbalanced data link is driven by a transmitter meeting the requirements
defined in tables 10, 11, and figure 29, and a signal is delivered to the receiver meeting the eye
diagram requirements specified in table 12 and
figure 30.
The unbalanced data link characteristics of
maximum path penalty and input impedance of
the receiver are specified in table 10.
The mask of the receiver eye diagram is given in
figure 30. The receiver input is specified in table
12.
NOTE The receiver (at point-c) must accommodate 10% of a bit period more total jitter than that
listed in table 12. This 10% jitter allocation is to allow for any external EMI induced events.
NOTE The minimum input amplitude to the receiver listed in table 12 is a worst case specification across all e nvironmental cond itions.
Restricted environments may allow operation at
lower minimum differential voltages, allowing significantly longer operating distances.

0.5

-A

0
-B
0

1-x2 1-x1 1
Normalized Time
Figure 29 Eye diagram mask at point-S
x1 x2

132,818 5 0,30

0,6

200 mV

1000 mV

265,625

0,30

0,6

200 mV

1000 mV

531,25

0,30

0,6

200 mV

1000 mV

1 062,5

0,30

0,6

200 mV

1000 mV

7.3.3

Unbalanced cable characteristics

The 75 unbalanced data links may be interconnected using any specified unbalanced cable depending on the performance and distance
required for a specific application.
The cable shield(s) shall be grounded through
the bulkhead connectors on both the transmitter
and receiver ends as shown in figure 27.

Differential Amplitude

1-Y1

Differential Amplitude

Normalized Amplitude

Bit rate
(MBaud)

-Y2

Table 12 Eye diagram mask at point-R

1+Y2

Intercabinet
Differential Amplitude

Y1
0
-Y1

-Y2
0

1
x2 1-x1
x1
Normalized Time
Figure 30 Eye diagram mask at point-R

dpANS X3.xxx-199x
7.3.4

Unbalanced cable connectors

7.3 .4.1 Intercabinet connec tors for

unbalanced cable
Connections between cabinets require the use
of shielded cable assemblies, terminated in polarized shielded connectors. All unbalanced cable types shall be connected using either style-1
or style-2 unbalanced connectors.
Standard cable assembles shall have either
proper varieties of style-1 connectors at both
ends of the cable, or style-2 connectors at both
ends of the cable. Cables may also be constructed with both a style-1 and style-2 connector for use in mixed installations or to adapt from
one style to the other.
The cable connector shall be the plug or male
connector while the bulkhead connector shall be
the receptacle or female connector.
7.3.4.2 Style-1 unbalanced cable connector
The style-1 connectors for unbalanced cable
shall be industry standard 75 BNC and TNC
type connectors, as shown in figure 27. The
electrical performance of the 75 BNC and TNC
connectors shall be compatible with video style
connectors specified by IEC 169-8 and IEC 16917.
The mechanical compatibility for BNC type (bayonet lock coupling) connectors is defined by IEC
169-8. The mechanical compatibility for TNC
type (threaded coupling) connectors is defined
by IEC 169-17. Primary use of unbalanced cables are for interconnection of cabinets.
These two connector types (BNC and TNC) are
specified to provide polarization to prevent the
incorrect connection of transmitter-to-transmitter or receiver-to-receiver. The end of such a cable, connected to an unbalanced transmitter,
shall be implemented with a male BNC-type
connector and the receiving end shall be implemented with a male TNC-type connector. The
transmitter and receiver shall be implemented
using female BNC and TNC type connectors respectively.
Should a case occur where, through a cabling
error or the incorrect use of in-line splices or other adapters, two transmitters or receivers are directly connected, no damage shall occur to any
transmitter, receiver, or other link component in
the system. The link shall be able to withstand

such an invalid connection without component

failure or degradation for an indefinite period of
time.
7.3.4.3 Style-2 unbalanced cable connector
The style-2 connectors for unbalanced cable
shall be industry standard 50 SMA. The electrical performance of the 50 SMA connectors
shall be compatible with IEC 169-15.
The mechanical compatibility for SMA-type connectors is defined by IEC 169-15. Primary use of
unbalanced cables are for interconnection of
cabinets.
Both ends of such a cable shall be implemented
with a male SMA-type connector. The transmitter and receiver shall be implemented using female SMA-type connectors.
Should a case occur where, through a cabling
error or the incorrect use of in-line splices or other adapters, two transmitters or receivers are directly connected, no damage shall occur to any
transmitter, receiver, or other link component in
the system. The link shall be able to withstand
such an invalid connection without component
failure or degradation for an indefinite period of
time.
7.3.4.4 Intracabinet connectors for
unbalanced cable
Connections within a cabinet do not normally require the same level of shielding as connections
external to a cabinet. For these internal connections an alternate connector may be used that
interfaces with industry standard headers with
0,64 mm (0,025 in) square posts on 2,54 mm
(0,100 in) center spacing. Due to size constraints this connector is only intended to be
used with the miniature coaxial cable.
These connectors are generally not entirely
shielded and leakage of RFI may occur. A
shielded cabinet and/or other RF leakage control techniques such as ferrite beads or lossy
tubing are recommended for compliance with
EMC standards, even with double shielded cables (refer to Annex F).
7.4
7.4.1
tics

150 balanced data links

ECL compatible driver characteris-

The output driver is assumed to have Emitter

Coupled Logic (ECL) output levels, as mea11

dpANS X3.xxx-199x
b

SHIELDED
BALANCED PAIR
ZO=150

RX
RECEIVE

TRANSMIT
NETWORK

NETWORK

Figure 31 FC-0 with 150 balanced cable link

sured at point-b. For all intercabinet links, the
output driver shall be AC-coupled to the media
through a transmission network, and have complementary outputs with outputs levels, measured at the input to the media (point-S) as listed
in tables 10 and 11, when terminated as shown
in figure 32. For all intracabinet links the driver
may be either AC- or DC-coupled to the media.
Measurements are to be made using an oscilloscope whose bandwidth including probes is at
least 1,8 times the Baud rate.
The mask of the transmitter eye diagram is given in figure 29. The transmitter output is specified in tables10 and 11.
7.4.2
tics

ECL compatible receiver characteris-

The receiver shall be AC-coupled to the media

through a receiver network located between
points-R and -c as shown in figure 31. The receive network shall terminate the link by an
equivalent impedance of 150.
An optional equalizer network, when present in
a link, shall exist as part of the cable plant. It
shall be used to correct for timing variations due
to the differences in propagation delay time beb

TRANSMIT
NETWORK

The balanced data link characteristics of maximum path penalty and input impedance of the
receiver are specified in table 10.
The mask of the receiver eye diagram is given in
figure 30. The receiver input is specified in table
12.
NOTE The receiver (at point-c) must accommodate 10% of a bit time more total jitter than that listed in table 12. This10% jitter allocation is to allow
for any external EMI induced events.

7.4.3

Balanced cable characteristics

The 150 balanced links may be interconnected using either TP or TW cable, depending on
the performance, distance, or application required for a specific link.
5

1 = Transmit +
9

+
TRANSMIT
75 1%

Figure 32 Balanced transmitter test circuit

The receiver shall operate within the BER objective (10-12) when a balanced data link is driven
by a transmitter meeting the requirements defined in tables 10, 11, and figure 29, and a signal
is delivered to the receiver meeting the eye diagram requirements in table 12 and figure 30.

S
75 1%

tween higher and lower frequency components,

as well as frequency selective attenuation loss
of the transmitted signal. An equalizer should
need no adjustment. A more detailed discussion
of the equalizer is found in Annex F.

6 = Transmit 5 = Receive +

9 = Receive Shell = Cable Shield

Figure 33 Style-1 balanced

connector pin assignments

dpANS X3.xxx-199x
Cable shield(s) shall be grounded through the
bulkhead connector shell(s) on both the transmitter and receiver ends as shown in figure 31.
7.4.4

Balanced cable connectors

7.4.4 .1 Interc abinet c onne ctors for

balanced cable
Connections between cabinets require the use
of shielded cable assemblies, terminated in polarized shielded connectors. Both the TP and
TW cable types shall be connected using either
the style-1 or style-2 balanced cable connectors.
Standard cable assemblies shall have either
style-1 connectors at both ends of the cable, or
style-2 connectors at both ends of the cable.
Cables may also be constructed with both a
style-1 and style-2 connector for use in mixed
connector installations or to adapt from one
style to the other.
The cable connector shall be the plug or male
connector while the bulkhead connector shall
be the receptacle or female connector.
7.4.4.2 Style-1 balanced cable connector
The style-1 connector for balanced cables is
the 9-pin shielded D-subminiature connector
conforming to IEC 807-3. The plug (male) half
of the connector shall be mounted on the cable.
One connector is required to connect both

transmitting and receiving shielded pairs at one

node. The connector pin assignments are
shown in figure 33. Unused pin positions within
the connector body are reserved.
The electrical conformance and mechanical
compatibility for D-subminiature type connectors is defined by IEC 807-3.
Should a case occur where, through a cabling
error or the incorrect use of in-line splices or
other adapters, two transmitters or receivers
are directly connected, no damage shall occur
to any transmitter, receiver, or other link component in the system. The link shall be able to
withstand such an invalid connection without
component failure or degradation for an indefinite period of time.
7.4.4.3 Style-2 balanced cable connector
The style-2 connector for balanced cables is dimensionally defined by figures 34 and 35. The
connector pin assignments are shown in figure
36.
Should a case occur where, through a cabling
error or the incorrect use of in-line splices or
other adapters, two transmitters or receivers
are directly connected, no damage shall occur
to any transmitter, receiver, or other link component in the system. The link shall be able to
withstand such an invalid connection without

Figure 34 Style-2 plug

dpANS X3.xxx-199x

Figure 35 Style-2 receptacle

component failure or degradation for an indefinite period of time.
7.4.4.3.1 Style-2 plug
The plug (male) half of the connector shall be
mounted on the cable. One connector is required to connect both the transmitting and the
receiving shielded pairs at one node. The style2 plug is dimensionally defined in figure 34.
7.4.4.3.2 Style-2 receptacle
The style-2 receptacle is dimensionally defined
in figure 35. This connector mates with both
transmit and receive balanced pairs. Unused pin

positions within the connector body are reserved. The connector contains eight pin locations plus an external shield. Pin locations 1, 3,
6, and 8 shall be populated in the connector
body.
7.4.4.4 Optional intercabinet connector pins
Both styles of intercabinet connectors may be
populated with additional contacts to support
additional functions. The presence of such contacts in the connector assemblies does not imply support for additional functions.
The suggested use for these additional contacts
or contact locations is listed in table 12 .

dpANS X3.xxx-199x
Table 13 Optional intercabinet contact
uses
Pin Number
Contact Name

Style 1 Style 2

Power supply,
nominal +5VDC

Module fault detect

Mechanical key

Output disable

Signal ground/+5VDC return

tions an alternate connector may be used that

interfaces with industry standard headers with
0,64 mm (0,025 in) square posts on 2,54 mm
(0,100 in) center spacing. Due to size constraints this connector may not assemble well
with all variations of balanced cable.
These connectors are generally not entirely
shielded and leakage of RFI may occur. A
shielded cabinet and/or other RF leakage control techniques such as ferrite beads or lossy
tubing are recommended for compliance with
EMC standards, even with double shielded cables (refer to Annex F).

7.4.4 .5 Intrac abinet c onne ctors for

balanced cable
Connections within a cabinet do not normally
require the same level of shielding as connections external to a cabinet. For these internal
connections an alternate connector may be
used that interfaces with industry standard
headers with 0,64 mm (0,025 in) square posts
on 2,54 mm (0,100 in) center spacing. Due to
size constraints this connector is only intended
to be used with TW cable.
These connectors are not entirely shielded and
leakage of RFI may occur. A shielded cabinet
and/or other RF leakage control techniques
such as ferrite beads or lossy tubing is recommended for compliance with EMC standards,
even with double shielded balanced cables (refer to Annex F).
7.4.4 .6 Intrac abinet c onne ctors for
balanced cable
Connections within a cabinet do not normally require the same level of shielding as connections
external to a cabinet. For these internal connec-

1 = Transmit +
1
2
3
4
5
6
7
8

3 = Transmit 6 = Receive 8 = Receive +

Shell = Cable Shield

Figure 36 Style-2 balanced connector

receptacle pin locations
15

dpANS X3.xxx-199x

Optical fibre cable plant specification

No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).

dpANS X3.xxx-199x

Electrical cable plant specification

This clause defines the link requirements for a

Fibre Channel electrical cable plant.
9.1

Unbalanced cable plant

The unbalanced cables listed in this clause are

LV (long-video) cable plant specifica-

This subclause specifies a LV-style cable plant

which is capable of communication at data
rates specified in table 15. The cable plant is
generally insensitive to data rate and therefore
any installed portions of the cable plant may be
used at any data rate.

formation identifying the specific designed operational characteristics of the cable assembly.
NOTE The Baudrate/2 equivalent frequency for
any specific data rate (referenced in tables in this
clause) is the frequency of the square wave produced when continuously transmitting a D21.5
transmission character.

9.1.1.1 LV-type
The cable shall conform to RG 6/U-type coaxial
cable specifications.
9.1.1.2 Shielding
The cable assembly shall provide a transfer impedance through the shield(s) of less than 100m/m from DC through the Baudrate/2 equivalent frequency.
9.1.2

TV (video) cable plant specification

This subclause specifies a TV-style cable plant

Table 14 LV-style cable plant

FC-0

100- 502512Unit LVLVLVLVEL-S EL-S EL-S EL-S

Subclause

7.3

dB/
0,25
conn

0,25

FC-0

Unit

7.3

Attenuation
(nom.)
at
dB/
Baudrate/2
0,148 0,105 0,074 0,052
m
equivalent
frequency
Connector
Related
Loss

Table 15 TV-style cable plant

0,25

Impedance

Impedance
Tolerance

For those cables containing embedded equalization circuits, the operation of the cable may
be both data rate and length specific. All cables
containing such circuits shall be marked with in-

Subclause

1225100- 50TVTVTVTVEL-S EL-S EL-S EL-S

7.3

Attenuation
(nom.)
at
dB/
Baudrate/2
0,176 0,124 0,088 0,062
m
equivalent
frequency
Connector
Related
Loss

dB/
0,25
conn

0,25

Impedance

Impedance
Tolerance

For those cables containing embedded equalization circuits, the operation of the cable may
be both data rate and length specific. All cables
containing such circuits shall be marked with in-

dpANS X3.xxx-199x

formation identifying the specific designed operational characteristics of the cable assembly.

m/m from DC through the Baudrate/2 equivalent frequency.

9.1.2.1 TV-type

9.1.4

The cable shall conform to RG 59/U-type coaxial cable specifications.

A specific goal of the unbalanced cable plant is

to allow interoperability with restricted lengths
of all styles of unbalanced cable. This requires
that all cables be connector compatible. Such
compatibility may be achieved with either special cables or adapters.

9.1.2.2 Shielding
The cable assembly shall provide a transfer impedance through the shield(s) of less than 100m/m from DC through the Baudrate/2 equivalent frequency.
9.1.3
tion

MI (miniature) cable plant specifica-

This subclause specifies a MI-style cable plant

which is capable of communication at data
rates specified in table 16. The cable plant is
generally insensitive to data rate and therefore
any installed portions of the cable plant may be
used at any data rate.

When unbalanced cable types are mixed, it is

the users responsibility to validate that the
lengths of cable used do not distort the signal
beyond the received signal specifications in 7.3.
At transmission rates of 531 MBaud or greater,
particular attention must be given to the transition between cable segments. No more than
four connection points should be present from
the ECL transmitter to the receiver of the data
link.
9.2

Table 16 MI-style cable plant

FC-0

100- 502512Unit MIMIMIMIEL-S EL-S EL-S EL-S

Subclause

7.3

Attenuation
(nom.)
at
dB/
Baudrate/2
m
equivalent
frequency
Connector
Related
Loss

0,62

dB/
0,25
conn

7.3

0,46

0,25

7.3

0,31

0,25

7.3

0,21

0,25

Impedance

Impedance
Tolerance

9.1.3.1 MI-type
The cable shall conform to RG 179B/U type coaxial cable specifications.
9.1.3.2 Shielding
The cable assembly shall provide a transfer impedance through the shield(s) of less than 100-

Unbalanced cable interoperability

Balanced cable plant

The balanced cables listed in this clause are

not the only such cables that may be used to
create such links. Usage of other cables are
permitted to meet specific cost, performance, or
other implementation specific criteria.
When using such cables it is the implementers
responsibility to insure that all impedance, attenuation (loss), jitter, skew, balance, and
shielding are within the operating limits of the
link type and data rate being implemented.
9.2.1 TP (shielded twisted pair) cable plant
specification
This subclause specifies a TP-style cable plant
which is capable of communication at data
rates specified in table 17.
Because of the differential skew requirement, it
is expected to be difficult to obtain cable of this
type meeting all requirements of 100-TP-EL-S
and 50-TP-EL-S. This cable may be used for
distances shorter than the maximum length,
providing that the differential skew at the end of
the cable does not exceed the specified limit.
9.2.1.1 TP-type
The cable shall conform to IEC 1156-1. One cable contains two individually shielded twisted

dpANS X3.xxx-199x
Table 18 TW-style cable plant

Table 17 TP-style cable plant

1225100- 50TPTPTPUnit TPEL-S EL-S EL-S EL-S

FC-0

7.4
XRE
F

Subclause

7.4
XRE
F

Attenuation
(nom.)
at
dB/
Baudrate/2e
0,310 0,220 0,155 0,110
m
quivalent
frequency
Connector
Related
Loss

dB/
0,25
conn

0,25

Impedance

150

Impedance
Tolerance

Differential
Skew

175

350

700

1400

pairs. Of these two pairs, one is used as the

transmitting medium, with the other used as the
receiving medium.
The shielded twisted pair cable, when used in
full duplex links, shall be wired in a crossover
fashion as shown in figure 37, with each pair
being attached to the transmit contacts at one
end of the cable and the receive contacts at the
other end.
9.2.1.2 Shielding
The cable assembly shall provide a transfer impedance through the shield(s) of less than 100m/m from DC through the bit-rate fundamental frequency.
9.2.2

TW cable plant specification

This subclause specifies a TW-style cable plant

which is capable of communication at data
rates specified in table 18.
T+
TR+
RShield

FC-0

Unit

Subclause
Attenuation
(nom.)
at
Baudrate/2e
quivalent
frequency
Connector
Related
Loss

100- 502512TW- TW- TW- TWEL-S EL-S EL-S EL-S

7.4

dB/
m

7.4

0,266 0,189 0,133 0,094

dB/
0,25
conn

0,25

Impedance

150

Impedance
Tolerance

Differential
Skew

175

350

700

1400

For those cables containing embedded equalization circuits, the operation of the cable may
be both data rate and length specific. All cables
containing such circuits shall be marked with information identifying the specific designed operational characteristics of the cable assembly.
9.2.2.1 TW-type
The cable shall have a nominal differential impedance of 150. It shall consist of two parallel
conductors, separated by a dielectric spacer,
with an overall shield
TW-style cable may be used in either full duplex
or simplex links. When configured in a full duplex link, the cable shall consist of two individually shielded balanced pairs in a common or
joined outer insulating jacket, or two orthogonal
balanced pairs with common shields and an
overall insulating jacket. These two pairs shall
be wired in a crossover fashion as shown in figure 37, with each pair being attached to the
transmit contacts at one end of the cable and
the receive contacts at the other end.

T+
T-

9.2.2.2 Shielding

R+
RShield

The cable assembly shall provide a transfer impedance through the shield(s) of less than 100m/m from DC through the bit-rate fundamental frequency.

Figure 37 Balanced cable wiring

dpANS X3.xxx-199x
9.2.3

Balanced cable interoperability

A specific goal of the balanced cable plant is to

allow interoperability with restricted lengths of
all styles of balanced cable. This requires that
all cables be connector compatible. Such compatibility may be achieved with either special
cables or adapters.
When balanced cable types are mixed, it is the
users responsibility to validate that the lengths
of cable used do not distort the signal beyond
the received signal specifications in 7.4

dpANS X3.xxx-199x

Optical interface connector specification

No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).

FC-1 8B/10B Transmission Code

No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).

FC-1 receiver and transmitter description

No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).

Loopback mode

No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).

Diagnostic mode

No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).

Transmitter safety

No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).

Ordered sets

No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).

Frame formats

No enhancements from X3.230-1994 (FC-PH) or x3.xxx-1995 (FC-PH-2).

dpANS X3.xxx-199x

Frame_Header

Enhancements to FC-PH and FC-PH-2 are

specified.
18.3

Address identifiers

Additional values specified in FC-PH-3 are

shown in table 33.

Table 33 Well-known Address identifiers

Table 36 Type codes - FC-4 (Device_Data

and Link_Data)
Encoded Value
Wd 2, bits 31-24

Description

0000 0000 to
0010 1111

Specified in FC-PH
Table 36
Specified in FC-PH-2
Table 36

Hex value

Description

0011 0000 to
0011 0011

FFFFF0 to
FFFFF4

Reserved

0011 0100 to
0011 1111

Reserved

Multicast Server

0100 0000 to
0100 0111

Specified in FC-PH
Table 36

0100 1000 to
0100 1111

Reserved for FC-AE

0101 0000 to
0101 1111

Reserved

0110 0000 to
1111 1111

Specified in FC-PH
Table 36

FFFFF5

( see 31.2.3)

FFFFF6

Clock Synchronization Server

(see FC-PH-3)

FFFFF7

Security Key Distribution Server

(see FC-GS-2)

FFFFF8 to
FFFFFF

Specified in FC-PH-2 Table 33

18.4

Data Structure (TYPE)

Additional values specified in FC-PH-3 are

shown in table 36.

18.5

Frame Control (F_CTL)

The Frame Control (F_CTL) field (Word 2, Bits

23-0) is a three byte field that contains control
information relating to the frame content. The
following subclause describes the valid uses of
F_CTL bits. If an error in bit usage is detected,
a reject frame (P_RJT) shall be transmitted in
response with an appropriate reason code (see
20.3.3.3) for Class 1 and 2. The format of the
F_CTL field is defined in table 37.

dpANS X3.xxx-199x
Table 37 (Page 1 of 2) - F_CTL field
Control Field

Word 2,
Bits

Description

Ref.

Exchange/Sequence Control
Exchange Context

0 = Originator of Exchange
1 = Responder of Exchange

FC-PH

Sequence Context

0 = Originator of Sequence
1 = Responder of Sequence

FC-PH

First_Sequence

0 = Sequence other than first of Exchange

1 = First Sequence of Exchange

FC-PH

Last_Sequence

0 = Sequence other than last of Exchange

1 = Last Sequence of Exchange

FC-PH

End_Sequence

0 = Data frame other than last of Sequence

1 = Last Data frame of Sequence

FC-PH

End_Connection (Class 1) or
Deactivate Class 4 circuit

0 = Originator of Exchange
1 = Responder of Exchange

Reserved

Sequence Initiative

0 = hold Sequence Initiative

1 = Transfer Sequence Initiative

FC-PH

X_ID reassigned

0 = X_ID assignment retained

1 = X_ID reassigned

FC-PH

Invalidate X_ID

0 = X_ID assignment retained

1 = Invalidate X_ID

FC-PH

ACK_Form

13-12

00 = No Assistance provided
01 = ACK_1 required
10 = ACK_N required
11 = ACK_0 required

FC-PH-2

Data Compression

0 = Uncompressed frame payload

1 = Compressed frame payload

FC-PH-2

Data Encryption

0 = Unencrypted frame payload

1 = Encrypted frame payload

FC-PH-3

Retransmitted Sequence

Unidirectional Transmit (Class 1)

or
Remove Class 4 circuit (Class 4)

FC-PH-2
FC-PH-3

0 = Original Sequence transmission

1 = Sequence retransmission

FC-PH

0 = Bidirectional transmission (Class 1)

1 =Unidirectional transmission (Class 1)
8

FC-PH-2
0 = Retain or deactivate circuit (Class 4)
1 = Remove circuit (Class 4)

dpANS X3.xxx-199x
Table 37 (Page 2 of 2) - F_CTL field
Control Field

Description

Ref.

7-6

Last Data Frame - Sequence Initiator

00 = No information
01 = Sequence to follow - immediately
01 = Sequence to follow - soon
01 = Sequence to follow - delayed

Abort Sequence Condition

5-4

ACK Frame - Sequence Recipient:

00 = Continue Sequence
01 = Abort Sequence, perform ABTS
10 = Stop Sequence
11 = Immediate Sequence retransmission
requested
FC-PH and
Data frame (1st of Exchange) - Sequence
FC-PH-3
Initiator:
00 = Abort, Discard multiple Sequences
01 = Abort, Discard a single Sequence
10 = Process policy with infinite buffers
11 = Discard multiple Sequences with
immediaet retransmission

Relative Offset present

0 = Parameter field not meaningful

1 = Parameter field - Relative Offset

FC-PH

Exchange reassembly

Reserved for Exchange reassembly

FC-PH

End of Data field - bytes of fill

00 = 0 bytes of fill
01 = 1 byte of fill (last byte of Data fieldl
10 = 2 bytes of fill (last 2 bytes of Data field)
11 = 3 bytes of fill (last 3 bytes of Data field)

FC-PH

Continue Sequence Condition

Fill Data Bytes

Word
2, Bits

1-0

FC-PH

dpANS X3.xxx-199x
Bit 10 - Data Encryption Status
Data encryption status bit (F_CTL bit 10) is
used by the Sequence Initiator to indicate to the
Sequence Recipient that the Information Category to which the payload in the frame belongs
is encrypted. The bit is meaningful in all Data
frames of the Information Category to which the
Data frames belong. The bit is not meaningful
on ACK, BSY, or RJT frames.
By resetting Data encryption status bit =
0, the Sequence Initiator is indicating that the
payload in the frame belonging to the Information Category is not encrypted.
By setting Data encrypted status bit = 1,
the Sequence Initiator is indicating that the
payload in the frame belonging to the Information Category is encrypted.
Table 36C Data encryption status
Word 2, F_CTL Bit 10
Encode

Meaning

Unencrypted frame
Payload

Encrypted frame
Payload

Bits 5-4 - Abort Sequence Condition

The following details changes to Process Policy
with Infinite Buffers.

The Abort Sequence Condition bits shall

be set to a value by the Sequence Initiator on the first Data frame of an Exchange
to indicate that the Originator is requiring
a specific error policy for this Exch an ge . Fo r C lasse s 1, 2 , a nd 4 , the
Abort Sequence Condition bits shall not
be meaningful on other Data frames within an Exchange. For Class 3 process policy support, the Abort Sequence
Condition bits shall be set to 1 0 on each
data frame with the sequence to indicate
tha t th e origina to r is re qu iring pr oce ss
policy to be used for the sequence. The
error policy passed in the first frame of
the sequence of the first Sequence of an
Exchange shall be the error policy supported by b oth N_Ports participa ting in
the Exchange. Add itio nally, for Class 3
operation the error policy passed in the

first received frame of the sequence shall

be the error policy supported by both N_
Ports participating in the Exchange (see
29.6.1.1)
0 0 = Abort, Discard multiple Sequences
0 1 = Abort, Discard a single Sequence
1 0 = Process policy with infinite buffers
1 1 = Discard multiple Sequences with
immediate retransmission
In the Abort, Discard multiple Sequences
E r r o r P o lic y , t h e S e q u e n c e R e c i p ie n t
shall de live r Se que nces to the FC-4 o r
upper level in the order transmitted under
the condition that the previous Sequence,
if any, was also deliverable. I f a S equence is determined to be non-deliverable, all subsequent Sequences shall be
d is ca rd e d u ntil the ABTS p ro to co l h a s
been completed. The Abort, Discard multiple Sequences Error Policy shall be supported in Class 1, 2, 3, or 4.
In the Abort, Discard a single Sequence
Error Policy, the Sequence Recipient may
deliver Sequences to the FC-4 or upper
level in the order that received Sequences are completed by the Sequence Recipient without regard to the deliverability of
any previous Sequences. The Abort, Discard a single Sequence Error Policy shall
be supported in Class 1, 2, 3, or 4.
In the Process policy with infinite buffers,
frames shall be delivered to the FC-4 or
upper level in the order transmitted. Process policy with infinite buffers shall only
b e a llo w e d in C la s s 1 a n d C la ss 3 . In
Class 1, Process policy with infinite buffers shall use ACK_0 (see 20.3.2.2).
Bit 3- Relative Offset present
When bit 3 is set to zero on a Data frame,
the Para mete r Fie ld is not me an in gful.
Th at is, it may be set by th e Se quence
Initiator, but it shall be ignored by the Sequ en ce Re cip ie nt. W h en bit 3 is set to
one in a Data frame, the Parameter Field
contains the Realtive Offset for the Payload of the frame. Bit 3 is only meanigful
on Data frames of a Sequence and shall
be ignored on ACK and Link_Response

dpANS X3.xxx-199x
frames. Bit 3 is not meaningful on Basic
Link_Data frames.
NOTE When bit 3 is set to 0 on a Data frame, although the Sequence Recipient ignores the value
in the Parameter Field, it may pass it to an upper
level.

18.6

Sequence_ID (SEQ_ID)

18.7

DF_CTL

Data_Field Control (DF_CTL) is a one byte field

(Word 3, bits 23-16) that specifies the presence
of optional headers at the beginning of the
Data_Field for Device_Data or Video_Data
frames. DF_CTL bits are not meaningful on
Link_Control or Basic Link Service frames.
Control bit usage is shown in table 40.
Table 40 DF_CTL bit definition
Word 3,
Bits(s)

Optional header

Reserved for Extended Frame_

Header

Reclaimed
from
Expiration_
Security_Header and Reserved

0 = No Network_Header
1 = Network_Header

0 = No Association_Header
1 = Association_Header

19-18

Reserved

17-16

0
0
1
1

0 = No Device_Header
1 = 16 byte Device_Header
0 = 32 byte Device_Header
1 = 64 byte Device_Header

The Optional Headers shall be positioned in the

Data Field in the order specified with the bit 23
header as the first header in the Data Field, the
bit 22 header as the second header in the Data
Field, and so forth, in a left to right manner corresponding to bits 23, 22, 21, and so forth as
shown in figure 47.
If either bit 17 or 16 is set to one, then a Device
Header is present. The size of the Device
Header is specified by the encoded value of bits
17 and 16 as shown.
If an Optional Header is not present as indicated by the appropriate bit in DF_CTL, no space
shall be allocated for the Header in the Data

Field of the frame. Therefore, for example, if

bits 23 and 22 are zero and bit 21 is one, the
first data byte of the Data Field contains the first
byte of the Network_Header.
See clause 19 for a discussion on Optional
Headers.
18.9

Word 4, Bits 31-16

Word 4, Bits 31-16 shall identify the Exchange_

ID assigned by the Originator of the Exchange
and, if enabled, the Priority that may be used by
the Fabric to establish connections for all classes of service.
When Priority is enabled, Word 4, Bits 31-24
shall specify the Priority and Word 4, Bits 23-16
shall specify the Originator Exchange_ID (OX_
ID). When Priority is not enabled, Word 4, Bits
31-16 shall specify the Originator Exchange_ID
(OX_ID). Priority is valid for all Classes of service except Class 3 and is enabled via Login
(see 23.6.7.2). See table 160 and table 161 for
illustrations of this field.
NOTE When priority is enabled, the number of
available Exchanges is reduced to 254.

Table 160 Priority/Preemption enabled

Bit(s)
31

Field
0 = No Preemption
1 = Preemption

30-24

Priority

23-16

OX_ID

Table 161 Priority/Preemption not

enabled
Bit(s)
31-16
18.9.1

Field
OX_ID

Originator Exchange_ID (OX_ID)

The Originator Exchange_ID is a two byte field

(Word 4, Bits 31-16) that shall identify the
Exchange_ID assigned by the Originator of the
Exchange and if enabled, the priority that may
be used by the Fabric to establish connections
for all classes of service and a preemption flag

dpANS X3.xxx-199x
to indicate that an SOFc1 is a preemption request. If priority is enabled the priority shall be
7 bits (Word 4, Bits 30-24), the preemption request flag shall be 1 bit (Word 4, Bit 31), and
the Exchange_ID shall be one byte (Word 4,
Bits 2 3-16). If priority is not en abled the
Exchange_ID shall be two bytes (Word 4, Bits
31-16).
Each Exchange shall be assigned an identifier
unique to the Originator or Originator-Responder pair. If the Originator is enforcing uniqueness via the OX_ID mechanism, it shall assign
a unique value for OX_ID other than hex 'FFFF
('FF' if priority enabled) in the first Data frame
of the first Sequence of an Exchange. An OX_
ID of hex 'FFFF' ('FF') indicates that the OX_
ID is unassigned and that the Originator is
not enforcing uniqueness via the OX_ID mechanism. If an Originator uses the unassigned
value of hex 'FFFF' ('FF') to identify the Exchange, it shall have only one Exchange (OX_
ID= hex 'FFFF' ('FF')) with a given Responder.
An Originator Exchange Status Block associated with the OX_ID is used to track the progress
of a series of Sequences which comprises an
Exchange. See clause 24 for a discussion of
Sequences and Exchanges. See 24.8.1 for a
description of the Exchange Status Block.
NOTE If hex 'FFFF' ('FF' if priority enabled) is
used as the OX_ID throughout the Exchange,
then the Originator uses an alternate Sequence
tracking mechanism. If the OX_ID is unique, it
may be used as an index into a control block
structure which may be used in conjunction with
other constructs to track frames.

18.9.2

Priority

b) In Class 1, Priority is meaningful for a

dedicated connection. The Priority for a dedicated connection shall be established by the
priority value provided by the SOFc1 frame.
NOTE Changing Priority in a subsequent
frame of a Dedicated Connection will not affect
the Fabric. However, if the Responder N_Port
does not support Priority and is using an RX_ID
of hex FFFF, its ability to track the Exchange
will be destroyed. This is because it is using the
OX_ID to track the Exchange and it will consider
all of Word 4, bits 31-16 to be the OX_ID.

c) In Class 2, Priority is meaningful for an

Exchange. Priority shall be set by the Exchange Originator on the first frame of the
Exchange. Priority shall be modified by the
Exchange Originator only on an SOFi2 frame
and under the following conditions:
1) The Responder has indicated during
Login that it supports Priority, or the Responder has returned an RX_ID not equal
to hex FFFF, or
2) The Responder has indicated during
Login that it does not support Priority, the
Responder has returned an RX_ID of hex
FFFF, and the OX_ID has previously
been invalidated.
NOTE If the Responder is using an RX_ID not
equal to hex FFFF, it is tracking the Exchange
via the RX_ID and not the OX_ID. Therefore,
modification of Word 1, Bits 31-16 will not affect
it. Also, if the Responder supports Priority, it recognizes that the OX_ID is only Word 4, bits 2316.

Priority shall only be modified by the Exchange Responder on an SOFi2 frame.

If the Originator N_Port indicated during Login

that Priority is supported, the following rules
shall apply to the use of the Priority field:

d) In Class 3, Priority shall not be used.

That is, all of Word 4, bits 31-16 shall be considered the OX_ID.

NOTE If the Originator N_Port indicated during

Login that Priority is not supported, it cannot be
used because the Priority field does not exist (it
becomes an extension of the OX_ID field).

e) In Class 4, Priority is meaningful for a virtual circuit. Priority shall be established by

the priority value provided by the Quality of
Service Request frame.

a) A value of hex 00 shall indicate that no

Priority has been assigned to the frame. The
remaining values shall indicate, in ascending
order, the relative priority of the frame. That
is, a Priority of hex 23 shall be considered to
have a lower priority than a Priority of hex
57. The Fabric may use the Priority to resolve resource contention or to determine the
order in which to deliver frames.

NOTE Once a Virtual Circuit has been set up,

Priority is meaningless.

dpANS X3.xxx-199x

This clause describes the changes that are made

in FC-PH-3 to the FC-PH Optional headers.

the Data Field. If present, a Device_Header shall

be the next 16 bytes of the Data Field. If none of
the optional headers is present, no space in the
Data Field shall be reserved.

19.1

19.2

Optional headers

Introduction

Optional headers are defined within the Data

Field of a frame are:

Expiration_Security_Header

The Expiration_Security_Header defined in FCPH is reclaimed and its space is reserved for future use.

a) Reserved (reclaimed from Expiration_

Security_Header)

19.3

Network_Header

This clause details the changes due to the reclamation of the CCITT NAA identifier.

Association_Header

Device_Header

NOTE The CCITT NAAs are reclaimed due to the

non-existence of a registration authority for these addresses.

The presence of optional headers is defined by

control bits in the DF_CTL field of the Frame_
Header. The sequential order of the optional
headers, Payload, and their sizes are indicated
in figure 47.

Start_of_Frame
Frame_Header
Reserved
Data
Field
(0 to
2112)

Network_Header
(optional)
Association_Header
(optional)
Device_Header
(optional)

Network_Header

4 bytes
24 bytes
16 bytes
16 bytes
32 bytes

NOTE Although this clause is referenced by 23.6.4

and 23.6.5, it is important to note that the usage of the
Network Header for network routing is very different
than the use of the same format to define N_Port and
node identification during Login. For example, the
Network Header may change as other NAA types are
defined, but this does not imply that these are valid for
use as identifiers during Login. Furthermore, one format or even value may be used in the Network Header for routing and a different format or value may be
used in the Login payload for identification.

19.3.1

D_NAA or S_NAA

Destination Network_Address_Authority (D_NAA)

or Source Network_Address_Authority (S_NAA)
field indicates the authority responsible for the administration of the network address (destination or
source) used. The Network_Address_Authority indicators are shown in table 45.

16 bytes
Table 41 NAA identifiers

Payload

Bits
4 bytes

CRC
EOF

4 bytes

Figure 47 Optional headers order

The first 16 bytes of the Data Field after the
Frame_Header have been reclaimed from the
Expiration_SecurityHeader and are reserved for
future use. If present, a Network_Header shall be
the next 16 bytes of the Data Field. If present, a
Association_Header shall be the next 16 bytes of
28

NAA

63 62 61 60
0000

ignored

0001

IEEE

0010

IEEE extended

0011

locally assigned

0100

0101

Reserved

....

dpANS X3.xxx-199x
1011

Reserved

1100

Reclaimed from CCITT

1101

Reserved

1110

Reclaimed from CCITT

1111

Reserved

Table 45 Association_Header Validity

bits (Bits 63-56)
Bit

Description

Originator P_AS
0 = not meaningful
1 = meaningful

FC-PH

Responder P_AS
0 = not meaningful
1 = meaningful

FC-PH

Originator O_AS
0 = not meaningful
1 = meaningful

FC-PH

28
0

Responder O_AS
0 = not meaningful
1 = meaningful

FC-PH

27
to
25

Reserved

FC-PH-3

Multicast P_AS
0 = Unicast
1 = Mulitcast

FC-PH-3

19.3.2.5 CCITT 60-bit address

This FC-PH clause is deleted.
19.4

Association Header

The following changes to the Association Header are indicated in figure 52 and table 45.

bits
word

Ref

31-24

Validity

2316

15-8

7-0

Originator P_AS
(most significant 3 bytes)

Originator P_AS
(least significant 4 bytes)
Reserved

Responder P_AS
(most significant 3 bytes)

Responder P_AS
(least significant 4 bytes)

Originator O_AS
(most significant 4 bytes)

Originator O_AS
(least significant 4 bytes)

Responder O_AS
(most significant 4 bytes)

Responder O_AS
(least significant 4 bytes)
Figure 52 Association_Header

Bit 56 - Multicast Process_Associator

This bit set to one shall indicate that the
passed Process_Associator shall be processed as a multicast Process_Associator by the recipient N_Port. That is, the
N_ Port s hall pe rform an in tern al multica st ing of th e p a ylo a d o f th e re c eiv ed
frame to all images within the Multicast
Group specified by the Process_Associator. This bit set to zero shall indicate that
the passed Process_Associator shall be
processed as a unicast Process_Associator by the Recipient N_Port. That is, the
N_Port shall pass the payload of the received frame to the image specified b y
t h e P r o c e s s _ As s o c ia to r . S e e X3 . x x x 1995 (FC-PH-2), clause 31 for a description of Multicast support.

dpANS X3.xxx-199x

Data frames and responses

FC-PH-3 enhancements to Data frames and responses defined in FC-PH and FC-PH-2 are
specified.
20.3

Link_Control

A Link_Response frame (F_RJT) shall be sent

by the Fabric in reply to a Class 1 preemption
request frame if the fabric rejects the request,
or preemption is not enabled. To reject the preemption request the fabric shall send an F_RJT
link response frame with a Preemption Request Rejected or Preemption Not Enabled
reason code.
20.3.3.2 N_Port Busy (P_BSY)
Table 53 provides the enhanced Busy reason
codes based on FC-PH and FC-PH-2 table 53.

Table 53 P_BSY Reason Codes

Word 0, bits
27-24

Description

0000 0001
to
0001 0100

Specified in FC-PH
table 55

0001 0101

Specified in FC-PH-2
table 55

0001 0110
to
0001 1010

Specified in FC-PH
table 55

0001 1011
to
0001 1111

Specified in FC-PH-2
table 55

0010 0000

Preemption Request
Rejected
(see clause 28.9)

0010 0001

Premption Not
Enabled
(see clause 23)

Word 5, bits
23-16

Description
0010 0010

Multicast Error
(see clause 31)

0000 0001

Specified in FC-PH
table 53

0000 0011

Specified in FC-PH
table 53

0010 0011

Multicast Error
terminate
(see clause 31)

0000 0111

Partial Multicast Busy

(see Clause 31)

Others

Reserved

1111 1111

Specified in FC-PH
table 53

Others

Reserved

20.3.3.3 Reject (P_RJT, F_RJT)

Table 55 provides the enhanced Reject reason
codes based on FC-PH and FC-PH-2 table 55.

Table 55 P_RJT or F_RJT Reason Codes

NOTE The By column indicates that this Reason Code is set by the fabric (F) , N_Port (N), or
both (B).

dpANS X3.xxx-199x

Link Services

This clause describes the changes that are made in

FC-PH-3 for:

Receive_Data_Field Size = 128,

X_ID interlock required,

no X_ID reassignment,

E_D_TOV timer resolution enhancement.

ACK_1,

Default login values.

Discard multiple Sequences Error Policy,

Basic link service commands

Relative Offset not used,

Extended link services.

E_D_TOV Resolution = 0,

Report Node Capabilities information.

Other optionally supported features shall not

be used or required.

21.1.1

Default Login values

Prior to Login or following Logout, a default set of

Service Parameters apply:

Concurrent Sequences = 1,

Total Concurrent Sequences = 1,

End-to-end Credit = 1,

Buffer-to-buffer Credit = 1,

Following Login with the destination, an N_Port

sh all use th e Ser vic e P ar ame ter s o bta in e d
through Login.
21.2

Basic Link Service commands

Enhancements to FC-PH and FC-PH-2 is specified in table 57.

Table 57 Basic Link Service Commands

Word 0

Word 1

Routing
Category
Type
(bits 31-28) (bits 27-24) (bits 31-24)

Word 5
Description

Abbr.

Ref.

Parameter

Basic Link Service

1000

0000

No Operation

NOP

0001

Abort Sequence

ABTS

0010

Remove Connection

RMC

0011

Reserved
Basic Accept

BA_
ACC

0101

Basic Reject

BA_RJT

0110

Preempted

PRMT

0100

Others

0000 0000

N/A

Reserved

Specified
in FC-PH
table 57

Specified
in FC-PH-3
Specified
in FC-PH
table 57

dpANS X3.xxx-199x
21.2.7 Dedicated Connection Preempted
(PRMT)
The PRMT basic link service command shall indicate that the connection for which this N_Port
is participating has been preempted and no
longer exists. All sequences associated with
this connection have ended abnormally.
Protocol:

OX_ID: If priority is enabled (see clause 18 and

23) the upper byte of the OX_ID field shall be
equal to the upper byte of the OX_ID field in the
SOFc1 preemption request frame which triggered this preemption notification.
Payload: None
Reply Sequence: None
21.3

Connection Preempted Notification

No Reply frame

Extended Link Services

Table 61 summarizes FC-PH,FC-PH-2, and

FC-PH-3 Extended Link Service Requests and
Replies.

Format: FT_1
Addressing: The D_ID field shall designate the
N_Port to which this basic link service command is directed by the Fabric. The S_ID field
shall be equal to the S_ID field in the SOFc1
preemption request frame which triggered this
preemption notification.
Table 61 Extended Link Service Commands
Word 0
Routing
(bits 31-28)

Payload

Category
(bits 27-24)

Type

Description

Word 0
(bits 31-24)

Abbr.

Ref.

Extended Link Service Request

0010

0000
0001

hex 03

N_Port Login

PLOGI

hex 04

F_Port Login

FLOGI

hex 05

Logout

LOGO

hex 06

Abort Exchange

ABTX

hex 07

Read Connection Status

RSC

hex 08

Read Exchange Status Block

RES

hex 09

Read Sequence Status Block

RSS

hex 0A

Request Sequence Initiative

RSI

hex 0B

Establish Streaming

ESTS

hex 0C

Estimate Credit

ESTC

hex 0D

Advise Credit

hex 0E

Read Time-out Value

RTV

hex 0F

Read Link Status

RLS

hex 10

Echo

ECHO

hex 11

Test

TEST

hex 12

Reinstate Recovery Qualifier

RRQ

Specified
in FC-PH
21.4 and
table 61

ADVC
Specified
in FC-PH-3
Specified
in FC-PH
21.4 and
table 61

dpANS X3.xxx-199x
Table 61 Extended Link Service Commands
Word 0

Payload
Type

Routing
Category
(bits 31-28) (bits 27-24)

Description

Word 0
(bits 31-24)

Abbr.

Ref.

Extended Link Service Request

0010

0000 0001

hex 20

Process Login

PRLI

hex 21

Process Logout

PRLO

hex 22

State Change Notification

SCN

hex 23

Test Process Login State

TPLS

hex 24

Third Party Process Logout

TPRLO

hex 30

Get Alias_ID

GAID

hex 31

Fabric Activate Alias_ID

FACT

hex 32

Fabric Deactivate Alias_ID

FDACT

hex 33

N_Port Activate Alias_ID

NACT

hex 34

N_Port Deactivate Alias_ID

NDACT

hex 40

Quality of Service Request

QoSR

hex 41

Read Virtual Circuit Status

RVCS

hex 50

Discover N_Port Service Parm

PDISC

hex 51

Discover F_Port Service Parm

FDISC

hex 52

Discover Address

ADISC

hex 53

Report Node Capability

RNC

Others

Reserved

hex 01

Link Service Reject

hex 02

Others

Reserved

Specified
in FC-PH-2
table 61

FC-PH-3

Extended Link Service Reply

0010

0011

0000 0001

LS_RJT Specified
in FC-PH
ACC
21.4 and
table 61

dpANS X3.xxx-199x
21.4

Extended Link Service requests

This section contains modifications to Extended

Link Service requests defined in X3.230-1994
(FC-PH) and X3.297-1996 (FC-PH-2), along
with the definition of additional Extended Link
Services.
21.4.13

Accept Payload:
The format of the Accept Payload is
shown in table 162. Timeout values are
specified as a count of either 1 ms or 1
ns increments, depending on the setting
of Bit 26 in the Timeout Qualifier.

Read Timeout Value (RTV)

The RTV Link Service request Sequence requests an N_Port or F_Port (hex FFFFFE) to
return the Resource_Allocation_Timeout Value
(R_A_TOV) and the Error_Detect_Timeout Value (E_D_TOV) in the Accept reply Sequence.
This provides the N_Port transmitting the request with the information regarding these values from another N_Port or from the F_Port.
Usage of E_D_TOV and R_A_TOV is discussed in X3.230-1994 (FC-PH) 29.2.1.
Protocol:
Read Timeout Value (RTV) request Sequence
Accept (ACC) reply Sequence
Format: FT_1
Addressing: The S_ID field designates the
source N_Port requesting the timeout interval
values. The D_ID field designates the destination N_Port or F_Port to which the request is
being made.
Payload: The format of the Payload is shown in
table 162.

Table 162 RTV Payload

Item
hex 0E000000

Size Bytes
4

Reply Link Service Sequence:

Table 163 RTV Accept Payload

Item
hex 02000000

Resource_Allocation_Timeout Value
(R_A_TOV) (see 29.2.1)

Error_Detect_Timeout Value
(E_D_TOV) (see 29.2.1)

Timeout Qualifier
(see 23.6.3.7)

R_A_TOV: In a point-to-point topology, this value shall have the same resolution as E_D_
TOV, as indicated by the Timeout Qualifier.
NOTE In a point-to-point topology, R_A_TOV
must be twice E_D_TOV, which means it must
have the same resolution. In other topologies, R_
A_TOV will always be in 1 ms increments.

Timeout Qualifier:
Bits 31-27: Reserved
Bit 26: E_D_TOV Resolution
If Bit 26 is zero, the value specified in the E_D_
TOV field shall indicate a count of 1 ms increments. If Bit 26 is one, the value specified in the
E_D_TOV field shall indicate a count of 1 ns increments.
Bits 25-0: Reserved
21.5 Ex tende d Link Se rv ic e r eply
Sequences
21.5.2

Service Reject (LS_RJT)

signifies rejection of the RTV command
(see X3.230-1994 (FC-PH) 21.5.2)
Accept
signifies that the N_Port or F_Port has
transmitted the requested data.

Size Bytes

Link Service Reject (LS_RJT)

Table 91 summarizes FC-PH,FC-PH-2, and

FC-PH-3 LS_RJT reason codes.

dpANS X3.xxx-199x
Table 91 LS_RJT reason code explanation
Encoded Value
(Bits 15-8)

Description

Applicable Commands

hex 00

No additional explanation

ABTX, ADVC, ESTS, FLOGI, PLOGI,

LOGO, RCS, RES, RLS, RSS, RTV,
RSI, PRLI, PRLO, TPLS, TPRLO,
GAID, FACT, FDACT, NACT,
NDACT, QoSR, RVCS, PDISC,
FDISC, ADISC, RNC

hex 01
to
hex 2B

See FC-PH Table 91

hex 2C

Request not supported

ADVC, ESTS, ESTC, PRLI, PRLO,

TPLS, TPRLO, GAID, FACT, FDACT,
NACT, NDACT, QoSR, RVCS,
PDISC, FDISC, ADISC, RNC

hex 2D

Invalid Payload Length

FLOGI, PLOGI

hex 30
to
hex 38x

See FC-PH-2 Table 91

hex 40
to
hex 42x

See FC-PH-2 Table 91

21.20 Report Node Capabilities Information

(RNC)
The RNC Link Service request Sequence provides
for the exchange of vendor identification, node capabilities, and other vendor unique information. This
link service may be used to query an N_Port to discover what document identifiers (and the associated
FC-4 protocols and profiles) it supports. Optionally
RNC may be used between two N_Ports to specify
which specific document(s) should be used to set operating parameters for these two N_Ports. RNC may
also be used to specify options or additional parameters specified by the referenced documents which
are not specified during N_Port Login.

Format: FT_1
Addressing: The S_ID field designates the
source N_Port requesting the capabilities information. The D_ID field designates the destination N_Port to which the request is being made.
Payload: The format of the Payload is shown in
table 164.

The RNC Link Service may be used anytime after N_

Port Login.
Protocol:
Report Node Capabilities Information (RNC) request Sequence
Accept (ACC) reply Sequence

dpANS X3.xxx-199x
Table 164 RNC/ACC Payload
Item

Size Bytes

hex 53 for RNC

hex 02 for ACC

Reserved

Payload Length

RNC Flags

Reserved

VU Information Length (VU_Len)

Vendor Identifier

Capability Entry(s)

Vendor Unique Information

0-128

Payload Length: Bytes 2-3 of Word 0 contain a

16-bit unsigned binary integer that specifies the
length of the RNC payload.
The minimum length of an RNC or RNC Accept
payload is 16 bytes. The maximum length shall
be limited to 256 bytes. The requesting N_Port
shall be responsible for ensuring payload length
does not exceed this limit. The maximum length
of the RNC Accept payload is not specified.
RNC Flags: Byte 0 of Word 1 contains an 8-bit
flag field which defines options applicable to all
Capability Entries in the RNC payload.
Bit 7: Select (S)
0 = Report all capabilities
1 = Select option requested
If the Select bit is zero, the RNC Accept
pa yloa d shall contain all Capability Entries the responding N_Port wishes to report.
If the Select bit is set to 1, the requesting
N_Port is specifying that the RNC Accept
payload contain only one Capability Entry. The Capability Entry specified in the
Accept payload shall be selected from the
list of capabilities given in the RNC payload. The Select bit also specifies that the
Low Revision and High Revision fields in
the RNC Accept payload shall be equal
for the capability being selected. If the responding node does not support any o f
36

th e c ap ab ilitie s liste d , it s ha ll re tu rn n
RNC Accept without any Capability Entries.
The act of selecting a specific capability
entry allows two nodes to agree upon a
set of specific operating parameters. The
selection may set or imply certain operating modes or parameters for a particular
p roto col, FC-4 , or o the r Fib re C ha nne l
characteristic as defined by the document
referenced in the capability entry. For example, if the capability entry refers to a
profile for a specific FCP implementation,
then selecting that capability entry may
specify class, process login parameters,
allowable SCSI commands, etc.
The RNC link service sh all no t re place
the normal parameter exchange (such as
process login). It does, however, provide
a mechanism for both nodes to anticipate
t h e p r e f e rr e d p a ra me t e r s o f th e o th e r
node.
If tw o N _Por ts sup po rt multip le FC -4s ,
p ro tocols, or for so me o ther reason re quire a selection of more than one capability entry, the RNC link service may be
used multiple times. (See Invalidate Previous bit below).
Bits 6-0: Reserved (r)
VU Information Length (VU_Len): Byte 3 of
word 1 contains an 8-bit unsigned binary integer that specifies the length of the Vendor
Unique Information field in bytes. Up to 128
bytes are supported.
Vendor Identifier: The Vendor Identifier field
contains eight bytes of ASCII data (code values
hex 20 through hex 7E) identifying the vendor
of the product. The data shall be left aligned
within this field. Any unused bytes are placed at
the end of the field (highest offset) and the unused bytes shall be filled with space characters
(hex 20). See X3T10/995D (SCSI-3 Primary
Commands) Annex C for an example of this formatting.
NOTE It is intended that this field provide a
unique vendor identification of the manufacturer of
the Fibre Channel device. In the absence of a formal registration procedure, X3T10 maintains a list
of vendor identification codes in use. Vendors are

dpANS X3.xxx-199x
requested to voluntarily submit their identification
codes to X3T10 to prevent duplication of codes.

Capability Entry: The Capability Entry field is

shown in table 165.

Table 165 Capability Entry

Item

Size Bytes

Flags: IEVVrrPP (bits)

Document Identifier

Low Revision

High Revision

Reserved

0 or 2

Extension Length (N)

0 or 2

Extension

0 or N

Flags: The Flags specify the type of entry as

well as other defining information for this entry.

se r vic e e xc h a ng e . Th e r e sp o n din g N_
Port shall clear any parameter or mode
settings associated with the invalidated
Capability Entry. The responding N_Port
shall select another Capability Entry from
th e se t o f e n trie s in th e R NC p a ylo ad .
(The Capability Entry with the Invalid bit
set is not a valid selection).
Bit 6 - Extended (E)
0 = No Extension
1 = Extended Format
If the Extended bit is 0, then the Capabilities Entry is exactly 4 bytes long.
If the Extended bit is 1, then the Capabilities En try is gre ater than 4 byte s lon g.
Byte 6 (offset from the beginning of this
capability entry) specifies the Extension
Length.
Bits 5-4 - Vendor Unique (V)

Bit 7 - Invalidate Previous (I)

00 = D ocume nt Iden tifie r is not ve ndo r

unique.

0 = Selectable Entry

01 = Document Identifier is vendor unique

1 = Invalidate Previous Selection

10 = Document Identifier is vendor unique

as d efine d b y vend or o f th e N_ Port receiving the payload.

Th is b it is on ly me a n in g fu l if th e R NC
Fla g s S e le ct b it is o n . F ur th e r mo r e , it
shall be set on the first Capability Entry in
the payload. It is used when the requesting N_Port wants to cancel the capability
entry selected with a previous RNC link
service request and have the responding
N_Port make a new selection.
When the RNC Flags Select bit is set to
1, and the first Capability Entry Flags Invalidate bit is set to 0, then the requesting
N_Port is specifying that the responding
N_Port shall select one of the Capability
Entries from the entries in the payload.
When the RNC Flags Select bit is set to 1
and the Invalidate bit is set to 1 in the first
Capability Entry, then the requesting N_
Port is indicating that this capability entry
shall be invalidated. All bytes in the Capability Entry marked with the Invalidate
bit shall match the values of a Capability
Entry selected during a previous RNC link

11 = reserved
Vendor unique Document Identifiers are
qualified by the 8-byte ASCII Vendor Identifier. Thus each vendor may use any identifier value, 0 through hex FF, for vendor
unique document identifiers.
When the Vendor Unique bits are set to
10 the N_Port sending the RNC or RNC
Accept must have previously obtained the
Ven do r Id entifie r o f the de stin ation N_
Port. This is inherent if sending an RNC
Accept. If sending an RNC then the information may have been obta ined from a
previous RNC/RNC Accept exchange or
some other method outside the scope of
this standard.
Bits 3-2 - Reserved (r)
Bits 1-0 - Preference (P)
Preference is a two bit value indicating
37

dpANS X3.xxx-199x
the level of support or performance relative to the other capabilities supported for
this FC-4. These may be used as an aid
in choosing a specific capability if multiple capabilities are supported. The Preference value ranges from 0 to 3.

or other information as defined by the referenced

document. This standard does not define the
meaning or content of the extension beyond the
Extension Length field.

Table 166 Document Identifiers

00 = Best
01

Profile or Standard Name

Identifier

Reserved

FC-LE

FC-SB

Document Identifier: If the V flags are 00 this

is a document Identifier as specified in table
166. If the V flag is not 00 then this is a vendor
unique Document Identifier.

IPI-3

SCSI-FCP

FC-FP

Low Revision: The Low Revision field represents the lowest revision of the specified document supported.

Reserved

10
11 = Worst

High Revision: The High Revision field represents the highest revision of the specified document supported.

06-0F

FC-GS

FC-FG

FC-SW

FC-AL

The revision fields shall represent a decimal revision between 0.0 (hex 00) and 25.5 (hex
FF). Changes to the revision number in increments smaller than 0.1 can not be represented
by RNC.

Reserved

FCSI Mixed Mode SCSI Profile

Extension Length: The Extension Length is a

16-bit unsigned binary integer that specifies the
number of additional bytes, including itself and
the precedin reserved field, present in the extended capability entry.

FCSI Class 2 SCSI Profile

FCSI IP Profile

FCSI IP Class 2 Profile

FC-PLDA - Private Loop Direct

Attach

FLA -Fabric Loop Attach Profile

The value of the Extension Length field shall be

a multiple of four. Each document which defines extensions shall ensure the length of the
extension allows four byte alignment.
NOTE For example, if the extension is 1 bytes,
the Extension Length is 8: 2 bytes for the reserved
field, 2 bytes for the Extension Length field, and 4
bytes allocated for the Extension, of which only 1
is used.

Extension: Capability Entry extensions may be

used to specify additional bit flags, parameters,

IBM/HP/Ancor
Deviations

14-1F
FC-PH

Reserved

4.2

27-FF

Vendor Unique Information: The format of the

Vendor Unique Information is defined by vendor or
profile specific documentation.
Reply Link Service Sequence:
Service Reject (LS_RJT)
signifies rejection of the RNC command
(see 21.5.2)
Accept

dpANS X3.xxx-199x
signifies that the destination N_Port has
transmitted the requested data.
- Accept Payload:
The format of the Accept Payload is
identical to the format of the RNC payload, except for the command code, and
is shown in table 164.
RNC Collision:
If an N_Port has transmitted an RNC Link Service request Sequence to an N_Port and receives an RNC Link Service request Sequence
from the same N_Port before the RNC Accept
Sequence then a collision has occurred. To
avoid ambiguity in the case the Select option
was used, N_Ports which implement RNC shall
detect RNC collisions. In the case of a collision
the N_Port shall compare N_Port_Names. If the
N_Port_Name of the sequence recipient is less
than the N_Port_Name of the sequence initiator, then the sequence recipient shall reply with
an LS_RJT, Reason Code = Logical busy.

dpANS X3.xxx-199x

Classes of Service

Enhancements to FC-PH and FC-PH2.

22.6 Class 6 - Uni-Directional Dedicated
Connection
Class 6 is a service which provides Dedicated
Connections for Reliable multicast (see clause
31) for a Fabric topology. A class 6 connection
is requested by an N_Port for one or more destination N_Ports. An acknowledgement is returned by the destination N_Ports to a multicast
server which returns an acknowledge to the
connection initiator, establishing a reliable multicast connection. In general, once a connection
is established, it shall be retained and guaranteed by the Fabric until the connection initiator
requests removal.
22.6.1

Class 6 function

A Class 6 connection is requested by an N_Port

to one or more destination N_Ports via transmission of a frame containing a SOFc1. A
Class 6 SOFc1 is identical to a Class 1 SOFc1.
The Fabric recognizes the multicast D_ID and
performs the Class 6 multicast function. The
Fabric establishes circuits between the requesting N_Port and the destination N_Ports. The
destination N_Ports each transmit an ACK, indicating acceptance, which are intercepted by the
multicast server. The multicast server, based
on the ACKs, RJTs, or BSYs received from the
destinations, transmits an ACK, a P_RJT, or a
P_BSY to the requesting N_Port indicating acceptance, rejection, or busy for the request.
The return of an ACK indicates the establishment of a multicast connection. The Fabric reta i n s t h e a llo c a te d c ir c u it s b e t w e e n th e
requesting N_Port and the destination N_Ports
until the connection initiator request the Dedicated Connection be removed.
Class 1 Delimiters, as specified in FC-PH
clause 22.1.3, are used to establish and remove the Dedicated Connection and to initiate
and terminate one or more sequences within
the Dedicated Connection.
Class 1 service parameters, as specified during
Login, shall be used to manage Class 6 connections.

22.6.2

Class 6 rules

The following rules apply to exclusive Class 6

Connections. See FC-PH 22.4 for additional
rules applicable to intermix. To provide a Class
6 Connection, the transmitting and receiving N_
Ports, Fabric, and multicast server shall obey
the following rules:
a) Except for some Link Service Protocols
(see FC-PH clause 21), an N_Port requesting
a Class 6 Connection is required to have previously logged in with the Fabric and the N_
Ports with which it intends to communicate,
either implicitly or explicitly. To Login explicitly, the requesting N_Port shall use Fabric
and N_Port Login protocols (see FC-PH
clause 23).
b) The Fabric is responsible for establishing
a Connection at the request of an N_Port and
retaining it until the requesting N_Port explicitly requests removal of the Connection or the
requesting N_Ports link participates in a primitive sequence protocol (see FC-PH clause
16.4). To establish or remove the Dedicated
Connection, the requesting N_Port shall use
the Class 1 Delimiters as specified in FC-PH
clause 22.1.3.
c) Afte r tran smittin g a Cla ss 6 /SOFc 1
frame, the N_Port requesting the Connection
shall not transmit additional frames to the
destination N_Ports until it receives, from the
multicast server, an ACK which shall establish the connection.
d) Once a Connection is established between multiple N_Ports, only the requesting
N_Port (Connection Initiator) shall send data
frames. Only the Connection Initiator shall
cause the connection to be terminated. All
frames shall contain S_ID and D_ID as appropriate (i.e. The D_ID shall be the multicast
address).
e) A destination N_Port shall acknowledge
delivery of every valid Data frame with an
ACK_1 or ACK_N, or the entire Sequence
with a single ACK_0 (see FC-PH clause
22.1.5).
f) The Sequence Initiator shall increment
the SEQ_CNT field of each successive frame
transmitted within a Sequence. The Fabric
shall guarantee delivery of the frames at the

dpANS X3.xxx-199x
receivers in the same order of transmission
within the Sequence (see FC-PH clause
24.3.6).
g) The Connection Initiator N_Port of an established Connection may originate multiple
Exchanges and initiate multiple Sequences
within that Connection. This N_Port shall assign a unique X_ID called OX_ID. The multicast server for the Exchange shall assign an
X_ID unique to the Responders called RX_
ID. The value of the RX_ID shall be negotiated during N_Port/Fabric login (see 23.6.8).
Thus, within a given Connection, the value of
OX_ID or RX_ID is unique to the respective
N_Port and multicast server. The Sequence
Initiator (Connection Initiator) shall assign a
SEQ_Qualifier, for each Sequence it initiates,
which is unique to the Sequence Initiator and
the respective Sequence Recipients.

k) The End-to-end Credit established during

the Login protocol by interchanging service
Parameters shall be honored (see FC-PH
clause 26.3). End-to-end credit shall be managed between Connection Initiator and the
multicast server. At the beginning of a Connection, the End-to-end Credit_Count is reinitialized to the value determined during Login.
A Class 6/SOFc1 frame shall share the Endto-end Credit with Class 2 frames (see FCPH clause 26.3).
l) The Fabric shall guarantee full bandwidth
availability to the connected N_Ports (see
FC-PH clause 3 and annex M).
m) Frames within a Sequence are tracked
on an Sequence_Qualifier and SEQ_CNT
basis (see FC-PH clause 18.1.1)
n)

Same as FC-PH Clause 22.1.2 item n.

h) Communicating N_Ports and the multicast server shall be responsible for end-toend flow control, without any fabric involvement. ACK frames are used to perform endto-end flow control (see clause 22.1.5). All
Class 6 frames, except Class 6/SOFc1, participate only in end-to-end flow control. A
Class 6/SOFc1 frame participates in both
end-to-end and buffer-to-buffer flow controls.

o) If an N_Port does not support Class 6

(i.e. does not support Class 1) and receives a
Class 6/SOFc1 frame, the N_Port shall issue
a P_RJT with a SOFn1 and EOFdt with a
reason code of Class not supported. If an F_
Port does not support Class 6 and receives a
Class 6/SOFc1 frame, the F_Port shall issue
an F_RJT with a SOFn1 and EOFdt with a
reason code of Class not supported.

i) The Fabric may reject a request for a

Class 6 Connection or issue a busy with a
valid reason code. After the Dedicated Connection is established, the Fabric shall not interfere with the Connection. The Fabric shall
issue a F_BSY to any Class 2 frame or discard any Class 3 frame, transmitted from a
third N_Port and destined to one of the N_
Ports engaged in the Connection (see FC-PH
clauses 20.3.3.1 and 20.3.3.3).

j) The destination N_Ports specified in the

Class 6/SOFc1 frame may respond with a
busy or a reject with a valid reason code to
this frame. The multicast server shall interpret these responses and respond with an
ACK, busy, or a reject with a valid reason
code to the requesting N_Port (see section
on multicast server). Once the Dedicated
Connection is established, the destination N_
Ports shall not issue a busy but may issue a
reject (see FC-PH clauses 20.3.3.2 and
20.3.3.3).

Same as FC-PH Clause 22.1.2 item p.

q) The Connection Initiator shall send two

zero length payload frames as the last two
frames of a Sequence.
NOTE This simplifies the processing of an abort
on the last non-zero payload frame of a Sequence.

r) The effect of preemption of one destination N_Port on the remaining N_Ports is implementation-dependent.
22.6.3

Class 6 delimiters

Same as FC-PH Clause 22.1.3.

22.6.4

Class 6 frame size

Same as FC-PH Clause 22.1.4.

22.6.5

Class 6 flow control

ACK frames are used to perform Class 6 endto-end flow control. ACK frames are started
with SOFn1. Destination N_Ports shall not ter-

dpANS X3.xxx-199x
minate Sequences or Connections. All ACK
frames shall end with EOFn.
All Class 6 frames shall follow end-to-end flow
control rules (see FC-PH clause 26.4.1). The
Class 6/SOFc1 frame shall follow both end-toend and buffer-to-buffer flow control rules (see
FC-PH clause 26.5.1).
22.6.6

Stacked Connect-requests

Same as FC-PH Clause 22.1.6.

dpANS X3.xxx-199x

Login and Service Parameters

This clause describes the changes that are

made in FC-PH-3 to support:
the E_D_TOV timer resolution enhancement.

Priority/Preemption

Enhancements to FLOGI to expand the

payload.
23.1

erate according to R_RDY Primitive, ACK, and

Link_Response rules specified in clause 20.
Explicit Fabric Login is performed during the initialization process under the assumption that a
Fabric is present. The first explicit Login is directed to the Fabric using the well-known Fabric add r e s s ( i .e ., F _ P o r t a t h e x F F FF FE ) . I t is
mandatory for all Fabric types to support the explicit Login procedure. In its first attempt at explicit
Fabric Login, an N_Port shall set the following S_
ID:

Introduction

The Login procedure is a method by which an

N_Port establishes its operating environment
with a Fabric, if present, and other destination
N_Ports with which it communicates. Fabric Login and destination N_Port Login are both accomplished with a similar procedure using
different Destination_Identifiers (D_IDs) and
possibly different Source_Identifiers (S_IDs).
Login between an N_Port and the Fabric or between two N_Ports is long-lived. The number of
concurrent N_Ports with which an N_Port may
be logged in with is a function of the N_Port facilities available. There is no one to one relationship between Login and Class 1 Dedicated
Connections.
Explicit Login is accomplished using the Login
(FLOGI/PLOGI) Link Service Sequence within
a separate Exchange to transfer the Service
Parameters (contained in the Payload) of the
N_Port originating the Login Exchange. The
Accept (ACC) contains the Service Parameters
of the Responder (contained in the Payload).
Implicit Login is a method of defining and
specifying the Service Parameters of destination N_Ports by means other than the explicit
use of the Login Exchange. Specific methods of
implicit Login are not defined in FC-PH.
When Login is referred to throughout other sections of this document, either the explicit or implicit procedure is acceptable. Implicit Login is
assumed to provide the same functionality as
Explicit Login. Default Login values are specified in 21.1.1. Explicit Login replaces previous
Service Parameters and initializes end-to-end
or buffer-to-buffer credit, or both. The Login
procedure shall follow the Exchange and Sequence management rules as specified in
clause 24. Frames within a Sequence shall op-

Bits 23-0 equal to binary zeroes (denoted as

0), or
Bits 23-8 equal to binary zeroes and bits 7-0
equal to a model-dependent value (denoted as
0000yy).
If the N_Port receives an F_RJT with a reason
code of Invalid S_ID, it may use its last known native address identifier in the FLOGI Sequence as
its S_ID.
The remainder of 23.1 is unchanged from FC-PH.

23.2

Applicability

No change from FC-PH.

23.3
23.3.1

Fabric Login
Explicit Fabric Login

The explicit Fabric Login procedure shall require

transmission of a Login (FLOGI) Link Service Sequence within an Exchange with an assigned OX_
ID by an N_Port with a Destination Identifier (D_
ID) of the well-known F_Port address (FFFFFE)
and a Source Identifier (S_ID) of either 0 or
0000yy.
When S_ID = 0 is used, the F_Port shall either:
assign a Fabric unique N_Port Identifier to
the N_Port in the ACC reply Sequence, or
return an F_RJT with a reason code indicating Invalid S_ID, if the Fabric does not support
N_Port Identifier assignment. The N_Port shall
assign its native N_Port Identifier by another
method not defined in FC-PH and retry the FLOGI Sequence with an S_ID = X.
When S_ID = 0000yy is used, the F_Port shall either:

dpANS X3.xxx-199x
If the F_Port has rejected both S_ID = 0 or
0000yy and S_ID = X, the N_Port shall attempt
to reLogin with another value of X, or determine
a valid value of X by a method not defined in
FC-PH.

assign a Fabric unique N_Port Identifier

to the N_Port in the ACC reply Sequence by
setting bits 23-8 and validating bits 7-0, or
return an F_RJT with a reason code indicating Invalid S_ID, if the value in bits 7-0
does not allow a Fabric unique Identifier to be
generated. The N_Port shall assign a different value for yy and retry the FLOGI Sequence with an S_ID = X.

The remainder of 23.3.1 is unchanged from FCPH.

23.3.2

Responses to Fabric Login

23.3.2.1 FLOGI with S_ID = 0 or 0000yy

If S_ID = X is used, the F_Port shall either:

Table 94 describes the set of possible responses to Fabric Login with an S_ID = 0 or 0000yy
and a D_ID of hex FFFFFE. Further description of the response primitive or frame is found
in clause 20.

return an ACC reply Sequence with D_ID

= X (confirming identifier), or
return an F_RJT with a reason code indicating Invalid S_ID, if X is invalid.

Table 94 Responses to FLOGI frame (S_ID = 0 or 0000yy) - Fabric Login

Response/
Reply Seq

D_ID

S_ID

Indication

N_Port Action

N/A

Class 1 (SOFc1)
Class 2 or 3
successful frame delivery
to F_Port or N_Port

2. Last ACK

0 or
0000yy

FFFFFE

FL O G I Se q ue n ce h as
been received by N_Port or
F_Port

wait f or Reply Data

frame Sequence

3. ACC

X or
XXXXyy

FFFFFE

OX_ID = FLOGI OX_ID

If Co mmo n Se rv = F_
Port, Fabric Login complete

Perform destination N_
Port Login (23.4.2.1) (Fabric present)

4. ACC

0 or
0000yy

FFFFFE

OX_ID = FLOGI OX_ID

If Co mmo n Se rv = N_
Port, no Fabric present

Perform point-to-point
destination N_Port Login
(23.4.2.1)

5. F_BSY or
P_BSY

0 or
0000yy

FFFFFE

1. R_RDY

Busy

6. F_RJT or
P_RJT

0 or
0000yy

FFFFFE

reason code
Class not supported

Invalid S_ID

Other

wait for frame

retry later

FL O GI n e x t C l a s s
(S_ID = 0 or 000yy)
FLOGI with S_ID = X
or different yy
respond accordingly

7. FLOGI

FFFFFE

0 or
0000yy

Collision with other N_

Port

8. LS_RJT

X or
XXXXyy

FFFFFE

Fabric present
reason code

re L o g in w it h a lte r e d
Service Parameters, use
D_ID of LS_RJT

error

perform ABTS after Sequence Timeout

9. None
44

See FC-PH

dpANS X3.xxx-199x
These responses are characterized by the following:
Response 1 is possible from an N_Port or
Fabric.
Response 2 is from a Fabric or an N_
Port. The D_ID and S_ID values (in the response to the FLOGI Sequence) correspond
to the values in the FLOGI fields, respectively, in the FLOGI Sequence (also for responses 5 and 6).

Connection associated with FLOGI shall be

removed by the normal method to remove a
Dedicated Connection in Class 1. See 23.6.4
for a description of N_Port_Names. See
23.4.2.3 for a description of point-to-point
destination N_Port Login.
Response 8 indicates that the Login request is being rejected for a reason specified
in the LS_RJT frame. The FLOGI request
may be retried if the appropriate corrective
action is taken.

Response 3 completes Fabric Login. The

N_Port S_ID is assigned as X or XXXXyy.

Response 9 indicates that a Link error

has occurred.

Response 4 indicates a point-to-point topology with another N_Port, which is determined by examining the Common Service
Parameter which specifies N_Port or F_Port.
Based on a comparison of Port_Names, either transmit PLOGI, or wait for PLOGI.

NOTE When an N_Port originates an Exchange

using an N_Port Identifier of unidentified (binary
zeroes or 0000yy), its N_Port Identifier may
change between transmitting a request Sequence
(Login) and receiving the reply Sequence (Accept).

Response 5 indicates that either the Fabric or N_Port is busy, retry later.
Response 6 indicates a Fabric or N_Port
reject. If Class is not supported, retry Login
with another Class with a numerically higher
value. If the reason code is Invalid S_ID, then
retry FLOGI with a different value of yy, or
with a value of X (see 23.3.2.2). For other reject reasons, the N_Port shall respond accordingly.
Response 7 indicates a point-to-point attachment and a collision with a FLOGI from
the attached N_Port. The N_Port shall respond with ACC. The Common Service Parameters shall contain the same information
as FLOGI, but shall indicate that an N_Port is
transmitting the Data. Port_Name and Node_
Name shall be included, but all Classes of
Service shall be indicated as invalid. The N_
Port shall compare the Port_Name received
to the Port_Name it transmitted. If this N_
Ports value is lower, it shall end this Exchange and wait for a PLOGI from the attached N_Port. In Class 1, if this N_Ports
value is lower, it shall become the Connection Recipient (see clause 28) for this Connection. In Class 1, if its value is higher, it
shall become the Connection Initiator for this
Connection. If its value is higher, it shall
transmit a PLOGI (see 23.4.2.3) as part of a
new Dedicated Connection. The Dedicated

23.6

N_Port Service Parameters

Figure 59 provides the payload format of the

FLOGI or PLOGI Extended Link Service commands and their respective ACC replies.

Item

Size
(Bytes)

LS_Command code

Common Service Parameters

Port Name

Node or Fabric Name

Class 1 Service Parameters

Class 2 Service Parameters

Class 3 Service Parameters

Class 4 Service Parameters

Vendor Version Level

Reserved

Services Availability (see note)

Reserved (see note)

116

Figure 59 FLOGI, PLOGI, or ACC

Payload
NOTE These fields are only present when the
Payload Length bit (see 23.6.2.3) is set to 1. When
the Payload Length bit is set to 0, these fields are

dpANS X3.xxx-199x
not present in the payload, i.e., the payload is 128
bytes long.

23.6.1
ters

N_Port Common Service Parame-

Table 98 provides a summary of N_Port Common Service Parameters based on x3.2301994 (FC-PH) table 98.

dpANS X3.xxx-199x

Table 98 N_Port Common Service Parameter Applicability

N_Port Login
Class
Service Parameter

Fabric Login
Class

Bits

Highest Version

31-24

Lowest Version

23-16

15-0

Continuously Increasing (C)

Random Relative Offset (O)

Vendor Version Level

N_Port/F_Port

Alternate
BB_Credit
Management (see 26.5)

E_D_TOV Resolution (see 23.6)

Payload Length (see 23.6.2.3)

Buffer-to-Buffer
Receive Data field Size

11-0

N_Port
Total
Sequences

31-16

Relative Offset by Info Category

15-0

E_D_TOV (3) (4)

31-0

PTP

FC-PH Version

Buffer-to-Buffer Credit
Common Features

Concurrent

PTP PTP

Notes
1) y indicates yes, applicable
2) n indicates, not applicable
3) PTP indicates the applicability only to Point-to-Point.
4) R_A_TOV and E_D_TOV provided by the F_Port as Fabric Common Service Parameters
during Fabric Login are not shown in this table.

dpANS X3.xxx-199x
23.6.2 N_Port Common Service parameters - Fabric Login
Enhanced N_Port Common Service parameters used during Fabric Login are illustrated in
figure 61.

23.6.2.3 Common features

Word 1, bits 31-30
Reserved.
Word 1, bits 28 (N)
Specified in x3.230-1994 (FC-PH).

31
word

FC-PH / FC-PH-2 /
FC-PH-3 Version

Buffer-to-buffer
Credit (Pt to Pt)

HHHHHHHH LLLLLLLL

BBBBBBBBBBBBBBBB

Specified in x3.xxx-1995 (FC-PH-2).

Word 1, bits 26-17

Common
Features

Buffer-to-buffer
Rcv Data Field size

rrVN Arr r r r r r r r r P

r r r r F F F F FFFF FFFF

Word 1, bits 29, 27 (VA)

Reserved.
Word 1, bit 16- Payload Length (P)

Total Concurrent
Sequences
Reserved
rrrrrrrr rrrrrrrr

Relative Offset by
Info Category
Reserved
rrrrrrrr rrrrrrrr

1 = 256 bytes

Reserved
rrrrrrrr rrrrrrrr

Figure 60 N_Port Common Service

Parameters - Fabric Login
23.6.2.1 FC-PH-3 version
Table 99 specifies the hexadecimal values for
low and high FC-PH-3 version levels indicated
in word 0, bits 31-16 of N_Port Common Service parameters.

Table 99 FC-PH-3 Version

Hex value

Word 1, Bit 16 indicates the length of the

FLOGI payload. If Word 1 Bit 16 = 0, then
the payload shall be 128 bytes, the same
as specified in FC-PH-2. If Word 1 Bit 16
= 1, then the payload shall be 256 bytes.
23.6.2.4 Buffer-to-buffer Data_Field size
Word 1, bits 15-0 Buffer-to-buffer
Receive Size (F)
T h e b u f f e r - t o - b uf f e r R e c e i v e D a t a _
Field Size is a binary value (bits 15-0)
w h ich s pe cifies the la rg est Da ta_ Field
Size for an FT_1 frame (17.4) that can be
received by the N_Port supplying the Service Parameters as a Sequence Recipient for:

a connect-request (SOFc1),

a Class 2 Data frame, or

a Class 3 Data frame.

Version level

00-09

See FC-PH Tables 99 or 100

0A-0F

Reserved

FC-PH-2

11-1F

Reserved

FC-PH-3

21-FF

Reserved

23.6.2.2 Buffer-to-buffer credit

No change from FC-PH.

0 = 128 bytes

Values less than 256 or greater than 2 112 are

invalid. Values shall be a multiple of four bytes.
The buffer-to-buffer Receive Data_Field size is
specified by FC-2.
23.6.3 N_Port Common Service Parameters - N_Port Login
N_Port Common Service Parameters used during N_Port Login are shown in figure 61.

dpANS X3.xxx-199x
31

FC-PH / FC-PH-2
Version

Buffer-to-buffer
Credit (Pt to Pt)

HHHHHHHH LLLLLLLL

BBBBBBBBBBBBBBBB

word
0

Common
Features

Buffer-to-buffer
Rcv Data Field size

COVNAR r r r D r r r r r P

r r r r F F F F FFFF FFFF

31
2

Total Concurrent
Sequences
rrrrrrrr TTTTTTTT

Relative Offset by
Info Category
DDDDDDDDDDDDDDD

E_D_TOV
3

(Pt-to-Pt)
tttttttt

tttttttt

tttttttt tttttttt

Figure 61 N_Port Common Service

Parameters - N_Port Login
23.6.3.1 FC-PH-3 version
Same as 23.6.2.1.
23.6.3.2 Buffer-to-buffer credit
No change from FC-PH.

Word 1, Bit 25 indicates the length of the

PLOGI payload. If Word 1 Bit 25 = 0, then
the payload shall be 128 bytes, the same
as specified in FC-PH-2. If Word 1 Bit 25
= 1, then the payload shall be 256 bytes.
23.6.3.4 Buffer-to-buffer Data_Field size
Word 1, bits 15-0 Buffer-to-buffer
Receive Size (F)
The buffer-to-buffer Receive Data_
Field Size is a bin ary va lue (bits 15 -0 )
wh ich sp ec ifie s th e la rg e st D ata _ Fie ld
Size for an FT_1 frame (17.4) that can be
received by the N_Port supplying the Service Parameters as a Sequence Recipient for:

a connect-request (SOFc1),

a Class 2 Data frame, or

a Class 3 Data frame.

Values less than 256 or greater than 2 112 are

invalid. Values shall be a multiple of four bytes.
The buffer-to-buffer Receive Data_Field size is
specified by FC-2.

23.6.3.3 Common features

23.6.3.5 Total Concurrent Sequences
Word 1, bits 31- 28 (COVN)
Specified in x3.230-1994 (FC-PH).
Word 1, bit 27, 22 (AD)
Specified in x3.xxx -1995 (FC-PH-2).
Word 1, bit 26 - E_D_TOV Resolution (R)
0 = 1 ms
1 = 1 ns
Word 1, Bit 26 indicates the resolution of
the E_D_TOV timer. If Word 1 Bit 26 = 0,
then the timer shall be in increments of 1
ms. If Word 1 Bit 26 = 1, then the timer
shall be in increments of 1 ns.
Word 1,bits 25-23, 21-17
Reserved
Word 1, bit 16 - Payload Length (P)
0 = 128 bytes

No change from FC-PH.

23.6.3.6 Relative Offset by category
No change from FC-PH.
23.6.3.7 Point-to-point E_D_TOV value
Word 3 shall only be meaningful by an N_Port
in a point-to-point topology. In a topology other
than point-to-point, word 3 shall not be meaningful. When Word 1, Bit 26 = 0, the E_D_TOV
value shall be specified as a count of 1 ms increments. When Word 1, Bit 26 = 1, the E_D_
TOV value shall be specified as a count of 1 ns
increments. Therefore, based on the setting of
Word 1, Bit 26, a value of hex 0000000A specifies a time period of either 10 ms or 10 ns.
The E_D_TOV value in the Accept shall be
greater than or equal to the value in the PLOGI.
The E_D_TOV value in the Accept shall be the
value used by each N_Port. R_A_TOV shall be
a value twice the E_D_TOV value in a point-topoint topology.

1 = 256 bytes

dpANS X3.xxx-199x
23.6.6

N_Port Class Service Parameters

Table 98 provides a summary of N_Port Class Service Parameters based on FC-PH-2 table 101.

Table 101 N_Port Class Service Parameter Applicability

N_Port Login
Class
Service Parameter

Fabric Login
Class

Bits

1/6

Intermix Mode

Stacked Connect-Request

29-28

Sequential Delivery

Dedicate Simplex

Camp-On

Buffered Class 1

Priority (see 18.9.2)

X_ID Reassignment

15-14

Initial Responder Process_Associator

13-12

ACK_0 capable

ACK_N capable

ACK generation assistance

Data compression capable

Data compression History buffer size

7-6

Data encryption capable

Clock synchronization capable

FC-PH Version
Valid = 1
Service Options

Initiator Control

dpANS X3.xxx-199x
Table 101 N_Port Class Service Parameter Applicability
N_Port Login
Class
Service Parameter

Fabric Login
Class

Bits

1/6

ACK_0 capable

ACK_N capable

X_ID Interlock

Error Policy Supported

28-27

Categories per Sequence

25-24

Data compression capable

Data compression History buffer size

22-21

Data decryption capable

Clock synchronization capable

Reserved - Fabric specific

18-16

Receive Data Field Size

15-0

Concurrent Sequences

31-16

N_Port End-to-end Credit

14-0

Open Sequences per Exchange

31-16

Recipient Control

Notes
1) y indicates yes, applicable
2) n indicates, not applicable

See FC-PH or FC-PH-2 for all items without

cross-references.

dpANS X3.xxx-199x
23.6.7 N_Port Class Service Parameters Fabric Login
Figure 62 illustrates N_Port Class Service Parameters for Fabric Login, enhanced from
x3.230-1994 (FC-PH) and X3.xxx-1995 (FCPH-2).

31
word

Initiator Control

VISSQDCB PEEEEEEE

DDDDDDDD DDDDDDDD

Rcv Data Field size

CCCCCCCC CCCCCCCC

r r r r F F F F FFFF FFFF

Neither supports

Fabric is capable of supporting.

N_Port support requested, Fabric does not support

N _Port requested, Fabr ic

agrees, Priority/Preemption is
enabled

Class 3
Word 0, bit 23 is reserved.
Word 0, Bit 22 - 16

Concurrent
Sequences
rrrrrrrr LLLLLLLL
31

Recipient Control

Service Options

N_Port F_Port

Open Sequences per

Exchange

rrrrrrrr xxxxxxxx

N_Port End-to_end
Credit

Reserved
23.6.7.3 Initiator control

0MMMMMMMMMMMMMMMM

This field is not meaningful during Fabric Login.

23.6.7.4 Recipient control

Reserved

This field is not meaningful during Fabric Login.

rrrrrrrr

rrrrrrr

Figure 62 N_Port Class Service

Parameters - Fabric Login

23.6.7.5 Receive Data_Field Size

This field is not meaningful during Fabric Login.

23.6.7.1 Class Validity (V)

23.6.7.6 Concurrent Sequences

No change from FC-PH or FC-PH-2

This field is not meaningful during Fabric Login.

23.6.7.2 Service Options

Word 0, Bit 30-24 (ISSQDCB)
Class 1, 2, 3, and 4
No change from FC-PH or FC-PH-2
Word 0, Bit 23 - Priority/Preemption (P)
0 = Priority/Preemption not supported
1 = Priority/Preemption supported
See clause 18.9

23.6.7.7 N_Port End-to-end Credit

This field is not meaningful during Fabric Login.
23.6.7.8 Open Sequences per Exchange
This field is not meaningful during Fabric Login.
23.6.8 N_Port Class Service Parameters N_Port Login
Figure 62a illustrates N_Port Class Service Parameters for N_Port Login, enhanced from
x3.230-1994 (FC-PH) and X3.xxx-1995 (FCPH-2).

Class 1, 2, and 4

23.6.8.1 Class Validity (V)

When an N_Port performs Login with a Fabric,

it shall request support for Priority/Preemption
by specifying bit 23 = 1. If the Accept reply from
the Fabric specifies bit 23 = 1, then both the N_
Port and Fabric have agreed that Priority/Preemption is enabled.

No change from FC-PH or FC-PH-2

The following set of values specifies the meaning of the combination of Word 0, bit 23:

No change from FC-PH or FC-PH-2

23.6.8.2 Service Options

Word 0, Bit 30-24 (ISSQDCB)
Class 1, 2, 3, and 4

dpANS X3.xxx-199x
31
word
0

VISSQDCB PEEEEEEE

XXPPZNGC CCEDDDDD

Recipient Control

Word 0, Bit 5
= 0 Initiator does not have data encryption capability

Rcv Data Field size

= 1 Initiator has data encryption capability

Class 4

ZNXLLrSS

CCCEYrrr

Concurrent
Sequences
rrrrrrrr LLLLLLLL
31

Initiator Control

Service Options

r r r r NNNNNNNNNNNN
15

N_Port End-to_end
Credit
16

Open Sequences per

Exchange

rrrrrrrr xxxxxxxx

Same function as Class 1 and 2.

0MMMMMMMMMMMMMMMM

Word 0, bit 4 - Clock synchronization

capable (Y)

Class 1,2,3, and 4 (see 39.4.1)

Class 6 Multicast
RX_ID
xxxxxxxx xxxxxxxx

Figure 62a N_Port Class Service

Parameters - N_Port Login
Word 0, Bit 23 - Priority (P)
0 = Priority not supported
1 = Priority supported
See clause 18.9

Word 0, Bit 4
= 0 Initiator does not have clock synchronization capability
= 1 Initiator has clock synchronization capability
23.6.8.4 Recipient control
Word 1, bit 20 - Data decryption capable
(E)

Class 1, 2, and 4

Class 1,2, and 3 (see 40.2)

When an N_Port performs Login with another

N_Port, it shall indicate support for Priority by
specifying bit 23 = 1. The other N_Port indicates support for Priority by specifying bit 23 =
1 in the ACC sent as a reply. Support of Priority
as an Exchange Originator means that Word 4,
Bits 31-24 of the Frame Header shall specify
the desired Priority and Word 4, Bits 23-16 of
the Frame Header shall specify the OX_ID.
Support of Priority as an Exchange Responder
means that Word 4, Bits 31-24 of the Frame
Header shall be ignored and Word 4, Bits 23-16
of the Frame Header shall be interpreted as the
OX_ID.

Word 1, Bit 20

Class 3

Word 1, Bit 19

Word 0, bit 23 is reserved.

= 0 Recipie nt does not have clock synchronization capability

Word 0, Bit 22 - 16
Reserved
23.6.8.3 Initiator control
Word 0, bit 5 - Data encryption capable
(E)
Class 1,2, and 3 (see 40.2)

= 0 Recipient does not have data decryption capability

= 1 Recipient has data decryption capability
Class 4
Same function as Class 1 and 2.
Word 1, bit 19 - Clock synchronization
capable (Y)
Class 1,2,3, and 4 (see 39.4.1)

= 1 Recipient has clock synchronization

capability
23.6.8.5 Receive Data_Field Size
No change from FC-PH or FC-PH-2.
23.6.8.6 Concurrent Sequences
No change from FC-PH or FC-PH-2.
53

dpANS X3.xxx-199x
23.6.8.7 N_Port End-to-end Credit

23.7.1.1 FC-PH-3 version

No change from FC-PH or FC-PH-2.

Same as 23.6.2.1.

23.6.8.8 Open Sequences per Exchange

23.7.1.2 Buffer-to-buffer (F_Port) Credit

No change from FC-PH or FC-PH-2.

23.6.8.9 Class 6 Multicast RX_ID

23.7.1.3 Common features

When an N_Port performs Login with the Multicast Server, it shall specify the RX_ID value to
be used by the Multicast Server when acknowledging the Connection Initiator. Word 3, bits 150 shall be the RX_ID value used by the Muticast Server.

Word 1, bits 31-27

23.6.9

1 = 1 ns

Vendor Version Level

No change from FC-PH-2.

23.6.10

Services Availability

F_Port Service Parameters

23.7.1
ters

Word 1, bit 26 - E_D_TOV Resolution (R)

0 = 1 ms

Word 1, Bit 26 indicates the resolution of

the E_D_TOV timer. If Word 1 Bit 26 = 0,
then the timer shall be in increments of 1
ms. If Word 1 Bit 26 = 1, then the timer
shall be in increments of 1 ns.

This field is reserved.

23.7

Specified in x3.230-1994 (FC-PH).

F_Port Common Service Parame-

Word 1, bits 25-24, 22 (MB, D)

Specified in x3.xxx-1995 (FC-PH-2).

Figure 67 illustrates F_Port Common Service

Parameters, enhanced from x3.230-1994 (FCPH) and X3.xxx-1995 (FC-PH-2).

Word 1, bit 23 - Hunt Group (H)

0 = Hunt Groups not supported.
1 = Hunt Groups supported.

31
word

FC-PH / FC-PH-2
Version

Buffer-to-buffer
Credit

HHHHHHHH LLLLLLLL

BBBBBBBBBBBBBBBB

Common
Features

Buffer-to-buffer
Rcv Data Field size

rrrN rRMB HDrr rrrr

r r r r F F F F FFFF FFFF

Specified in x3.230-1994 (FC-PH).

Word 1, bit 16- Payload Length

Word 1, bits 21-17

R_A_TOV

tttttttt
31

0 = 128 bytes

tttttttt tttttttt ttttttt

1 = 256 bytes
0

E_D_TOV

tttttttt

tttttttt tttttttt

Figure 67 F_Port Common Service

Parameters - Fabric Login

Word 1, Bit 23 indicates whether or not

the Fabric supports Hunt Group routing. If
Word 1 Bit 23 = 0, then the Fabric shall
not support Hunt Group routing. If Word 1
Bit 23 = 1, then the Fabric shall support
Hunt Group routing.

Word 1, Bit 25 indicates the length of the

ACC payload. If Word 1 Bit 25 = 0, then
the payload shall be 128 bytes, the same
as specified in FC-PH-2. If Word 1 Bit 25
= 1, then the payload shall be 256 bytes.

dpANS X3.xxx-199x
23.7.1.4 Buffer-to-buffer Data_Field size

Word 1, bits 15-0 Buffer-to-buffer

Receive Size (F)
The buffer-to-buffer Receive Data_
Field Size is a bin ary va lue (bits 15-0 )
wh ich sp ec ifie s th e la rg es t D ata _Fie ld
Size for an FT_1 frame (17.4) that can be
received by the F_Port supplying the Service Parameters as a Sequence Recipient for:

VISSQDCB PEEEEEEE

Not Meaningful

31
1

a Class 3 Data frame.

Recipient Control
Reserved for Fabric
use
31

Not Meaningful

Rcv Data Field size

Concurrent
Sequences
Not Meaningful

tttttttt

Figure 67a F_Port Class Service

Parameters - Fabric Login
23.7.4.1 Class Validity

23.7.1.5 E_D_TOV

No enhancements to FC-PH or FC-PH-2

When Word 1, Bit 26 = 0, the E_D_TOV value

shall be specified as a count of 1 ms increments. When Word 1, Bit 26 = 1, the E_D_TOV
value shall be specified as a count of 1 ns increments. Therefore, based on the setting of
Word 1, Bit 26, a value of hex 0000000A specifies a time period of either 10 ms or 10 ns.

23.7.4.2 Service Options

No change from FC-PH or FC-PH-2.

23.7.2

F_Port Name

No change from FC-PH or FC-PH-2.

23.7.3

Fabric Name

Service Options (E) shall specify Class of Service capabilities supported or required by the
Fabric supplying the Service Parameters. (FCPH)
Service options shall specify optional features
of a Class of Service supported by the N_Port
supplying the Service Parameters. (FC-PH-2)
Word 0, Bit 31-24 (VISSQDCB)
Class 1, 2, 3, and 4
No change from FC-PH or FC-PH-2
Word 0, Bit 23 - Priority (P)

No change from FC-PH or FC-PH-2.

Class 1, 2, and 4

23.7.4

0 = Priority/Preemption not supported

F_Port Class service Parameters

Figure 67a illustrates F_Port Class Service Parameters, enhanced from x3.230-1994 (FC-PH)
and X3.xxx-1995 (FC-PH-2).

CR_TOV
tttttttt tttttttt tttttttt

Values less than 256 or greater than 2 112 are

invalid. Values shall be a multiple of four bytes.

23.7.1.6 R_A_TOV

N_Port End-to_end
Credit
Not Meaningful
16 15

a Class 2 Data frame, or

Initiator Control

a connect-request (SOFc1),

Service Options

word

1 = Priority/Preemption supported
See clause 18.9
Class 3
Word 0, bit 23 is reserved.
23.7.4.3 Initiator control
No change from FC-PH or FC-PH-2.
23.7.4.4 Recipient control
No change from FC-PH or FC-PH-2.

dpANS X3.xxx-199x

No change from FC-PH or FC-PH-2.

this bit shall indicate that the Fabric does

not support routing to the well-known Key
Distribution Server address identifier.

23.7.4.6 Concurrent Sequences

Word 0, bit 7 - Alias Server

23.7.4.5 Receive Data_Field Size

No change from FC-PH or FC-PH-2.

23.7.4.7 N_Port End-to-end Credit
No change from FC-PH or FC-PH-2.
23.7.4.8 Open Sequences per Exchange
No change from FC-PH or FC-PH-2.
23.7.4.9 C_R_TOV
No change from FC-PH-2.
23.7.5

Vendor Version Level

This field is reserved.

23.7.6

Services Availability

This field returns information regarding the Fabrics ability to route to the defined well-known
addresses.

When set to 1, this bit shall indicate that

the Fa bric supp orts ro utin g to the wellk n o w n A lia s S e r ve r a d d r e s s i d e n tif ie r
( hex FFFFF8) . Wh en s et to 0 , this bit
s ha ll in dica te th a t th e Fa br ic d o es n o t
supp ort routing to the well-known Alias
Server address identifier.
Word 0, bit 6 - Quality of Service
Facilitator
When set to 1, this bit shall indicate that
the Fa bric supp orts ro utin g to the wellknown Quality of Service Facilitator address identifier (hex FFFFF9). When set
to 0, this bit shall indicate that the Fabric
d o e s n o t s u p p o r t r o u t i n g t o t h e w e l lknown Quality of Service Facilitator address identifier.

Word 0, bits 31-11 - Reserved

Word 0, bit 5- Management Server

Word 0, bit 10 - Multicast Server

When set to 1, this bit shall indicate that

the Fa bric supp orts ro utin g to the wellknown Management Server address identifier (hex FFFFFA). When set to 0, this
bit shall indicate that the Fabric does not
suppo rt routin g to th e well-known Man agement Server address identifier.

When set to 1, this bit shall indicate that

the Fa bric suppo rts ro utin g to the wellknown Multicast Server address identifier (hex FFFFF5). When set to 0, this bit
s ha ll in dica te th a t th e Fa br ic d o es n o t
support routing to the well-known Multicast Server address identifier.
Word 0, bit 9 - Clock Synchronization
Server
When set to 1, this bit shall indicate that
the Fa bric suppo rts ro utin g to the wellknown Clock Synchronization Server address identifier (hex FFFFF6). When set
to 0, this bit shall indicate that the Fabric
d o e s n o t s u p p o r t r o u t i n g t o t h e w e ll known Clock Synchronization Server address identifier.
Word 0, bit 8 - Security Key Distribution
Server
When set to 1, this bit shall indicate that
the Fa bric suppo rts ro utin g to the wellkno wn Key Distribution Server address
identifier (hex FFFFF7). When set to 0,

Word 0, bit 4- Time Server

When set to 1, this bit shall indicate that
the Fa bric supp orts ro utin g to the wellk n o w n Tim e S e r ve r a d d re ss id e n tif ie r
(h ex FFFFFB). W hen se t to 0, th is bit
s ha ll in dica te th a t th e Fa br ic d o es n o t
supp ort routing to the well-kn own Time
Server address identifier.
Word 0, bit 3 - Directory Server
When set to 1, this bit shall indicate that
the Fa bric supp orts ro utin g to the wellknown Directory Server address identifier
(h ex FFFFFC). When se t to 0, this bit
s ha ll in dica te th a t th e Fa br ic d o es n o t
support routing to the well-known Directory Server address identifier.

dpANS X3.xxx-199x
Word 0, bits 2-0 - Reserved
Words 1-7 - Reserved
23.8 Procedure to estimate end-to-end
Credit
No change from FC-PH or FC-PH-2.

dpANS X3.xxx-199x

2 4 E x c h a n ge , S e q ue nc e , a n d s e quence count management

Enhancements to FC-PH and FC-PH-2 are
specified.
24.3

Summary rules

24.3.1

Exchange management

i) In Process policy with infinite buffers under Class 1 operation, a Sequence is complete with regard to Data content if at least
the first and last Data frames were received
as valid frames without rejectable errors being detected. For Class 3 Process policy with
infinite buffers, a sequence is complete if a
frame of another sequence is received or E_
D_TOV expires before the last frame of the
current sequence is received.
24.3.7

Normal ACK processing

g) ACK_1 or ACK_N frames with an ACK_CNT

of 1, or an ACK_0 frame, shall be transmitted
during X_ID interlock, (see 25.3.1 and 24.5.4)
and in response to a connect-request (see
28.4.1).
24.3.11

Sequence errors - Class 3

Errors within a Sequence may only be detected

by the Sequence Recipient.
24.3.11.1 Rules common to all Discard
policies
NOTE The following is identical to FC-PH,
24.3.11.

In both Discard policies, the Sequence Recipient shall discard Sequences in the same manner as in Class 1 and 2 with the exception that
an ACK indication of Abort Sequence shall not
be transmitted. In discard policy, the Recipient
shall discard frames received after the point at
which the error is detected. Individual FC-4s or
upper levels may recover the entire Sequence
or only that portion after which the error is detected.
a) The types of errors that shall be detected
by an N_Port include:
detection of a missing frame based on
timeout, or

b) If a Recipient detects an internal error, it

detection of an internal malfunction.

c) If a Recipient detects a missing frame, it

shall abnormally terminate the Sequence,
post the appropriate status, and notify the
FC-4 or upper level. One or more Sequences
shall not be delivered based on single or multiple Sequence discard Error Policy.
d) In the Discard multiple Sequences Error
Policy in Class 3, the Sequence Recipient
shall not be required to utilize a timeout value
of R_A_TOV following detection of a missing
frame. Therefore, frames may be discarded
for an Exchange forever if other detection
mecha nisms are no t utilize d b y the Sequence Initiator.
e) Notification of the Sequence error condition to the Initiator is the responsibility of the
FC-4 or upper level.
24.3.11.2 Process with infinite buffers Error
Policy
In process Policy, the Recipient shall ignore errors detected on all frames, or timeout errors.
However, such errors shall be reported to an
upper level.
NOTE Ignoring an error on the first frame of a
Sequence or an Exchange may cause the frame to
be delivered to the wrong Recipient.

24.8
24.8.1

Status blocks
Exchange Status Block

An Exchange Status Block is a logical construct

used to associate the OX_ID, RX_ID, D_ID and
S_ID of an Exchange. The Status Block is used
throughout the Exchange to track the progress
of the Exchange and identify which N_Port
holds the initiative to transmit Sequences. The
Exchange Status Block shall continue to exist
even following X_ID Invalidation, since
the Operation_Associator is used to locate the
ESB (use of a Process_Associator may also be
required).
The Exchange Status Block shall record Exchange status information and Sequence Status for a number of Sequences received as a

dpANS X3.xxx-199x
Sequence Recipient. The Exchange Status
Block is supplied in the RES Link Services request. Equivalent information to track transmitted Sequences is required by the Sequence
Initiator fo r internal tracking of Exchange
progress but is not required to be supplied to
any other N_Port. The Sequence Status is
stored in the Exchange Status Block in the oldest to newest order. The oldest Sequence is
dropped out of the ESB when new Sequence
status is added
.
Table 103 Exchange Status Block
Item

Size Bytes

PRIORITY* (if enabled)

OX_ID/with priority enabled

24.8.2

Sequence Status Block

A Sequence Status Block is a logical construct

used to track the progress of a single Sequence
by an N_Port on a frame by frame basis. A Sequence Status Block shall be Opened and
maintained by the Sequence Recipient for each
Sequence received in order to support the RSS
Link Service request. Information equivalent to
an SSB is required for the Sequence Initiator to
track Sequence progress internally, but is not
required to be supplied to any other N_Port
.
Table 104 Sequence Status Block

1
2/1

Item

SizeBytes

SEQ_ID

reserved

Lowest SEQ_CNT

Highest SEQ_CNT

S_STAT

Error SEQ_CNT

Frame header Word 4, Bits 31-16

RX_ID

reserved

RX_ID

Originator address
identifier
(High order byte - reserved)

Responder Address Identifier

(High order byte - reserved

E_STAT
reserved
Service Parameters

Bits 20-0 - Reserved

112

Oldest Sequence Status (SSB

format- first 8 bytes)

Intermediate Sequence Status

(SSB format-first 8 bytes

X*8

Newest Sequence Status (SSB

format-first 8 bytes)

* MSB is Preemption Flag

E_STAT
Bit 31-22

Frame header Word 4, Bits 31-16: When priority is enabled, this field shall contain the current priority in the high order byte and the OX_
ID in the low order byte. When priority is not enabled, this field shall contain the OX_ID.
S_STAT
Bit 15-0
No enhancements to FC-PH or FC-PH-2

No enhancements to FC-PH or FC-PH-2

Bit 21- Priority Enabled
0 = Priority/Preemption not enabled
1 = Priority/Preemption enabled
Priority/Preemption enabled reflects the
condition set on login for Word 4, Bits 3116 of the frame header.

dpANS X3.xxx-199x

Association Header management and usage

No enhancements from FC-PH or FC-PH-2.

Flow control management

No enhancements from FC-PH or FC-PH-2.

Segmentation and reassembly

No enhancements from FC-PH or FC-PH-2.

dpANS X3.xxx-199x

Connection management

Enhancements to FC-PH as specified.

28.1

to by an ACK frame. A proper response frame

consists of:

Introduction

Preempting a Dedicated Connection

Interrupting and removing a Class 1 or Class 6
Dedicated Connection between N_Ports and
establishing a new Class 1 or Class 6 Dedicated Connection between an unconnected N_
Port and one or more of the previously connected N_Ports is Preemption. A preemption is initia ted b y a N_ Po rt s ou rcin g a Pr ee mp tio n
Connection Request frame (an SOFc1 with the
Preemption flag set, Word 4 bit 31) to the Fabric. The preempting N_Port then receives (1) a
reject link response frame (F_RJT) with either a
Preemption Request Rejected or a Preemption Not Enabled reason code, or (2) a connection acknowledge (ACK_1 or ACK_N) with an
SOFn1 having the appropriate S_ID and D_ID
fields of the preemption request frame. When
the ACK is received a dedicated connection
has been established. If an F_RJT is received
no connection has been established and the
preemption request process has ended.
NOTE Fabric resolution of a preemption request
may be based on the priority of the connection request (established when the connection request
was processed by the Fbric) and the priority of the
preemption request as provided to the Fabric in
Word 4, bits 30-24 of the preemption request
SOFc1 header. If priority is used for preemption request resolution, a preemption request will be rejected with a Preemption Request Rejected
reason code if the preemption request priority is
equal to or less than the connection being preempted.

Once a preemption request results in a Dedicated Connection all Dedicated Connection and
disconnection rules defined in FC-PH shall be
followed.
28.4
28.4.1

Connect/disconnect rules
Connect-request rules

An ACK_1, ACK_N, or ACK_0 frame with:

An SOFn1 delimiter

an S_ID of (B) and a D_ID of (A)

an EOFn or EOFt delimiter

28.5
28.5.4

Establishing a Connection
Destination of a connect-request

When N_Port(B) is not connected, but is available, and it receives a connect-request as the
destination N_Port, N_Port (B) transmits the
appropriate ACK frame (ACK_1, ACK_N, or
ACK_0) to N_Port (A) which is requesting the
connection. After the ACK frame has been
transmitted with SOFn1, a Dedicated Connection is established with N_Port (A) as the Connec tion Initiator and N_Port (B) as the
Connection Recipient. After a Connection has
been established, N_Port (B) may initiate Sequences with N_Port (A) using an SOFi1 delimiter.
If N_Port (B) is not connected, but is busy, and
it receives a connect-request as the destination
N_Port from N_Port (A), it respondes with P_
BSY with an EOFdt delimiter.
See 28.4.1 for the rules which a destination N_
Port of a connect-request shall follow.
28.9

Connection Preemption

The procedure for preempting a Dedicated

Connection is specified in this subclause.
28.9.1

Applicability

This preemption process applies only to Class

1 and Class 6 Service. Other preemption processes may be defined that apply to other connection oriented classes of service.
28.9.2

Topology Model

The following sections specify the rules governing the behavior of the source and destination
of the connect-request.

An N_Port that uses preemption shall have the

ability to be connected to another N_Port
through a Fabric.

28.4.1.1 Source of connect-request

28.9.3

d) A Dedicated Connection is established when

the connect-request frame has been responded

The following subsections specify the rules governing the behavior of the preemptor (P), pre-

Rules for Preemption

dpANS X3.xxx-199x

empted source (PS) or destination (PD), and

the preemption destination (PnD).

an S_ID of the PnD and a D_ID of

the P, and

28.9.3.1 Preemptor (P)

The following rules specify the procedure for
preempting a Dedicated Connection with respect to the Preemptor.

an S_ID of the P N_Port and a D_ID of

the PnD N_Port(s)

an EOFn or EOFt ending delimiter

b) The Data Field of the SOFc1 preemption

request frame shall be limited to the smaller
of
the maximum buffer-to-buffer Receive_
Data_Field size specified by the Fabric, or
the maximu m Receive_Data_Field
size specified by the destination N_Port.
c) After the P N_Port transmits the SOFc1
frame it shall wait for the response frame before transmitting another frame for this seq u e n c e . Ad d it io na l s e qu e n c e s fo r th is
connection shall not be initiated until the Dedicated Connection is established.

an ACK_1, ACK_N, or ACK_0 frame

with:

a F_BSY or F_RJT frame with:

an SOFn1 delimiter, and

an S_ID of the PnD and a D_ID of

the P, and

an EOFdt delimiter

g) After a Dedicated Connection is established, the P N_Port shall be the Connection

Initiator and the PnD(s) shall be the Connection Recipient(s).
h) After a Dedicated Connection is established (i.e., the ACK to the SOFc1 preempt ion reques t has been rec eiv ed), the
Connection Initiator may continue transmitting its initial Sequence and initiate other Sequences with SOFi1 up to the Connection
Recipients ability to support Concurrent Sequences.
28.9.3.2 Preempted Source (PS)
The following rules specify the procedure for a
preempted source. The PS is the connection
initiator N_Port for a Class 1 or Class 6 connection.
a)

d) A Dedicated Connection is established

when the SOFc1 frame has been responded
to by an ACK (ACK_1 or ACK_N) frame. A
proper response frame consists of:

an EOFdt delimiter

f) An alternate response frame is also possible from the Fabric F_Port:

the Unidirectional bit (F_CTL bit 8) shall

be set = 0 for bidirectional Connection, and
= 1 for a unidirectional Connection

an SOFn1 delimiter, and

an S_ID of the PnD and a D_ID of

the P, and

the E_C bit (F_CTL bit 18) shall be set

the preemption flag bit (Word 4, bit 31)

shall be set = 1.

a P_BSY or P_RJT frame with:

An SOFc1 delimiter

a Data (Device_Data or Link_Data)

frame

an EOFn, or EOFt delimiter

e) An alternate response frame is also possible from the PnD N_Port:

a) An N_Port shall initiate a preemption request using a Data (Device_Data or Link_Data) frame directed to the desired destination
N_Port. The SOFc1 preemption request
frame shall be formed as follows:

an SOFn1 delimiter, and

If a basic link service frame consisting of:

an PRMT command with:

an SOFc1 delimiter, and

an S_ID of the P and a D_ID of the

PS, and

dpANS X3.xxx-199x

an EOFdt delimiter

is received by a connection initiator N_

Port, that N_Ports Dedicated Connection
has been removed. This PS N_Port should
notify its host that its Dedicated Connection has been preempted.

an ACK_1, ACK_N, or ACK_0 frame

with:

an S_ID of the PnD N_Port and a D_

ID of the P, and

28.9.3.3 Preempted Destination(s)(PD)

The following rules specify the procedure for a
preempted destination. The PD is the connection recipient N_Port for a Class 1 or Class 6
connection.
a)

If a basic link service frame consisting of:

an PRMT command with:

an SOFn1 delimiter, and

an S_ID of the P and a D_ID of the

PD, and

an EOFdt delimiter

is received by a connection recipient N_

Port, that N_Ports Dedicated Connection
h a s b e e n r e mo v e d . Th i s P D N _ P o r t
should notify its host that its Dedicated
Connection has been preempted.

an SOFn1 delimiter, and

an EOFn, or EOFt delimiter

A dedicated connection is established with

the PS N_Port. The PnD N_Port(s) shall
be the Connection Recipient(s) and the PS
N_Port shall be the Connection Initiator.
d) If a PnD N_Port receives a preemption
request frame after it has transmitted a connection-request frame it should requeue its
own request for transmission at a later time
and respond with the proper response frame
to the PS N_port.
NOTE The preemption destination N_Port requeues its original connection-request because
the Fabric has discarded it. The PnD N_Port
needs to adjust its end-to-end Credit_CNT to account for the discarded connection-request.

If stacked connection-requests are being employed, the connection-request shall not be

requeued by the PnD N_Port.

28.9.3.4 Preemption Destination(s) (PnD)

28.9.4

The following rules specify the procedure for a

preemption destination (PnD). A PnD is any N_
Port, connected or not, that is addressed by the
D_ID in a SOFc1 preemption request frame.

Once a connection is established as a result of

a preemption request, all rules specified in FCPH or FC-PH-2 for normal Class 1 or Class 6
connections shall be followed.

a) If an SOFc1 preemption request frame is

received by an N_Port not connected, and
this N_Port is busy, the N_Port shall respond
with P_BSY with an EOFdt delimiter as specified in FC-PH clause 28.4.1.1 item e.
b) If an SOFc1 preemption request frame is
received by an N_Port not connected, and
this N_Port rejects the preemption request,
the N_Port shall respond with a P_RJT with
an EOFdt delimiter as specified in FC-PH
clause 28.4.1.1 item e.
c) If an SOFc1 preemption request frame is
received by an N_Port previously connected
(i.e., connected prior to being preempted) or
not connected and not busy, this N_Port shall
respond with the proper response frame. A
proper response frame shall be:

28.9.5

Connection Rules

Remove Connection Rules

All rules Specified in FC-PH or FC-PH-2 to remove Class 1 or Class 6 connections shall be
followed.
28.10 Establishing a Connection Using
Preemption
A Dedicated Connection is established between a preemption requesting (Connection Initiator) N_Port and preemption destination(s)
(Connection Recipient(s)) N_Port(s) following
the successful completion of the Preemption
process specified in sub-clause 28.9.
28.10.1

Connection Initiator

When the FC-2 protocol layer receives a request from an FC-4 or upper level to initiate a
Class 1 or Class 6 sequence using preemption,
the N_Port shall attempt to establish a Class 1
63

dpANS X3.xxx-199x

Table 111A Responses to Preemption Requests

Event

SOF

D_ID

S_ID

Frame

EOF

SOFc1

B, ...

Data
Frame

EOFn

- Transmit Preemption Request

- Wait for confirmation frame

SOFn1

F_RJT

EOFdt

- Preemption Failed. Fabric Rejected

request.

SOFn1

F_BSY

EOFdt

- Preemption Failed, Fabric Busy.

SOFn1

P_BSY

EOFdt

- Busy N_Port, Connection Removed.

SOFn1

P_RJT

EOFdt

- N_Port Rejected, Connection Removed.

SOFn1

ACK_1/
ACK_N/
ACK_0

EOFn/
EOFdt

- Dedicated connection Established

- Continue Transmitting Sequence
- Sequence/Connection Ended.

Any

Connect
Request
Frame

EOFn

- Requeue Preemption Request

Associated with Event 1.
- Respond with SOFn1 on ACK_1, ACK_
N, ACK_0, or P_BSY.

SOFc1

- Time-out, no response frame

- Perform Link Reset Protocol
(see FC-PH 16.6.5)

SOFn1

PS or
PD

PRMT

or Class 6 connection with the destination N_

Port(s) using an SOFc1 preemption request
frame (preemption flag set = 1) as part of a Sequence initiation.
The N_Port initiates a preemption request using
the rules defined in sub-clause 28.9
Table 111A defines event 1 as the preemption
request and events 2 through 8 as possible responses. Event 9 defines the response of the
preempted source or destination.
Event 1
A preemption Request is transmitted by N_Port
(A) with an SOFc1 delimiter with a destination
address of N_Port (B) and the preemption flag
set = 1 (word 4, bit 31).
Event 2
An F_RJT indicates that the Fabric is unable to
establish the Dedicated Connection or has re64

N_Port Action

EOFdt

- Dedicated Connection Preempted

- Notify Host, Preempted.

jected the request. A dedicated connection has

not been established. The reason code specifies the cause.
Event 3
An F_BSY indicates that the Fabric is busy and
was unable to service the preemption request.
A Dedicated connection has not been established.
Event 4
A P_BSY indicates that the destination N_Port
link facility is temporarily occupied with other
activities and is unable to accept the preemption request. Try again later.
Event 5
A P_RJT indicates that the destination N_Port
is unable to establish a Dedicated Connection.
The reason code specifies the cause.

dpANS X3.xxx-199x
Event 6

28.10.2

An ACK_1, ACK_N, or ACK_0 indicates that

the preemption request has been serviced and
a Dedicated connection has been established.
N_Port (A) is connected to N_Port (B).

If an SOFc1 preemption request frame is received by an N_Port previously connected (i.e.,

connected prior to being preempted), it shall
transmit the appropriate ACK frame (ACK_1 or
ACK_N) to the P N_Port. After the ACK frame
has been transmitted with the SOFn1, a Dedicated Connection is established with the P N_
Port as the Connection Initiator and this destination N_Port(s) as Connection Recipient(s).
After a Connection has been established, this
Destination N_Port may initiate Sequences with
the preemptor N_Port using an SOFi1 delimiter,
if the Connection is bi-directional (note: Class 6
dedicated connections are uni-directional).

a) N_Port (A) is the Connection Initiator and

N_Port (B) is the Connection Recipient.
b) N_Port (A) may continue transmitting the
Sequence initiated (EOFn), or the Sequence
which initiated the Connection may be complete (EOFt).
c) N_Port (A) may initiate other Sequences
with the same destination N_Port (B) up to
the maximum number of Sequences defined
by the Service Parameters obtained from (B)
during Login.
d) The connected N_Port (B) may initiate
Sequences using SOFi1 to start each Sequence when the Connection is bidirectional.
The number of active Sequences is limited by
the Service parameters provided by N_Port
(A) during Login.

Preemption Destination

When an un-connected N_Port receives a preemption request it shall respond normally for a
Class 1 connection request, as specified in FCPH 28.5.4.

Event 7
N_Port (A) shall requeue the SOFc1 sent to the
Fabric in Event 1 and may respond to the
SOFc1 received with and ACK_1, ACK_N,
ACK_0, or P_BSY. Once this connection is
completed N_Port (A) may re-send the SOFc1
preemption request frame to the Fabric.
Event 8
If a frame response is not received within the
time-out period (E_D_TOV), a link time-out
shall be detected and the Link Reset Protocol
shall be performed (see FC-PH 16.6.5)
See FC-PH 28.4.1 for the rules which a source
N_Port of a connect-request shall follow.
Event 9
When a connected source (i.e. Connection Initiator) or destination (connection recipient), receives a PRMT, the dedicated connection has
been preempted and no longer exists. The N_
Port should notify its host that the Sequence(s)
were abnormally terminated due to the connection being preempted.

dpANS X3.xxx-199x

Error detection and recovery

This clause describes the changes that are

made in FC-PH-3 to support the E_D_TOV timer resolution enhancement.
29.2.1.2 E_D_TOV
The following replaces the second paragraph of
this section in FC-PH.
When an N_Port performs N_Port Login in a
point-to-point topology, the Common Service
Parameters provided by each N_Port specify a
value for E_D_TOV. If the two values differ, the
longer time shall be used by each N_Port. An
N_Port may determine another N_Ports value
for E_D_TOV via the Read Timeout Value
(RTV) Link Service command (see 21.4.13).
Timeout values as specified in the Payload of
the Accept are counts of either 1 ms or 1 ns increments, depending on the resolution specified. Therefore, a value of hex 0000000A
specifies a time period of either 10 ms or 10 ns.
29.6

Exchange integrity

Process with infinite buffering

The Process with infinite buffering Error Policy
does not require that a Sequence be complete
or that any previous Sequences be deliverable.
Process policy allows an N_Port to utilize the
Data Field of invalid frames under certain restrictive conditions (see 17.8.1 and 17.8.2). The
Process with infinite buffering Error Policy is intended for applications such as a video frame
buffer in which loss of a single frame has minimal effect or no effect on the Sequence being
delivered. Frames shall be delivered to the FC4 or upper level in the same order as received.
The above shall also apply to Process with infinite buffering in Class 3.

dpANS X3.xxx-199x

Hunt Group

No enhancements from FC-PH or FC-PH-2.

dpANS X3.xxx-199x

Multicast

Enhancements to FC-PH-2 as specified.

31.1

Introduction

Multicast provides a service based on Fabric

routing of Class 3 or Class 6 frames. For a multicast connection the Fabric routes frames from
a source N_Port to many destination N_Ports.
31.2

Class 6 Multicast

Class 6 multicast provides a reliable service

based on Fabric routing of Class 6 frames. A
Class 6 SOFc1 is identical to a Class 1 SOFc1.
The Fabric recognizes the multicast D_ID and
performs the Class 6 multicast function, i.e., it
causes the frame to be delivered to every destination in the Multicast Group. A Multicast
Group is the set of N_Ports to which a frame
being multicast is delivered. An N_Port becomes a member of a Class 6 Multicast Group
when a dedicated connection is established between it and another N_Port. An N_Port is no
longer a member of a Class 6 Multicast Group
when the multicast connection is dissolved.
NOTE A system implementation may provide
less than reliable multicast service by implementing a single Sequence with infinite credit.

31.2.1

N_Port

Class 6 Multicast Routing

All routing of multicast frames is done by the

Fabric, based on the recognition that the D_ID
of the transmitted frame is a multicast address.
The exact frame that entered the Fabric is replicated to every destination N_Port indicated.
The Fabric shall not alter the frame header or
the frame contents in any manner during this
replication.
Figure 89a illustrates the multicast routing. N_
Port B, C, D and E are members of a Multicast
group. N_Port A is the message sender which
may or may not be a member of the group.

N_Port

Data
Fabric

N_Port

A
Ack

Multicast
Server

N_Port

E
Figure 89a Class 6 Multicast Routing
31.2.2

Class 6 Multicast Rules

a) The Sequence Initiator of the Multicast

message shall follow the uniqueness rules for
OX_ID, SEQ_ID, and Sequence Count. The
Sequence Initiator shall be the Connection
Initiator for all multicast sequences. RX_ID
for the Sequence shall be set to an appropriate value (established during Login) by the
multicast server.
b) D_ID in all frames shall address the multicast alias of the multicast group. S_ID in all
frames shall be the N_Port Identifier of the
Sequence Initiator.
c) The Fabric shall not alter the frame in
any way. The Fabric shall simply replicate
each frame to every group member.
d) Sequence Initiative shall not be transfered.
e) All Class 6 multicast frames shall be
routed as uni-directional Dedicated Connections, regardless of the state of the Simplex
bit in the CS_CTL Field (word 1 bit 31).

dpANS X3.xxx-199x
f) If any Multicast Group member is not able
to receive frames for any reason the Multicast Server shall respond to the connection
request with a P_RJT.
g) Class 1 service parameters, as specified
during Login, shall be used to manage Class
6 multicast connections.
h) The effect of preemption of one destination N_Port on the remaining N_Ports in the
multicast group is implementation-dependent.
31.2.3

Class 6 Multicast Server

To provide a single consistant response to the

requesting N_Port, all destination N_Port responses shall be managed by a multicast server (at well known address FFFFF5). Based
upon the type of responses returned from the
destination N_Ports (i.e. ACK, P_RJT, or P_
BUSY), the multicast server shall return a single, ACK, busy, or reject (with a valid reason
code) frame to the requesting N_Port as follows:
a) Respond with an ACK only if all destinations respond with an ACK before E_D_TOV
has expired since the sending of the last multicast Data frame.
b) Respond with a busy, with a partial multicast busy reason code (20.3.3.2), if one or
more destinations respond with a busy.
c) Respond with a reject, with a multicast
error reason code (20.3.3.3), if one or more
destinations respond with a reject, or not all
destinations have responded with an ACK
within E_D_TOV.
d) Respond with a reject, with an EOFdt
delimiter and a multicast error terminate
reason code (20.3.3.3), if one or more destinations respond with an ACK, BSY, or RJT
frame with an EOFdt delimiter.
e) Respond with a Link Reset (LR) if one or
more destinations respond with a Link Reset,
or if one or more, but not all, destinations respond with a Link Reset Response (LRR).
f) Respond with a Link Reset Response
(LRR) only if all destinations respond with an
LRR.

Once a Class 6 connection is established, endto-end credit is managed between the Connection Initiator and the multicast server.
31.2.4

Class 6 Multicast recovery

If the multicast Connection Initiator receives

from the Multicast Server a BSY or RJT, the
Connection Initiator shall perform a Link Reset.
If a RJT with an EOFdt delimiter is received,
the Connection Initiator shall terminate the multicast connection.
31.3

Class 3 Multicast

Class 3 multicast provides a service based on

Fabric routing of Class 3 frames. When the
Fabric receives a Class 3 frame that is to be
multicast, it causes the frame to be delivered to
every destination in the Multicast Group. A Multicast Group is a list of N_Ports to which a
frame being multicast is delivered. A Multicast
Group is managed by the Alias Server, which
handles the registration of N_Ports into a Multicast Group, and the de-registration of N_Ports
from a Multicast Group. The Alias Server is not
involved in the routing of multicast frames.
Class 3 multicast routing is specified in 31.3.2
in more detail.
31.3.1

Registration and De-registration

The registration/de-registration by an N_Port as

a member of a Multicast Group with the Alias
Server is specified in clause 32. An N_Port may
register itself as a member of one or more Multicast Groups. An N_Port may register a list of
N_Ports as members of one or more Multicast
Groups. The third party authorization for registration or de-registration is outside the scope of
the document.
31.3.2

Multicast Routing

All routing of multicast frames is done by the

Fabric, based on a recognition that the D_ID of
the transmitted frame is an MG_ID Alias. The
exact frame that entered the Fabric is replicated
to every destination N_Port in the Multicast
Group associated with the MG_ID of the frame.
The Fabric shall not alter the frame header or
the frame contents in any manner during this
replication.
The Sequence Initiator performs no special
function to transmit a frame to be multicast
other than use a D_ID indicating the MG_ID

dpANS X3.xxx-199x
and the Multicast Group Service Parameters,
rather than the Login Service Parameters. For
example, the Receive Data Field Size for a multicast frame may be different than the Receive
Data Field Size for a unicast frame.

be the N_Port Identifier of the Sequence Initiator.

c) The Fabric shall not alter the frame in
any way.The Fabric shall simply replicate
each frame to every group member.

If the Sequence Recipient is a member of a

Multicast Group, it shall recognize the MG_ID
as an Alias and accept the frame.

d) Sequence Initiative shall not be transfered.

Class1, Class 2, and Class 4 frames with a

D_ID equal to an MG_ID shall be rejected by
the Fabric.

e) If any group member is not powered on

nor able to receive the frame for any other
reason, the Fabric Controller shall not retransmit the frames.

Figure 89b illustrates the multicast routing. N_

Port B, C, D, and E are members of a Multicast
Group. N_Port A is the message sender which
may not be a member of the group. If it is a
member, it may optionally receive the same
message (see FC-GS.).

N_Port

C
N_Port

Fabric

A
N_Port

f) All multicast frames shall be routed in

Class 3.
31.4

Broadcast is considered a simplification of

mu ltic a st. N o e x plic it r e g ist ra tio n o r d e registration is required. Hex FFFFFF is the
Well-known address for Broadcast which may
be recognized by an N_Port.
NOTE .The Fabric may try to send to all possible
N_Ports. However, the Fabric may not be able to
deliver to all N_Ports for any number of reasons
such as Class mismatch and N_Port not powered
on.

The Broadcast Service Parameters shall be

defined. All N_Ports that support the Broadcast
shall support the Broadcast Service Parameters.
NOTE The Broadcast Service Parameters shall
be the least common denominator for all N_Ports.
Normally the Broadcast Service Parameters may
correspond to the default parameters.

31.5
N_Port

E
Figure 89b Class 3 Multicast Routing
31.3.3

Class 3 Multicast rules

a) The Sequence Initiator of the Multicast

message shall follow the uniqueness rules for
OX_ID, SEQ_ID, and Sequence Count. RX_
ID for the Sequence shall be set to hex
FFFF.
b) D_ID in all frames shall be the Alias for
the Multicast Group. S_ID in all frames shall

Broadcast

Moviecast

Moviecast is an inherent feature of Multicast.

An example for Class 3 Multicast: if a source
N_Port is multicasting a movie to an Alias
Group, another N_Port may join this Alias
Group in progress. That is, after the registration procedure is complete, the Fabric will start
routing frames to the new N_Port. This is possible with Class 3 Multicast since a multicast
group can be destination initiated. For a Class 6
Multicast the multicast group is source initiated
and does not provide the direct capability for an
N_Port to join a Multicast group in progress. If
intermix is supported an N_Port could request
inclusion in a multicast group using a Class 2 or
Class 3 frame, supporting an indirect destination initiated multicast group.

dpANS X3.xxx-199x
31.6

Other

Other forms of multicast are available in topology specific configurations. For examples, see
FC-AL for a description of Selective Replicate
to perform dynamic multicasting.

dpANS X3.xxx-199x

Aliases

No enhancements from FC-PH or FC-PH-2.

Dedicated Simplex

No enhancements from FC-PH or FC-PH-2.

Class 4- Fractional

No enhancements from FC-PH or FC-PH-2.

Camp-On

No enhancements from FC-PH or FC-PH-2.

Stacked Connect Request

No enhancements from FC-PH or FC-PH-2.

Buffered Class 1 Service

No enhancements from FC-PH or FC-PH-2.

Data Compression

No enhancements from FC-PH or FC-PH-2.

dpANS X3.xxx-199x

Clock synchronization service

39.1
39.1.1

Introduction
Applicability

Conventional network technologies utilize clock

distribution protocols (e.g. Network Time Protocol) which synchronize the computers time-ofday clock. Such protocols typically provide
clock synchronization accuracies on the order
of a few millisecond with highly tuned versions
producing accuracies on the order of 50 microseconds.
The synchronization that naturally occurs between transmitters and receivers in a Fibre
Channel fabric offers a highly accurate reference for maintaining clock synchronization. If
all delays are accounted, accuracies on the order of a few nanosecond become practical. The
protocols defined in this clause allow clocks located within N_Ports to be synchronized to
nanosecond accuracies.
39.1.2

Function

Clock Synchronization over Fibre Channel is attained by having a Clock Synchronization Server exchange clock synchronization symbols
with Clients on a periodic basis determined by
its reference clock. (Clock synchronization symbols can be either primitive sequences or ELS.)
The Server can be either built into a fabric servicing multiple F_Ports or an independent node
servicing one or more N_Ports. The Client can
be either an N_Port or a F_Port (when synchronizing other sub-fabrics). Embedded within
each clock synchronization symbol is a delay
field (measured in clock ticks) for use in the calculation of the one-way propagation delay from
the Server ports transmitter to the Client ports
receiver.
NOTE The round-trip propagation delay is used
to compute the one-way propagation delay. For
best accuracies, the transmit and receive paths
between Servers port and the Client port must be
equal in length.

When all of the Clients are requested with the

Server, they will themselves be synchronized.
By tagging data with the current value of their
synchronization clock, one client can accurately
exchange time sensitive data with another client.

39.2

Communications Model

Figure 114 illustrates the clock synchronization

protocol that occurs between the Server and
Client port in order for their respective clocks to
be synchronized. Periodically the Servers reference clock will generate a synchronization
event (t1). The synchronization event will cause
the exchange of clock synchronization request/accept symbols with one or more Clients.
(The period of the synchronization event is controlled by the Server.) Embedded within the
clock synchronization symbols is the necessary
data to compute the delays between the sender
and receiver.
Figure 114 Clock Synchronization Model
Server

Client

sync
_
(ser clock_re
ver_
dela quest
y)
t3

ept
_acc
k
c
o
l
_c
ay)
sync lient_del
(c
t5

where (t3-t2) = (t5-t4)

The synchronization event (t 1) eventually results in the transmission of a clock synchronization request symbol to the Client port at time
(t2). Initially, the delay between the synchronization event and when the synchronization
event is actually sent (t2 - t1) is embedded into
the delay field of the synchronization symbol
(server_delay).
When the Client port receives a clock synchronization request symbol (t3), it sets its synchronization clock to the value embedded in the
delay field of the request symbol (t2 - t1). It then
initiates a clock synchronization accept symbol
to the Server (t 4). Embedded in the clock synchronization accept symbol (client_delay) is the
delay from when the request symbol was re73

dpANS X3.xxx-199x
ceived to when the clock synchronization accept
symbol is returned (t4 - t3).
When the Servers port receives the clock synchronization accept symbol from the Client port,
it takes the difference (t5 - t2) between when it
sent the clock synchronization symbol (t2) and
when it received the accept (t5). The Server then
computes the total propagation delay ((t5 - t4) (t3 - t2)) by subtracting the accept delay (t4 - t3)
from (t5 - t2). The one way propagation delay (t3
- t2) is then computed by dividing the total propagation time by two (assuming the transmit and
receive propagation delays are equal).
The above process is then repeated. On subsequent synchronization events, the Server adds
the one-way propagation delay (t3 - t2) to the delay between the synchronization event and req uest transmission (t 2 - t 1 ). The resu ltin g
embedded delay is the difference between the
Clients synchronization clock and Servers synchronization clock (t 3 - t 1 ). By setting its synchronization clock to the value embedded within
the clock synchronization request symbol (t 3 t1), the Clients clock will be synchronized to the
Servers clock.
NOTE From this point on, as long as the Servers
transmitter port is connected to the Clients receiver
port, the synchronization clocks in the client and
server should be synchronized.

39.3

Requirements

The Clock Synchronization Server shall have a

clock reference that operates at the speed of the
N_Ports being served. The Server shall provide
clock synchronization service to one or more Client Ports. Each Client/Server pair must operate
with common speeds and classes of service.
(The Clients themselves can operate at different
speeds and classes of service.) The Server
shall send a clock synchronization request symbol on a periodic basis to all Clients being
served. The Client port being synchronized shall
respond by returning a clock synchronization accept symbol.
Clients can determine the synchronization period by sending an Extended Link Service request
to the Server. The synchronization count (sync
count) in the Accept Payload (see 39.4.3.1) indicates the synchronization period. The synchronization count is measured in transceiver clock
ticks. Clients operating at different speeds will
have different synchronization counts.

The Server shall increment a 32-bit reference

clock register (reference_clock) at the rate of the
clock reference. The reference clock is used to
determine the synchronization period for all Clients (sync_count).
The Servers clock reference shall also be used
as a reference for all N_Port transmitters being
serviced. Each of these N_Ports shall have a
28-bit delay register (server(n)_delay) which increments at the rate of the ports transmitter.
The Server shall also have a 28-bit register for
each Client to save the computed propagation
delay (propagation(n)_delay).
The Clients shall have a set of registers including a 32-bit register for the synchronization clock
(client_clock) and a 28-bit register for Client delays (client_delay) both incremented at the rate
of the Client ports receiver. Clients shall also
have a 32-bit register with their synchronization
count (sync(n)_count).
39.3.1

Server Rules

The following statements illustrate the Servers

reference clock and synchronization clock logic:
if servers clock reference ticks then
reference_clock = reference_clock + 1
if reference_clock = sync_count then (t1)
server(n)_sync = true
server(n)_delay =0
if N_Port (n)s transmitter ticks
server(n)_delay = server(n)_delay + 1
The following logic statements illustrate the
clock synchronization protocol for a Server.
These statements shall apply for all (n) Clients:
if (server(n)_sync is true) and (port(n) is idle)
then (t2)
server(n)_sync = false
send_symbol (sc_request,
server(n)_delay + propagation(n)_delay)
server(n)_delay = 0
if receive_symbol (symbol, symbol_data) then
if (symbol = sc_accept) then (t5)
client_delay = symbol_data
propagation(n)_delay =
(server(n)_delay - client_delay)/2
39.3.2

Client Rules

The following statements illustrate the Clients

clock synchronization logic:

dpANS X3.xxx-199x
if clients receiver clock ticks then
client_clock = client_clock + 1
client_delay = client_delay + 1
if client_clock = sync(n)_count then
client_clock = 0
The following logic statements illustrate the
clock synchronization protocol for a Client:
if receive_symbol (symbol, symbol_data) then
if (symbol is sc_request) then (t3)
client_clock = symbol_data
client_delay = 0
client_sync = true
if (client_sync is true) and (port is idle) then (t4)
client_sync = false
send_symbol (sc_accept, client_delay)
39.4

Clock Synchronization Control

Servicing of a Client ports synchronization clock

is controlled through protocols containing a set
of request/reply IUs supported by the Server.
These requests and replies use FC-PH constructs as defined in the following sections.
39.4.1

Use of FC-PH Constructs

39.4.1.1 Login/Logout
Before performing any clock synchronization operations, a Client port shall perform F_Port Login followed by N_Port Login with the Clock
Synchronization Server. When the Client port
has no further operations pending, it shall perform N_Port Logout with the Server.
39.4.1.1.1 Initiator Capability
To the Initiator Control Flags (D) specified in FCPH 23.6.8.3, additional flags are specified in FCPH-2 (see 23.6.8.3).
The clock synchronozation capability is indicated by the Sequence Initiator (Clock Synchroniztion Server) during N_Port Login in word 0, bit 4
of N_Port Class service parameters under Initiator Control.

bit 19 of N_Port Class service parameters under

Recipient Control.
39.4.1.2 Exchanges
Clock synchronization Exchanges shall be used
in a bidirectional manner. That is, clock synchronization Service request IUs and accept IUs
shall be transferred on the same Exchange, via
the passing of Sequence initiative.
39.4.1.3 Information Units
The Information Unit construct defines the information transferred as a single Fibre Channel
Sequence for clock synchronization requests
and replies. A single Information Unit contains
either a clock synchronization request or a reply.
All communication occurs through the Exchange
of Information Units. This clause describes both
the data which are transparent to FC-PH-3 and
those control parameters which are required by
FC-PH-3.
39.4.1.4 Common Required FC Parameters
Class of Service
The Server shall support all Classes of Service
supported by the Fabric Region to which it is attached. See FC-SW for a discussion of Regions.
An Client port may communicate with the Server
using any desired Class.
If the Client port or the Servers port uses Class
3 to communicate, it shall provide the
Sequence_Tag on the FC_PH service interface.
Any Sequence_Tag provided on a given IU shall
not be reused on a subsequent IU associated
with the same Exchange until either of the following conditions exists:
R_A_TOV has expired since the Client
port or the Servers port has determined that
the IU has been transmitted by the FC-2.
The Client port or the Servers port receives a accept to the transmitted IU from the
receiver of the IU.

39.4.1.1.2 Recipient Capability

To the Recipient Control Flags (D) specified in
FC-PH 23.6.8.4, additional flags are specified in
FC-PH-2 (see 23.6.8.4).

R_CTL Routing Bits

Routing bits of the R_CTL field shall indicate
FC-4 Device Data.

The clock synchronozation capability is indicated by the Sequence Recipient (Clock Synchroniztion Server) during N_Port Login in word 0,

dpANS X3.xxx-199x
Information Category

39.4.1.6 CT_HDR

A ll R e qu e st I Us sh a ll s pe cify U ns olicite d
Control. All Accept IUs shall specify Solicited
Control.

The CT_HDR, as defined in FC-GS, shall be

supported by the Server. That is, all requests
and replies shall contain the CT_HDR. Following is a description of the usage of the various
CT_HDR fields.

Sequence Initiative
Sequence Initiative shall be transferred after the
transmission of the Request IU, to allow the return of the associated Reply IU (FS_ACC or FS_
RJT) on the same Exchange. If Sequence Initiative is not passed on the Request IU, The Recipient shall abort the Exchange.

Revision
This field shall be set to hex 01.
IN_ID
This field shall be ignored by the Server.

Destination ID (D_ID)

FCS_Type

This parameter shall identify the destination address identifier (hex FFFFF6 if the well known
address for the clock synchronization service is
being used) of the IU.

This field shall be set to hex F6.

Source ID (S_ID)

Application Information Unit

This parameter shall identify the source address

identifier of the IU.

This field shall contain the payload of the a single request or reply.

Type

39.4.2

All clock synchronization IUs shall specify the Fibre Channel Services TYPE (b0010 0000).

A clock synchronization Client (Sequence Initiator) shall transmit a clock synchronization Request to solicit the Server to perform a control
function. If the request is transmitted without the
transfer of Sequence Initiative, the responding
port shall abort the Exchange and not perform
the Request. The clock synchronization Protocol
is composed of a clock synchronization Request, followed by a reply, on the same Exchange.

Error Policy
All error policies, with the exception of Process
Policy, are permitted.
39.4.1.5 Common Optional FC Parameters
Expiration/Security Header
The use of this parameter is beyond the scope
of this document and is both implementation
and system dependent.
Network Header
The use of this parameter is beyond the scope
of this document and is both implementation
and system dependent.
Association Header
The use of this parameter is beyond the scope
of this document and is both implementation
and system dependent.
Device Header
The Device Header shall not be used.

Options
This field shall be set to hex 00.

Clock Control Request

The clock synchronization control request provides the means to enable and disable the clock
synchronization service to the Clock Synchronization Client. For the above Request, if an FS_
RJT is generated, it shall specify a Reason
Code of Unable to perform command request,
unless otherwise indicated. The Reason Code
Explanation shall indicate the specific reason for
the FS_RJT.
39.4.3

Clock Control Link Service

In order for the clock synchronization service to

be established, a Client port, as the Exchange
Originator, shall send a FC-4 link service request to the Server. The accept to the request
shall indicate the period at which the Clients
clock will be synchronized.

dpANS X3.xxx-199x
39.4.3.1 Clock Control (CSS_CC)
The clock control sequence shall be used by a
Client port to determine the clock synchronization services provided by the Server and to control the synchronization clock. The format of the
request payload is shown in table 167.
Table 167 CSS_CC Payload
Item

Size (Bytes)

hex 01000000

command

command: This field controls clock synchronization service to the Client. A value of zero (0)
indicates the Server shall disable clock synchronization off; a value of one (1) indicates that the
Server shall enable clock synchronization using
primitive sequences; a value of two (2) indicates
that the Server shall enable clock synchronization using ELS sequences; and a value of three
(3) indicates the Server shall report its current
state.
Fibre Channel service reject (FS_RJT) signifies
rejection of the CSS_CC command.
Fibre Channel service accept (FS_ACC) signifies the clock synchronization service has transmitted the clock synchronization information.
The format of the accept payload is shown in table 168.
Table 168 CSS_CC Accept Payload
Field

Size (Bytes)

hex 02000000

synchronization_count

state

capability

synchronization_count: This field is an integer

value which defines the number of synchronization clock ticks in millions (x10 6) between clock
synchronization request symbols.

two (2) indicates that clock synchronization is

enabled using ELS sequences.
capability: This field reports the clock synchronization capability of the Server. A value of zero
(0) indicates the Server supports primitive sequences; a value of one (2) indicates the Server
supports ELS primitive sequences; and a value
of three (3) indicates support for both.
39.5

Synchronize Clock Request

Either a series of Primitive Signals or ELS service can be used as clock synchronization symbols. Primitive Signals can only occur between
frames. Whether ELS or Primitive Signals are
being used, synchronize clock symbols must be
delayed if the Server or Client port is in the process of transmitting a frame.
NOTE Highest clock synchronization accuracies occur when clock synchronization primitives
are used with Class 1 service and a fabric based
Server w hose transmitters are referenced to a
common clock source.

39.5.1

Primitive Signal Service

Primitive Signals can be used to issue clock

synchronization requests and accepts. When
the Servers port is connected to the Client port
over a point-to-point connection, the use of
clock synchronization Primitive Signals can provide higher clock accuracies than are possible
with ELS sequences.
39.5.1.1 Terms
The clock synchronization signals for the clock
synchronization Primitive Signals consist of the
following ordered sets:
SYNx - K28.5, D31.3, CS_X, CS_X
SYNy - K28.5, D31.5, CS_Y, CS_Y
SYNz - K28.5, D31.6, CS_Z, CS_Z

The 14-bit value (hex) contained within a clock

synchronization signal (x, y, or z) is the concatenation of two 7-bit hexadecimal values (X and
X; Y and Y; Z and Z respectively). As defined
in Annex K of FC-AL, each 7-bit value has an
equivalent neutral disparity Data Character as illustrated in table 169.

state: This field reports the current clock synchronization state. A value of zero (0) indicates
clock synchronization is disabled; a value of one
(1) indicates that clock synchronization is enabled using primitive sequences; and a value of

dpANS X3.xxx-199x
Table 169 Data Character Translation
Value
Data
(hex) Character

Value
Data
(hex) Character

CS_X

CS_Y

CS_Z

39.5.1.2 Synchronize Clock Request

The synchronize clock request sequence consists of the following primitive signals: (2) Idles;
(1) SYNx; (1) SYNy; and (2) Idles.
The concatenation of the binary data fields from
the synchronize clock signals (SYNx and SYNy)
produce a 28-bit field (xy) which contains the binary value of the Server ports server_delay
(see Figure 114).
39.5.1.3 Synchronize Clock Accept
The synchronize clock accept sequence consists of the following primitive signals: (2) Idles;
(1) SYNx; (1) SYNz; and (2) Idles.
The concatenation of the binary data fields from
the synchronize clock signals (SYNx and SYNz)
produce a 28-bit field (xz) which contains thebinary value of the Client ports client_delay (see
Figure 114).

Destination ID (D_ID)
This parameter shall identify the destination address identifier of the IU for the Client port being
synchronized.
Source ID (S_ID)
This parameter shall identify the source address
identifier of the IU (hex FFFFF6 if the well
known address for the clock synchronization
Server is being used).
The Server (Sequence Initiator) shall transmit a
clock synchronization Request to solicit a participating clock synchronization port to perform a
service function. If the request is transmitted
without the transfer of Sequence Initiative, the
responding port shall abort the Exchange and
not perform the Request. The clock synchronization Protocol is composed of a clock synchronization Request, followed by a reply, on the
same Exchange.
The Synchronize Clock request provides the
means for the Server to synchronize clock synchronization Clients. For the above Request, if
an FS_RJT is generated, it shall specify a Reason Code of Unable to perform command request, unless otherwise indicated. The Reason
Code Explanation shall indicate the specific reason for the FS_RJT.
39.5.2.1 Synchronize Clock Link Service

39.5.1.4 Primitive Signal Insertion

When sending a synchronize clock request symbol, the Server will use the synchronize clock request sequence to substitute the sequence of
idles that normally occurs between frames. Likewise when sending a synchronize clock accept
symbol, the Client port will use the synchronize
clock accept sequence to substitute the sequence of idles.
39.5.2

ELS Service

When using ELS service, The Server, as the Exchange Originator, shall issue Synchronize
Clock Requests with the use of FC_PH constructs. With the exception of the Source and
Destination identifiers described below, subclause 39.4.1 describes the use of FC_PH constructs.

The Server shall synchronize the Client ports

clock at a rate that is no greater than the indicated synchronization_count. Clock synchronization events are generated periodically by the
Server. The Client can anticipate the synchronization ELSs at a rate no greater than that indicated in the synchronization count.
39.5.2.2 Synchronize Clock (CSS_SC)
The synchronize clock command shall be issued
by the Server to synchronize the clock of the Client port. The format of the request payload is
shown in table 170.
Table 170 CSS_SC Payload
Item

Size (Bytes)

hex 03000000

server_delay

dpANS X3.xxx-199x
server_delay: The unsigned sum of: (1) the
number of clock ticks between when the clock
synchronization event occurred and when the
ELS is transmitted; (2) the number of clock ticks
for the one-way propagation delay from the
Server to the Client port.
Fibre Channel service reject (FS_RJT) signifies
rejection of the CSS_SC command.
Fibre Channel accept (FS_ACC) signals a reply
from the Client port being synchronized was
transmitted with synchronization information to
the clock synchronization Server. The format of
the accept payload is shown in table 171.
Table 171 CSS_SC Accept Payload
Field

Size (Bytes)

hex 04000000

client_delay

client_delay: The unsigned number of clock

ticks that occurred between when the Client port
received the clock synchronization request and
when the Client port transmitted the clock synchronization accept.

dpANS X3.xxx-199x

Data Encryption

This clause describes and formally defines the

data encryption method and format. The encryption algorithm should be designed for fast
bulk encryption. However, a specific algorithm
is beyond the scope of this document (see Annex A of FC-GS-2). FC-GS-2 (Security key distribution service) defines the mechanism by
which encryption keys with different lengths are
distributed. The encryption algorithm should be
a variable-key-size cipher function which suppors multiple key lengths if export versions of
products is required.
40.1

Introduction

The Data Encryption option can be invoked by

the initiator on a per Information Category basis
within a Sequence, immediately preceding segmentatio n to fra me Pa yload s. De cryp tion
should be performed immediately following Information Category reassembly.
40.2

N_Port Login

The Sequence Initiators capability to perform

data encryption and the Sequence Recipients
capability to perform decryption are determined
during N_Port login.
Only if both Sequence Initiator and the Sequence Recipient support the capability can
they perform the function.
40.2.1

Initiator Capability

40.2.3

F_CTL

Data encryption status of an Information Category shall be indicated by the Sequence Iniator
to the Sequence Recipient by means of F_CTL
bit 10 (see 18.5)
40.3

Applicability

Frame level encryption is applicable to all

Classes of service. Data encryption status (F_
CTL bit 10) is meaningful in all Data frames of
an Information Category.
NOTE F_CTL bit is defined to be meaningful in
all data frames to ensure that the Sequence Recipient recognizes encrypted data with RO usage and
out-of-order frame delivery.

40.4

Decryption

The Sequence Recipient shall decrypt data on

a per Information Category basis, using Information Category bits of R_CTL and the SEQ_
ID of the Sequence to which the Information
Category belongs.
Since the Data encryption is performed on a per
Information Category basis (not on frame by
frame basis), the RO shall not be used with
Data encryption. If the Sequence Recipient
uses RO and transmits compressed data, the
Sequence Recipient shall ignore the RO and
decrypt the data for the entire Information Category.

To the Initiator Control Flags (D) specified in

FC-PH 23.6.8.3, additional flags are specified in
FC-PH-2 (see 23.6.8.3).
The data encryption capability is indicated by
the Sequence Initiator during N_Port Login in
word 0, bit 5 of N_Port Class service Parameters under Initiator Control.
40.2.2

Recipient Capability

To the Recipient Control Flags (D) specified in

FC-PH 23.6.8.4, additional flags are specified in
FC-PH-2 (see 23.6.8.4).
The data encryption capability is indicated by
the Sequence Recipient during N_Port Login in
word 1, bit 20 of N_Port Class service Parameters under Recipient Control.

dpANS X3.xxx-199x
A

Annex A
(informative)
No enhancements to X3.230-1994 (FC-PH) annex A.
B

Annex B
(informative)
No enhancements to X3.230-1994 (FC-PH) annex B.
C

Annex C
(informative)
No enhancements to X3.230-1994 (FC-PH) annex C.
D

Annex D
(informative)
No enhancements to X3.230-1994 (FC-PH) annex D.
E

Annex E
(informative)
No enhancements to X3.230-1994 (FC-PH) annex E.

dpANS X3.xxx-199x
F

Annex F
(informative)
Electrical cable interface implementation examples
NOTE The cable descriptions listed in this annex replace the cable descriptions present in the equivalent annex in ANSI X3.230-1994. All other portions of the ANSI X3.230 annex remain in effect.

F.1

Example of LV (long-video) coaxial cable characteristics

This large diameter style of coax is capable of relativly long distance transmission due to its low attenuation. Electrical and mechanical characteristics of a cable meeting the requirements of LV links is
listed in table F.1. This cable is equivalent to a type-1694A version of RG-6/U.
Table F.1 Typical characteristics of LV-type coaxial cable
Category
Electrical

Impedance
see 9.1.1

Capacitance
53,1 pF/m nom.

Attenuation
see 9.1.1

Velocity
82%

Category
Conductor

Material
Bare Copper

Size
AWG 18

Construction
Solid

Outer diameter
1,02 mm nom.

Category
Dielectric

Material
Foam Polyethylene

Wall thickness
1,78 mm nom.

Dielectric constant
1,50 nom.

Outer diameter
4,57 mm nom.

Category
Shield

Material
Tin plated Cu braid
over foil

Coverage
Braid 95%
Foil 100%

Outer diameter
----------

Category
Jacket

Material
PVC

Colour
----------

Outer diameter
6,99 mm nom.

F.2

Wall thickness
----------

Example of plenum-rated LV (long-video) coaxial cable characteristics

This large diameter style of coax is capable of relativly long distance transmission due to its low attenuation. Electrical and mechanical characteristics of a cable meeting the requirements of plenum
rated LV links is listed in table F.1. This cable is equivalent to a type-1695A version of RG-6/U.
Table F.2 Typical characteristics of plenum rated LV-type coaxial cable
Category
Electrical

Impedance
see 9.1.1

Capacitance
53,1 pF/m nom.

Attenuation
see 9.1.1

Velocity
83%

Category
Conductor

Material
Bare Copper

Size
AWG 18

Construction
Solid

Outer diameter
1,02 mm nom.

Category
Dielectric

Material
Foamed Teflon

Wall thickness
1,65 mm nom.

Dielectric constant
1,50 nom.

Outer diameter
4,32 mm nom.

Category
Shield

Material
Tin plated Cu braid
over foil

Coverage
Braid 95%
Foil 100%

Outer diameter
----------

Category
Jacket

Material
Chloride-based or
Florocopolymer

Colour
----------

Outer diameter
5,94 mm nom.

Wall thickness
----------

dpANS X3.xxx-199x

F.3

Example of TV (video) coaxial cable characteristics

This intermediate diameter style of coax is capable of medium distance transmission due to its low attenuation. Electrical and mechanical characteristics of a cable meeting the requirements of TV-type
links is listed in table F.1. This cable is equivalent to a type-1505A version of RG-59/U.
Table F.3 Typical characteristics of TV-type coaxial cable
Category
Electrical

Impedance
see 9.1.2

Capacitance
53,1 pF/m nom.

Attenuation
see 9.1.2

Velocity
83%

Category
Conductor

Material
Bare Copper

Size
AWG 20

Construction
Solid

Outer diameter
0,81 mm nom.

Category
Dielectric

Material
Foam Polyethylene

Wall thickness
1,43 mm nom.

Dielectric constant
1,50 nom.

Outer diameter
3,68mm nom.

Category
Shield

Material
Tin plated Cu braid
over foil

Coverage
Braid 95%
Foil 100%

Outer diameter
----------

Category
Jacket

Material
PVC

Colour
----------

Outer diameter
5,97 mm nom.

F.4

Wall thickness
----------

Example of plenum-rated TV (video) coaxial cable characteristics

This intermediate diameter style of coax is capable of medium distance transmission due to its low attenuation. Electrical and mechanical characteristics of a cable meeting the requirements of plenum
rated LV-type links is listed in table F.1. This cable is equivalent to a type-1506A version of RG-59/U.
Table F.4 Typical characteristics of plenum rated TV-type coaxial cable
Category
Electrical

Impedance
see 9.1.2

Capacitance
52,8 pF/m nom.

Attenuation
see 9.1.2

Velocity
83%

Category
Conductor

Material
Bare Copper

Size
AWG 20

Construction
Solid

Outer diameter
0,81 mm nom.

Category
Dielectric

Material
Wall thickness
Foamed FEP Teflon 1,31 mm nom.

Dielectric constant
1,50 nom.

Outer diameter
3,68 mm nom.

Category
Shield

Material
Tin plated Cu braid
over foil

Coverage
Braid 95%
Foil 100%

Outer diameter
----------

Category
Jacket

Material
Chloride-based or
Florocopolymer

Colour
----------

Outer diameter
5,05 mm nom.

F.5

Wall thickness
----------

Example of plenum-rated MI (minitaure) coaxial cable characteristics

The attenuation of miniature coaxial cabe is significantly more lossy than either the LV or TV styles of
coax. Its usage is limited to short connections between pieves of equipment. Electrical and mechanical characteristics of a cable meeting the requirements of plenum rated MI-type links is listed in table
F.1. This cable is equivalent to a type-83264 version of RG-179.

dpANS X3.xxx-199x
Table F.5 Typical characteristics of plenum rated MI-type coaxial cable
Category
Electrical

Impedance
see 9.1.3

Capacitance
64,0 pF/m nom.

Attenuation
see 9.1.3

Velocity
69,5%

Category
Conductor

Material
Silver coated
Copper covered
Steel

Size
AWG 30

Construction
Stranded

Outer diameter
0,30 mm nom.

Category
Dielectric

Material
Teflon

Wall thickness
0,64 mm nom.

Dielectric constant
----------

Outer diameter
3,68 mm nom.

Category
Shield

Material
Silver coated
Cu braid

Coverage
Braid 95%

Outer diameter
----------

Category
Jacket

Material
Teflon

Colour
----------

Outer diameter
2,54 mm nom.

F.6

Wall thickness
----------

Example of STP cable characteristics

This cable should be compatable with existing Type-1A and Type-2A 150 STP cable. Electrical
and mechanical characteristics of a cable meeting the requirements of TP links is listed in table F.1.
This cable is equivalent to a type-9688 version of Type-1A STP.
Table F.6 Typical characteristics of TP-type cable
Category
Electrical

Impedance
see 9.2.1

Capacitance
27,9 pF/m nom.

Attenuation
see 9.2.1

Velocity
69,5%

Category
Conductor

Material
Bare Copper

Size
AWG 22

Construction
Solid

Outer diameter
0,65 mm nom.

Category
Dielectric

Material
Foamed
Polyethylene

Wall thickness
----------

Dielectric constant
----------

Outer diameter
----------

Category
Shield

Material
Metalized Foil with
tinned Cu braid

Coverage
Foil 100%
Braid 65%

Outer diameter
----------

Category
Jacket

Material
PVC

Colour
Black

Outer diameter
7.5mm x 10.9mm
nom.

Wall thickness
----------

dpANS X3.xxx-199x

F.7

Example of TW cable characteristics

This cable should be used in skew sensitive environments, or where overall cable size is a factor.
Electrical and mechanical characteristics of a cable meeting the requirements of TW-type links is listed in table F.1.
Table F.7 Typical characteristics of TW-type cable
Category
Electrical

Impedance
see 9.2.2

Capacitance
----------

Attenuation
see 9.2.2

Velocity
83%

Category
Conductor

Material
Tin or Silver plated
Copper

Size
22 AWG

Construction
Stranded or solid

Outer diameter
----------

Category
Dielectric

Material
various

Wall thickness
----------

Dielectric constant
----------

Outer diameter
----------

Category
Shield

Material
Metalized foil and
Cu braid

Coverage
Foil 100%
Braid 85%

Outer diameter
----------

Category
Jacket

Material
various

Colour
----------

Outer diameter
----------

Wall thickness
----------

dpANS X3.xxx-199x
G

Annex G
(informative)
No enhancements to X3.230-1994 (FC-PH) annex G.
H

Annex H
(informative)
No enhancements to X3.230-1994 (FC-PH) annex H.
I

Annex I
(informative)
No enhancements to X3.230-1994 (FC-PH) annex I.
J

Annex J
(informative)
No enhancements to X3.230-1994 (FC-PH) annex J.

Annex K
(informative)
No enhancements to X3.230-1994 (FC-PH) annex K.
L

Annex L
(informative)
No enhancements to X3.230-1994 (FC-PH) annex L.
M

Annex M
(informative)
No enhancements to X3.230-1994 (FC-PH) annex M.
N

Annex N
(informative)
No enhancements to X3.230-1994 (FC-PH) annex N.
O

Annex O
(informative)
No enhancements to X3.230-1994 (FC-PH) annex O.
P

Annex P
(informative)
No enhancements to X3.230-1994 (FC-PH) annex P.

dpANS X3.xxx-199x
Q

Annex Q
(informative)
No enhancements to X3.230-1994 (FC-PH) annex Q.
R

Annex R
(informative)
No enhancements to X3.230-1994 (FC-PH) annex R.

dpANS X3.xxx-199x
S

Annex S
(informative)
FC-PH Service Interface
This annex describes changes to the FLOGI
and PLOGI service interface.
S.2.3

FABRIC_LOGIN.request

This primitive is used to provide Fabric Login

parameters and to request a login with the Fabric, if necessary.
S.2.3.1 Semantics of the Primitive
FABRIC_LOGIN.request
(My_ID,
Local_N_Port,
My_Fabric_Service_Parameters)
My_ID will specify the S_ID to be used in the
Sequence that delivers the Fabric Login. See
23.3.1 for the usage of the S_ID in Fabric Login.
Local_N_Port will specify the local N_Port
which is to issue the FLOGI.
My_Fabric_Service_Parameters will optionally
specify the parameters to be used in the payload of the Fabric Login.
S.2.3.2 When Generated
A level above FC-PH will generate this primitive
to provide operating parameters to FC-PH and
to request a Fabric Login.
S.2.3.3 Effect of Receipt
If the N_Port specified by My_ID is not currently
logged into the Fabric, the receipt of this primitive will cause FC-PH to attempt Link Initialization (see 16.6.2) if the Link is not active and to
transmit a Fabric Login Sequence with Class as
specified by 23.3.3.
If the N_Port specified by My_ID is currently
logged into the Fabric, the receipt of this primitive will cause FC-PH to return the current Fabric Service Pa ra me ters, via the FABRIC_
LOGIN.confirmation. Link Initialization is not
performed and a Fabric Login Sequence is not
transmitted. However, the N_Port may issue an
FDISC ELS to obtain the most current Fabric
Login parameters.

S.2.4

FABRIC_LOGIN.indication

No change from FC-PH.

S.2.5

FABRIC_LOGIN.confirmation

This primitive will provide an appropriate response to the FABRIC_LOGIN.request primitive signifying the success of the primitive and,
if a Fabric is present, will provide the Service
Parameters returned by the Fabric.
S.2.5.1 Semantics of the Primitive
FABRIC_LOGIN.confirmation
(My_ID,
Local_N_Port,
Request_Status,
Reject_Reason,
Fabric_Status,
Other_Port_Fabric_Service_Parameters)
My_ID will reflect the D_ID returned in the Fabric Login Accept Frame.
Local_N_Port will indicate the local N_Port
which issued the FLOGI.
Request_Status will indicate status as one of
the following:

Successful - Fabric Login completed.

Unsuccessful - Sequence was not delivered completely due to reason other than reject.
Rejected_Request - The Request was not
sent by the Initiator due to the specified
Reject_Reason.
Rejected_by_Fabric - Reject frame received from Fabric.
Rejected_by_N_Port - Reject frame received from N_Port.
Rejected_by_Link_Services - Link Services Reject frame received from N_Port.
When the Request_Status is Rejected_Request, Rejected_by_Fabric, or Rejected_by_N_

dpANS X3.xxx-199x
Port, the Reject_Reason will indicate one of the
Reject reason codes given in Table 55.
The Fabric_Status will indicate status as one of
the following:

isolated - Link is not connected.

no_fabric - N_Port is connected point-topoint with another N_Port.

fabric - N_Port is connected to a Fabric.

Other_Port_Fabric_Service_Parameters will
optionally specify the parameters to be used for
the F_Port in the operation of a Fabric when a
Fabric is present as indicated by Fabric_Status,
or will optionally specify the parameters to be
used for the other N_Port when no_fabric is indicated by Fabric_Status.
S.2.5.2 When Generated
S.2.5.3
This primitive is generated upon
completion of a Fabric Login attempt.
S.2.5.4 Effect of Receipt
The effect of receipt of this primitive by the FC4 entity is unspecified.
S.2.6

return the current N_Port Service Parameters

for the N_Port specified by Other_ID, via the N_
PORT_LOGIN.confirmation. An N_Port Login
Sequence is not transmitted, but a count of the
number of Login requests for the specified N_
Port pair is updated. However, the N_Port may
issue an a PDISC ELS to obtain the most current N_Port Login parameters.
S.2.14

N_PORT_LOGOUT.request

This primitive is used to request that a Login be

terminated with the specified N_Port.
S.2.14.3 Effect of Receipt
Receipt of this primitive will cause FC-PH to
decrement the count of the number of Login requests for the specified N_Port pair.
If the count of Login requests for the specified
N_Port pair is not yet zero, FC-PH does not
generate a Logout Sequence.
If the count of Login requests for the specified
N_Port pair is now zero, receipt of this primitive
will also cause FC-PH to generate a Logout Sequence.

IMPLICIT_FABRIC_LOGIN.request

No change from FC-PH.

S.2.7

N_Port Login Primitive Flows

No change from FC-PH.

S.2.8

N_Port Login Service Parameters

No change from FC-PH.

S.2.9

N_PORT_LOGIN.request

This primitive is used to provide N_Port Login

parameters and to request a login with another
N_Port, if necessary.
S.2.9.3 Effect of Receipt
If the N_Port specified by My_ID is not currently
logged into the N_Port specified by Other_ID,
the receipt of this primitive will cause FC-PH to
transmit an N_Port Login Sequence with a
Class as specified by 23.4.3. The count of the
number of Login requests for the specified N_
Port pair is set to 1.
If the N_Port specified by My_ID is currently
logged into the N_Port specified by Other_ID,
the receipt of this primitive will cause FC-PH to
89

dpANS X3.xxx-199x
T

Annex T
(informative)
No enhancements to X3.230-1994 (FC-PH) annex T.
U

Annex U
(informative)
No enhancements to X3.230-1994 (FC-PH) annex U.
V

Annex V
(informative)
No enhancements to X3.230-1994 (FC-PH) annex V.
W

Annex W
(informative)
No enhancements to X3.230-1994 (FC-PH) annex W.
X

Annex X
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex T.
Y

Annex Y
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex U.
Z

Annex Z
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex V.
AA

Annex AA
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex AA.
AB

Annex AB
(informative)
No enhancements to X3.xxx-1995 (FC-PH-2) annex AB.

dpANS X3.xxx-199x
AC

Annex AC
(Informative)
A Real Time Loop Based Fibre Channel Topology
AC.1

Scope

This annex describes a data distribution architecture based on the use of Fibre Channel constructs aimed at real time applications where a
known worst case amount of guaranteed bandwidth is needed. These applications include
the distribution of real time audio and video.
Though the architecture is loop based, it provides higher layer protocol support to act as a
crosspoint switch as well. The loop at each
node also provides a point to point interface
which makes the architecture expandable into a

mesh like structure. From a Fibre Channel perspective, with minimal exceptions noted herein,
the architecture design is compliant with FC-PH
rev 4.3. Compliance to FC-PH-3 is used to cover exceptions to FC-PH rev 4.3 necessary to
support real time operation. No primitives or
link services beyond those defined in FC-PH
rev 4.3 are necessary for its implementation. In
detail this annex defines the overall topology, a
new port type, the real time loop (RTL) port, the
specific Fibre Channel services which are used,
and the layers of protocol above Fibre Channel
needed to define the architecture.

1.0625 Gbps
Optical
RTL Port
Class 2/3
N_Port

Node N-1

RTL Port

Terminal N-1
266 Mbps
Coax

1.0625 Gbps
Optical
RTL Port
Class 2/3
N_Port

Node N

RTL Port

Terminal N
266 Mbps
Coax

1.0625 Gbps
Optical
RTL Port
Class 2/3
N_Port

Node N+1

RTL Port

Terminal N+1
266 Mbps
Coax

1.0625 Gbps
Optical

Figure 112 Real Time Loop Topology

dpANS X3.xxx-199x

AC.2

General Description

Application Interconnect

The distribution system is based on a ring topology. The ring structure consists of a set of
nodes tied together in a point to point configuration as shown in figure 112. Within each node
are two Real Time Loop (RTL) Ports which support Fibre Channel class 3 communications and
an N_Port which supports class 2 and 3 communication. The distribution protocol uses a
slotted or "register insertion" algorithm. The
point to point class 3 interconnects conform to
the ANSI X3.230 Fibre Channel standard.
Each RTL port communicates with its neighbor
RTL port using a full speed (1.0625 Gbaud) optical (100-M5-SL-I) bi-directional path to its
neighbor node which operates in a full duplex
mode.
The N_Port to Terminal interconnect shown in
figure 112 represents a full duplex point to point
known as a Local Node Interface. This link represents a quarter sp eed coaxial (265.625
Mbaud 25-TV-EL-S) access point to the ring's
data structures. Optics are optional at this interface.
As shown in figure 114, the Fibre Channel FC2
layer is a Time Division Multiplexed (TDM) win-

TDM Windowing
Fibre Channel Framing FC-2
Classes 2 and 3
Fibre Channel Signalling FC-1
Fibre Channel Physical FC-0
Full Speed Optical &
Quarter Speed Electrical
Figure 113 Real Time Protocol Stack
dowing protocol which provides for synchronous
data delivery. The system designer is given access to this protocol structure so that bandwidth
can be allocated based on application requirements. By programming these windows, the user
can allocate any amount of bandwidth to any type
of data, and to any network terminal. The loop architecture with the synchronous windowing technique built on top of Fibre Channel is here after
referred to as the Fibre Channel Real Time Loop
(FC-RTL) topology.

Interface
Hardware

3
1

6
Interface
Hardware

10
Interface
Hardware
2

5
Interface
Hardware

Interface
Hardware
4

Normal Data Flow

Loopback
Fault

Interface
Hardware

Loopback
8

3
Interface
Hardware

2
1

7
Interface
Hardware

Data Flow Under Fault Condition

Figure 114 Failure Detect and Re-routing

dpANS X3.xxx-199x
This layer also provides the FC-RTL with support for a counter-rotation feature. During normal error free operation, data flows primarily in
one direction with the return path used for flow
control. When an error occurs either through
the result of a link failure or the failure of a
node, neighboring nodes can autonomously detect the failure and reroute the data around the
error as shown in figure 114. In this way the
system provides recovery from single point failures without the need for expensive backup or
redundant rings.
In addition, the TDM layer provides support for
allocating bandwidth (that is not being used for
synchronous communications) for asynchronous non-real time control type traffic. The built
in asynchronous support is used for determining mastership, for system synchronization, and
for error recovery.
AC.2.1

Network Data Flow

Network data flow can be divided into synchronous and asynchronous traffic. The frame
based data structure for transmissions is shown
in figure 114.

Synchronous
Bandwidth
Type 1

Type 2

Asynchronous
Bandwidth
Type 3

62.5 us

nel frames. The minor frame size is programmable and represents the amount of bandwidth
that has been assigned to a particular data information type. Thus, if Type 1 was audio and
consisted of 2000 words, the bandwidth allocation for audio would be 2000 * 16 bits *16 KHz
or 512 Mbps.
AC.2.1.1 Synchronous Service
To provide for guaranteed data delivery, the
network provides a synchronous data frame
service. This may be viewed as a set of exchanges/sequences/frames which are initiated
by one node, designated as the Master node,
according to a predetermined rate schedule.
These frames are delivered to each node in
succession, and may be used by that node for
the purpose of encapsulating data. The receiving node may in effect, capture the frame, modify it, and retransmit it in the corresponding time
slot.
To provide for synchronous bandwidth allocation, each data source is allocated a number of
channels which it can use to insert information
onto the network. These channels are grouped
into a set of frame types which are distributed at
different rates. As an example, a data source
could be allocated 100 16 KHz channels and
100 50 Hz channels. This would be an allocation of 1,605,000 16 bit channels, or 25.68
Mbits/sec of network bandwidth to the data
source. The frame types, their sizes, and their
rates are all totally programmable. Maximum
frame rates and numbers of provided data
types are a function of RTL Port design.
AC.2.1.2 Asynchronous Service

Major Frame
Figure 115 TDM Window
In this example, the highest rate frame is 16
KHz, and a major frame is a 62.5 us window of
data. This window size is programmable with
the minimum size determined by RTL port design. Each window is broken down into synchronous and asynchronous bandwidth. The
window is then further broken down into minor
frame types. For example, Type 1 might be audio, Type 2 might be video, and Type 3 might
be control information. These minor frame
types consist of a number of 16 bit data words,
and are transmitted as one or more Fibre Chan-

Should applications not require 100% use of

the network's bandwidth for synchronous service, the remaining bandwidth can be used
asynchronously -- whenever it is available.
The asynchronous bandwidth is used only
when window space is available after synchronous bandwidth has been allocated. Asynchronous bandwidth can also be used at
initialization before synchronous frame transmissions have begun. Note that the network
design supports a configuration where the
amount of allocated synchronous bandwidth is
zero, and therefore allowing 100 % of the bandwidth to be allocated to asynchronous commun icatio ns . Th e syst em do es n ot s up p or t

dpANS X3.xxx-199x
multiple data types in the asynchronous mode.
The asynchronous mode is not an optional feature however, as it is required for system initialization and error recovery.
To prevent the transmitting node from capturing
the network for an extended time, the RTL port
shall be capable of implementing a fairness algorithm while in asynchronous mode. After a
prescribed number of successful frame transmissions, the node shall allow sufficient time to
permit at least any one of the other nodes on
the ring the opportunity to start a frame. In the
event of a collision, the node shall implement a
delay prior to any re-attempt to capture a transmit opportunity.
AC.2.2

Network Characteristics

AC.2.2.1 Master Node

Data distribution through the network is controlled by a "master node". Each node has the
capability of being the master, but only one
master is active at a time. Mastership establishment is done at network initialization time
through an arbitration algorithm. Upon power
up, after a node determines that it is functional,
it begins transmitting an asynchronous frame
which contains its network address. It continues this until it receives from its upstream node
an address which is greater than its own. If this
occurs, the master begins transmitting the highest address that it receives. When a node rec e i v e s i t s o w n a d d r e s s , it a s s u m e s t h e
mastership role and begins transmitting synchronous frames. Once a node obtains mastership, it retains the role until either it fails or the
system is shut down. The network provides automatic master failure detection and recovery to
a new master.
The master node is the synchronization point of
the network. It resynchronizes frames as they
pass through it. The master node is synchronized to an external clock which it uses to determine when to transmit a major frame. It also
houses a scheduler which it uses to determine
the minor frame types to include in each major
frame.
AC.2.2.2 Data Distribution Characteristics
Initially, the window is transmitted by the master
as nulls in each channel of each frame type. As
each terminal sees this null frame it can source
data into its pre-allocated channels as the

frame passes through its "local node". Once

the frame which was originated by the master is
received back by the master (after having traversed the ring), it is resynchronized by the
master. Any data received by the master is inserted into the next frame that it transmits.
Terminals which source data are also responsible for removing it from the network, otherwise
it would traverse the ring continuously. This is
done when the data source's local node receives back what it has transmitted.
A terminal is aware of which slots of a particular
data type have been allocated to it through the
use of a data structure known as an "access table". This access table simply consists of a single bit for each data word in each frame type.
The state of each bit determines whether or not
a node is to make a copy of the data word represented by the bit as it passes through the
node. This table is dynamically programmable,
and a copy of it is kept at each terminal and at
each terminal's local node. Management of
these tables is the primary means for creating a
crosspoint from a terminal source to a destination. For a terminal to obtain access to a particular channel, it simply makes a request to the
table manager (software that currently executes
on a CPU board in one of the terminals) who in
turn modifies the requesting terminal's access
table. These tables can reside in non-volatile
memory at power on, so that fixed connections
can be made as the network is initialized. The
tables are also accessible from the network itself so that they can be read or written to and
downloaded if necessary.
Class 3 Fibre Channel functionality is defined
as a datagram communication methodology
which operates in a "send and forget" manner.
This is a connectionless service which does not
provide reception acknowledgment or automatic retransmission in response to error detection.
This class is used in the ring portion of the system architecture because of the type of data it
has been designed to distribute -- high data
rate audio and video. Due to the nature of the
data itself, real time error recovery in terms of
data retransmission is not practical, and the
choice of class 3 (which does not provide this
service) keeps the interface circuitry complexity
to a minimum. Still, class 3 provides buffer to
buffer flow control so that data is not lost because of the lack of buffer space at the receiv-

dpANS X3.xxx-199x
er. The system provides inband signaling and
control distribution which requires more robust
acknowledgment and error recovery services.
Since this is not provided by Fibre Channel itself (in Class 3), it is handled in a upper level
protocol shown in figure 114.
Each network node also provides a point to
point Fibre Channel interconnect to a network
terminal as shown in figure 112. This point to
point interface provides Fibre Channel class 2
and 3 communication services. This interface
provides an access point to sources and destinations of network information. Class 2 services are offered here so that bridges to other
network structures such as LANs, SCSI drives,
ATM switches, etc are possible. Thus the ring
topology can be considered a local area network with bridges to other local or wide area
networks. The node then acts as a gateway between a Fibre Channel real time loop and a Fibre Channel point to point connection.
AC.2.2.3 Network Latency
The real time loop topology has been designed
to a top level system requirement of a 2 millisecond loop rotation time. Any data sourced to
the network will be received by any other terminal on the network within 2 ms, and the time
delta between the reception of the same data
for any two terminals is 2 ms. The network
guarantees this through its system design regardless of how much traffic is currently on the
network. Obviously, this latency is dependent
on the number of nodes on the network, and
this latency can be exceeded if enough nodes
are put onto the network. However simulations
of the interface hardware design have shown
that with a wormholing approach, a 128 byte Fibre Channel frame can be moved through a
node in less that 10 microseconds. With this
timing, the latency requirement above can be
achieved with a configuration of 2000 nodes.
These times are achievable, because, once the
system has been initialized, there is no software interaction required for data movement
from input RTL port to output RTL port through
the node.
AC.2.2.4 Sequence/Exchange Management
When a new window is scheduled on the loop,
it may consist of several data types, but will always consist of at least one data type (there are
no empty windows). Each window's worth of

each data type scheduled for that window can

consist of multiple Fibre Channel frames. This
series of Fibre Channel frames are packaged
into a Fibre Channel Exchange as defined in
FC-PH. Each data type within the window will
be given its own exchange. Thus multiple exchanges can be transmitted within a window.
However, only one exchange is open at any
one time. Within a particular exchange, only
one sequence is opened at a time. An RTL_
Port can only manage one exchange at a time.
Within this one open exchange, the RTL_Port
can manage multiple sequences of multiple
types of data. Only one sequence can be active at a time, and each frame within a sequence is always of the same type.
An RTL_Port is capable of transmitting and receiving up to 16 different types of information.
The transmitted type is identified in the "type"
field of the Fibre Channel header. An RTL_Port
also applies types to exchanges. A port supports up to four different exchange types, each
corresponding to a particular error policy as defined in FC_PH. Each frame transmitted within
an exchange of a particular type will be treated
with the error policy defined for the exchange.
Furthermore, because the RTL_Port is used in
a real time system, it uses the sequence type
within an exchange to decide what sequence
has transmission priority should a transmission
schedule overlap sequence transmission rates.
AC.2.2.5 Use of Flow Control
Since the RTL components of the architecture
use class 3 communication, only R_RDY primitives are available for flow control, and these
are used at each ring interconnect. Specifically, a RTL port transmits an RDY whenever a
buffer becomes available. This is used by the
source RTL port to maintain buffer to buffer
credit. When the RTL network is used in synchronous mode, all data types and sizes are
programmable as are the transmission rates of
each type. Since the frame rates and sizes can
be determined by the system designer ahead of
time, the RTL port buffer space can be designed to support the worst case transmission
scenario. Thus in this mode of operation a RTL
port can theoretically transmit without waiting
for RDYs to indicate buffer availability at the
destination. However, each RTL port supports
the transmission and reception of RDYs as de-

dpANS X3.xxx-199x
fined in FC-PH. This is done to support the
asynchronous mode of operation, error recovery situations, and to insure specification compliance and interoperability issues.
AC.2.2.6 Error Recovery

AC.2.2.7 Use of Discard Policy

The network design permits the use of Discard
Policy for synchronous and asynchronous
frames. The use of Discard Policy is as defined
in FC-PH rev 4.3.
AC.2.2.8 Use of Process Policy
The network design allows the use of process
policy for synchronous frames. It makes no attempt to process data within an invalid Fibre
Channel frame, but continues to process subsequent frames within the sequence of which
an invalid frame is a part. This permits the use
of most of an audio or video sequence in the
case where potentially only small portions are
lost.
This process policy is defined in FC-PH-3 and
is a modification to X3.230 in that it allows the
sequence to continue even if the first or last
frame of a sequence is lost. In this case, the
abort sequence bits in the frame header are
valid for each frame in the sequence, not just
the first.
Since the interface permits only one concurrent
sequence, it can detect that a sequence has
ended by the reception of another frame with a
different sequence ID. The interface also closes a sequence if E_D_TOV times out before
the reception of the last frame of a sequence or
the reception of a frame of another sequence.
AC.2.2.9 Acknowledgement
Since the loop interconnects communicate using class 3 services, no acknowledgment is provided by the Fibre C hannel interface
hardware. Where needed, mainly for in-band
control functions, acknowledgment is provided
by the Upper Layer Protocol (ULP). Acknowledgment is provided by the point to point interface using class 2 services.
AC.2.2.10 Wormholing
To decrease network latency, frames pass
through the two RTL_Ports within a node using

a "wormholing" algorithm. Received frames will

be retransmitted by the node without having
been fully received and validated. Both the receiving RTL_Port and the transmitting RTL_
Port are operational with respect to the optical
link simultaneously. Also, multiple nodes can
be processing a particular frame of data at the
same time. Note that this frame could be altered after it was initiated, so that when multiple
nodes are processing the same frame each
node may be working on a different payload.
AC.2.2.11 Frame Validation
With wormholing in effect for synchronous service, several nodes can be accessing data from
the same frame simultaneously. This means
that data is extracted by a node before the
frame has been validated, and thus invalid data
may be extracted. However, it is not the node
that uses the extracted data - it is the terminal.
It doesn't matter that the node has extracted
bad data as long as it is not sent to the local terminal. In order to prevent this from happening,
the node does not send data to its local terminal
until the received network frame has been validated.
Note also that wormholing causes a problem on
the insertion of data into a frame as well. As a
frame is traversing through a node, new data in
the node's insertion buffer (sourced by it's local
terminal) is put into the frame. This happens
before the frame is validated as well. Thus
good data can be put into an invalid frame.
This again is overcome since the destination
terminal will not ever see this data. Frames
which are determined to be invalid because of
an incorrect CRC or an invalid payload by a
node are terminated with an EOFi delimiter
upon retransmission. Although the downstream node may have extracted data from this
invalid frame due to the use of wormholing, it
will not transmit the data to its local terminal
when it sees the EOFi delimiter. The extracted
data, some of which might have been good data, is dropped by the node. Frames with an
EOFi end delimiter continue to be propagated
by the network nodes until the reach the master
node where they are removed.
Frames that are not correctly delimited are removed by the node which detects the incorrect
delimiter. These frames do not propagate back
to the master node.

dpANS X3.xxx-199x
AC.2.2.12 External Clocks

AC.2.2.15 Smoothing Algorithm

As the network was designed to support fully

synchronous data distribution, carefully consideration is given to controlling jitter. The network
is designed to support the distribution of information such that the phase relationship of data
put onto the network and taken off of the network can be maintained. To support this the
master node (and its associated backup(s)) are
provided external master clocks which are used
to synchronize the delivery of windows. The
rate of these clocks is a system design parameter. However, for interoperability considerations a standard rate should be chosen. The
recommendation here is a 4.096 MHz clock. It
is further recommended that the clock source
be redundant.

With this network topology, there exists the

eventual certainty of clock mismatch due to
clock frequency skew and jitter. Since each
node transmitter is attempting to maintain the
FC-PH requisite number of six fill characters
between frames, the eventual accumulation of
clock difference between the receive and transmit clock domains a character (taken to be a fill)
will either have to be deleted or inserted. Each
node supports a smoothing algorithm to account for the difference in clock domains passing from node to node. Since each node uses a
clock that meets the frequency tolerances defined in FC-PH, only fractional clock differences
are accumulated on a frame to frame basis.

AC.2.2.13 Link Recovery

In the event that the communication channel
between two nodes fails, the RTL_Ports which
make up the link will continuously attempt to reestablish communication. In this failure scenario, the two nodes go into loopback and network
data flows in a counter-rotating manner. Still
the RTL_Ports which are now out of the loop
will use the link recovery mechanisms defined
in FC_PH to repair the loop. Should the link recovery be successful the two nodes will transition out of loopback mode and into normal
operation. Note that Login is performed before
the healed interconnect can support data flow.
AC.2.2.14 Real Time Support
The network design is intended to support real
time applications, and deterministic performance is necessary. With this intent in mind,
the propagation delay through a node in the
network is a fixed constant number of clock cycles at each node. Each node is expected to
maintain an internal clock to within the specified
tolerance limits specified for Fibre Channel data
transmission. As specified in FC-PH the transmitter is required to provide a minimum of six
clock cycles between frames. With a fixed
number of clock cycles per node (within the tolerances of the transmission clocks at each
node) the frames will maintain their relative time
positions. This fixed number of clock cycles is
a system design parameter. However, when interoperability is considered the number of clock
cycles should be standardized.

Each node provides enough elasticity buffering

to accommodate input data overflow/underflow
that occurs within the lifetime of a frame and will
attempt to recover the difference by adjusting
the perceived number of fills received.
AC.2.2.16 Frame Addressing
For synchronous frame services, each frame
transmitted by any node on the network always
contains the master's address as the S_ID and
the D_ID. These identification fields within the
Fibre Channel frame header can be modified
only by the master node. All other nodes simply pass them through. When the master node
receives a frame with its D_ID in the header
field, it removes the frame from the network.
Note that the payload within the frame is not
dropped, but is stored locally at the master
node. This payload will be inserted into the
next scheduled frame of the received type.
For asynchronous frames the S_ID field contains the address of the frame source (which
can be any node on the network). The D_ID is
the address of the desired destination. Again,
when the node sees its address in the D_ID
field of an asynchronous frame, it removes the
frame from the network. Since there is no rescheduling of the asynchronous frames, the
transmission ends upon frame removal by the
destination.
AC.2.2.17 In-Order Delivery
RTL_Ports use an in-order delivery scheme for
all synchronous and asynchronous transactions
throughout the network in a manner described
in FC-PH. All RTL_Ports logon to each other
97

dpANS X3.xxx-199x
with the in-order delivery parameter set to "required".
AC.2.2.18 Frame Size
Network frame sizes are system design parameters, and buffer space is a function of RTL_
Port design. However, as a minimum the network interface to each local node should provide 31 buffers each sized at a minimum of 512
bytes of data. The interface also should provide buffer space for 31 frame headers of 32
bytes each.

AC.3
AC.3.1

System Level Components

Node Description

As previously defined, a node consists of two

RTL_Ports and an N_Port. Each node also
provides its own power rather than obtaining
power from its local terminal. Autonomous
power allows the loop to maintain full functionality should a terminal fail.
AC.3.2

RTL_Port Functionality

At its optical interface with its upstream or

downstream Port, an RTL_Port operates as a
class 3 N_Port as defined in FC-PH. At its
backend parallel electrical interface an RTL_
Port communicates with a second RTL_Port
and the N_Port within the same node. As a
RTL_Port receives data from its upstream
neighbor, it uses its access table to determine
which parts of the payload (if any) to copy as
the frame passes through it. Copied data is
made available to the N_Port for transmission
to the local terminal. The receiving RTL_Port is
also responsible for validating the received
frame. Data is not transmitted to the local terminal by the N_Port until the received frame
has been validated. The receiving RTL_Port is
responsible for invalidating a frame in the manner defined in FC_PH should it detect an error.
The N_Port within the node is responsible for
building the new data to be retransmitted by the
node. It does so based on data received from
its local terminal via its point to point interface.
The local terminal has been told previously
where in each frame that it can originate data.
This knowledge is kept in the access table
housed within the local terminal. The N_Port
also knows where within each frame it has previously inserted data into the network. In its allocated frame locations where it is sourcing no

new data, the N_Port must insert nulls. This effectively removes data from the network that it
has previously sourced.
The second RTL_Port within the node is responsible for packaging the data generated by
the N_Port into a Fibre Channel frame and
transmitting it to its downstream neighbor. This
RTL Port is also responsible for generating the
CRC before transmission.
The backend interfaces of both RTL_Ports in
conjunction with the backend interface of the
N_Port act together to create a fabric like structure. These backend interfaces move data
from one N_Port to another N_Port. This might
be considered the primary responsibility of a Fibre Channel fabric. One major difference between this functionality and that of a fabric is
that data is that data may be modified as it
passes through the fabric. Since it is not a FC_
PH compliant fabric, it is really performing a
ULP function.
AC.3.3 RTL_Port/N_Port
Characteristics

Fibre

Channel

AC.3.3.1 Primitive Signals

All ports within a node support all FC-PH rev
4.3 primitive signals and requires the use of no
"vendor specific" primitives. Though the optical
network protocol uses class 3, each RTL_Port
is capable of receiving and transmitting frames
with delimiters for all classes (1 through 3).
However, the RTL_Port does not support class
1 and 2 applications. It will reject class 1 and 2
frames with the appropriate delimiters as required in FC-PH.
AC.3.3.2 Basic Link Services
Basic Link Services are handled by the microprocessor in the local node. These services
are all done using the asynchronous mode of
the interface. The local node at the network interface and the point to point interface to the
terminal supports all Basic Link Services as defined in FC-PH rev 4.3 except for the Remove
Connection service which is only used for class
1 connections.
AC.3.3.3 Extended Link Services
Extended Link Services are handled by the microprocessor in the local node as well. Like the
Basic Link Services, the Extended Link Servic-

dpANS X3.xxx-199x
es are done in the asynchronous mode. The
node supports Link Service Reject (LS_RJT),
Accept (ACC), N_Port login (PLOGI), F_Port login (FLOGI), logout (LOGO), Abort Exchange
(ABTX), Read Connection Status (RCS), Read
Exchange Status (RES), Read Sequence Status Block (RSS), Read Timeout Value (RTV),
Read Link Status (RLS), and ECHO.
Ports within the node do not support Link Service Busy (LS_BSY), Request Initiative (RSI),
Establish Streaming (ESTS), Estimate Credit
(ESTC), Advise Credit (ADVC), Test (TEST),
and Reinstate Recovery Qualifier (RRQ).
AC.3.3.4 Login/Logout
Each port within a node supports the explicit login and logout procedures defined in FC-PH rev
4.3. Login can be done at any time to reestablish parameters, and can be done with or without a preceding logout.

At a minimum the N_Ports used for the point to

point interface to the node must support ACK_
1.

AC.4

Fabrics

While the Real Time Loop is normally expected

to be a continuous ring of RTL ports connected
by point to point links, it is possible to place an
intervening fabric between two RTL ports. In
this case, in order to meet the real time requirements of the network, it is necessary for the
fabric to provide a dedicated, in order path with
a fixed path delay. If the fabric also supports
the other requirements for RTL such as the
Fairness algorithm, it may also route frames
from outside the ring onto the ring network or
route frames from the net elsewhere.

AC.3.3.5 Use of Credit

RTL_Port support the use of buffer to buffer
credit as defined in FC-PH to manage flow control. N_Port tied to the node's point to point interface use both buffer to buffer credit and end
to end credit
AC.3.3.6 Timers
Each port within a node provides the timers defined in FC-PH. E_D_TOV is used with a resolution of 1 ns.
AC.3.3.7 Sequence/Exchange Status
Each port within a node maintains both Sequence Status Blocks (SSB) and Exchange
Status Blocks (ESB) in accordance with FCPH. The only time where sequence initiative is
passed to to get SSBs and ESBs from a neighbor port to support error management.
AC.3.4

Point To Point Interface

At the point to point interface to its local terminal the node should provide the following programmable buffer space:
240 bytes
512 bytes
1056 bytes
2112 bytes

16 buffers
8 buffers
4 buffers
2 buffers

dpANS X3.xxx-199x

Annex AD
(Informative)
Priority and Preemption

Real-time systems require interconnect networks that provide guaranteed bandwidth,

guaranteed in-order delivery, and guaranteed
latency. To meet these requirements, an interconnect network that resolves access contention using priority and preemption is desired.
A priority value in the Fibre Channel frame
header is defined (high 7 bits of the OX_ID
field, see FC-PH-3 clause 18) and can be used
by a Fabric to resolve contention between N_
Ports requesting a Dedicated Connection to a
single resource N_Port. A 7 bit field is defined
since this size enables efficient implementations of the Rate Monotonic Scheduling Algorithm.
Preemption in the context of a Fibre Channel
Fabric is the act of establishing a connection to
a resource or resources (if multicast is used)
that is/are already a part of a dedicated connection. The act of preempting an existing dedicated connection is completed ensuring that
complete frames are transmitted and received
with link integrity maintained.
A preemption is initiated when a preemption request frame (SOFc1 with preemption flag set =
1, defined in FC-PH-3 clause 18) is forwarded
to the Fabric by an unconnected N_Port. The
preemption request will result in (1) the preemption of an existing dedicated connection
and the establishment of a new dedicated connection between the preemption requesting N_
Port (the preemptor) and the desired destination(s) N_Port(s) (the preemption destination(s)), (2) the establishment of a dedicated
connection between the preemptor the preemption destination(s), (3) or rejection of the preemption request by the Fabric. In a real-time
application, rejection by the Fabric might be
due to a priority value that is too low.
The process for performing a preemption is as
follows:
Upon receipt of a request submitted by an FC-4
or other upper level protocol to initiate a con-

nection using preemption, the FC-2 protocol attempts to establish a connection using the
SOFc1, with the preemption flag set = 1, preemption request frame. In the following figure,
the preemptor P is sending a preemption request frame (SOFc1 with preemption flag set =
1) to the Fabric.

Fabric
A

SOFc1

If the Fabric denies the request the Fabric returns a F_RJT Link_Response frame with a
preempt request rejected reason code (FCPH-3 clause 20) to the preemptor with no other
effects on the Fabric. No connections are
changed if the Fabric rejects a preemption request.

Fabric
A

F_RJT

If the Fabric accepts the request, the Fabric terminates the connection(s) being preempted (A
to B) by initiating the Link Reset protocol (FCPH clause 16.6.5) to both the preempted connection initiator and recipient (A and B). Once
the Link Reset protocol is complete the Fabric
forwards an PRMT basic link service command
(FC-PH-3 clause 21.2) to both the preempted
connection initiator and recipient (A and B. N_
100

dpANS X3.xxx-199x
Ports A and B now know why they have abnormally terminated sequences that must be managed).

LR, F_PRMT

Fabric
B
F_PRMT ,LR

The sum of P_T_LR, R_T_LRR, and R_T_ID

should be equal to n times the class 1 connection setup latency. Where the class 1 connection setup latency is the time from when the
connection initiator forwared the SOFc1 to
when the connection recipient detects reception
of the SOFc1. The value of n is dependent on
the application environment. High performance
environments will want a small value of n (~1 or
2), other environments may be function with a
value much larger.

The Fabric then establishes a new connection

(P to B) by forwarding the SOFc1 preemption
request frame to the preemption destination
(B). The new dedicated connection is established when the preemptor (P) receives the acknowledge from the preemption destination N_
Port (B).

Preempt Connection

LR Transmitted

Timeout
Received LRR Received LR
LRR Received

Fabric
A

Transmit Idles

LR Received

Received Idles

Transmit LRR

SOFc1
B

Link Failure

Transmit LR

Active

ACK

Link Reset Protocol: The link reset protocol, as

defined in FC-PH clause 16.6.5 follows the process oulined in the preceeding figure when
used for preemption. The Timeout period is
sp ecified as the R_ T_ TO V value (FC-PH
clause 29.2.1.1) for detection of loss of synchronization (see FC-PH clause 12.1.1.2). To
guarentee timely progress through the preemption sequence the following delays should be
specified by the application layer profile.
P_T_LR, Preempt Connection state to
Transmit LR
R_T_LRR, Received LR to Transmit LRR
R_T_ID, Received LRR to Transmit Idles
Reasonable values for these event delays are
dependent on the application that is using preemption. A rule of thumb that could be useful
might be:

101

dpANS X3.xxx-199x

Annex AE
(Informative)
Report Node Capabilities (RNC)

AE.1

Background

Much information about an N_Port can be determined from its login parameters and how it
responds to certain requests. For example the
login parameters may indicate that Class 1 and
Class 3 are not supported. A failed process login attempt may indicate an N_Port does not
support FCP. A time-out waiting for a response
may indicate an N_Port does not support FCLE (IP). Although ways exist to obtain much of
the information desired, some items can not be
determined without the use of vendor specific
fields. For example, an N_Port which can operate under both the Class 2 only and mixedmode (Class 1 and 2) variations of the FCSI
profiles does not have a standard method to indicate which is preferred (and likely to give the
best performance).
The RNC link service was designed to meet the
following goals:
Provide a standard way to discover what
protocols and standards an N_Port supports
(its capabilities).
Provide a method to select a specific capability from a list of supported capabilities.
Provide a method to indicate preference
or relative level of support of a specific capability (e.g. support of a profile) when multiple
capabilities are supported for a given protocol.
Provide a method to exchange and set
new and additional parameters not specified
during N_Port login.
Provide a standard method to select vendor unique operation modes or profiles.

AE.2

Operation Modes

The RNC link service may be used in two distinct modes:

Querying the capabilities of an N_Port

Setting specific operating modes or parameters

AE.2.1

Query Function

Using the RNC link service to query the N_

Ports capabilities may be accomplished by setting the RNC_Flags Select bit to 0. The requesting N_Port may, but is not required to,
supply Capability Entries in the RNC payload.
The Vendor Identifier must always be supplied.
The requesting N_Port must keep the length of
the RNC payload less than or equal to 256
bytes. This requirement relieves the responding
N_Port from dealing with an arbitrarily large,
unsolicited link service.
The responding N_Port, upon receiving an
RNC request with the Select bit 0, should respond with an RNC Accept payload which lists
all of the nodes capabilities it wishes to report.
No length restriction exists on the RNC Accept
because it is solicited. Also, there is a desire to
keep the responders requirements at a minimum. The responder may choose to vary the
capabilities reported based upon the Vendor
Identifier in the RNC request.
AE.2.2

Selection Function

The RNC link service is designed to allow either

the requesting or the responding N_Port to actually make the selection from the list of supported capabilities.
If the requesting N_Port wishes to allow the responding N_Port to make the selection, it sends
an RNC request with a list if the capabilities it
supports and the Select bit set to 1. The responding N_Port will choose one capability
from the list and include it in the response.
The requesting N_Port can make the selection
itself by first issuing an RNC with the Select bit
set to 0 (query). It then evaluates the list of capabilities in the RNC Accept and selects one.
Finally, it issues an RNC request with the Select bit set and the selected Capability Entry.
The responding N_Port will then be forced to
select the desired entry.

102

dpANS X3.xxx-199x
Of co urse th ere may be variations on the
above. A requesting N_Port may only support a
small set of capabilities (possibly only one). It
may choose not to query the capabilities of the
other node first, but issue an RNC with Select
set to 1 immediately.
Multiple Selections: There may be cases
when both N_Ports support two distinct protocols or classes of capabilities. For example two
N_Ports may communicate using both FCP and
FC-LE (IP) protocols. In this case the requesting N_Port should only list the FCP related capabilities in one RNC request. After the FCP
profile selection is made, the N_Port would then
issue a second RNC request with the Select bit
set and list profiles or capabilities associated
with the FC-LE (IP) protocol.
The RNC definition does not attempt to define
which documents support what protocols or in
any way group associated documents. It is assumed the N_Ports implementing the protocols
and various capabilities will handle the required
associations and distinctions.
Preference Bits: The Preference bits may be
used to aid the selection choice in the event
there are multiple capabilities listed. The two
bits provide a range of four values to rank the
relative preference of multiple capabilities. For
example an N_Port may support three profile
variations for FCP; FCSI SCSI with Class 2,
FCSI SCSI mixed mode, and a vendor unique
FCP profile. The node may wish to assign a
preference as follows:

00 (Best) - Vendor unique FCP

01 - FCSI SCSI mixed mode (protocol

chip may be designed for Class 1)
11 (Worst) - FCSI SCSI w/Class 2 (supported for interoperability reasons, but poor
performance)
Of course another N_Port may work best with
FCSI SCSI with Class 2. The idea is that an N_
Port may have hardware or software implementations which favor a certain operating mode.
The Preference bits allow that information (in a
limited way) to be exchanged with other N_
Ports.
Invalidate Bit: The Invalidate bit allows a
change in a previous selection. Unless the Invalidate bit is set, additional RNC requests with

the Select bit set to 1 are assumed to be selecting additional capabilities which are unrelated
(non-conflicting) with previously chosen capabilities.
To renegotiate a capability, the specific capability selected in the prior RNC request should
be included in the new RNC request as the first
Capability Entry with the Invalidate bit set to 1.
The capabilities the requesting N_Port wishes
the replacement selection to be made from
should follow the entry marked invalid.
Extensions: Extensions to a Capability Entry
allow option bits, parameters, or other information to be specified as a capability. The document referenced in the Capability Entry is
responsible for defining the meaning of all fields
in the extension except the Extension Length.
An example usage of extensions would be if a a
document defined a new feature which would
allow increased performance. The use of the
feature, however, may break older devices
which do not have the feature. An extension bit
or field in the RNC capability entry for that document could be used to indicate support.
The length of any extensions must be a multiple
of four bytes (including the extension length
field). This ensures that all capability entries
start on a 32 bit word boundary.
Vendor Unique Indication: Two bits of flags
are used to indicate vendor unique options. If
the Ca pability Entry is marked a s ve ndor
unique then the value assigned for the document identifier is determined by the vendor. No
attempt is made to coordinate vendor unique
document identifier values across vendors.
Thus, interpretation of a vendor unique document identifier must be in conjunction with the 8
byte ASCII Vendor Identifier in the RNC or RNC
Accept payload.
A value of 00 indicates the referenced document is not vendor unique.
A value of 01 indicates the referenced document is vendor unique. The vendor which defined the vendor unique document is the one
listed in the Vendor Identifier field of the current
RNC or RNC Accept payload.
A value of 10 indicates the referenced document is vendor unique, but it is defined by the
other N_Port. For example, if vendor A supports a unique profile y, then vendor As N_
103

dpANS X3.xxx-199x
Port would use a Vendor Unique flag value of
01 in the capability entry for profile y when it
sends an RNC request. If the request goes to
an N_Port made by vendor B, and the receiving N_Port is aware of and supports the profile
defined by vendor A, then vendor Bs N_Port
would indicate support for vendor As profile by
using a Vendor Unique flag value of 10 for the
capability entry for profile y, in the accept payload.

104

dpANS X3.xxx-199x

Index
A

OX_ID

ACC (Accept) 34
Address identifiers 22
Association_Header 29

P
Priority 22, 27??, 43, 52, 53??, 55
Process Policy 25, 66
Process_Associator 29
Profile 2, 36

C
Clock synchronization

D
Definitions

E
E_D_TOV 34
Resolution 31, 34, 43, 47, 49, 54, 66
Editorial conventions 2
Exchange management 58
Exchange Status Block 58
Extended Link Service commands
Read Timeout Value (RTV) 32, 34
Report
Vendor
Unique
Information
(RVU) 2, 33, 3539

F
F_CTL
Abort Sequence Condition
Fabric Login 88
FC-4 Region 2, 34

R_A_TOV 34
Read Timeout Value (RTV) 32, 34
Report Vendor Unique Information (RVU)
33, 3539
Request Clock Synchronization (REQCS)
78

S
Sequence 59
Sequence Status Block 59
Shielded twisted pair cable 18

T
Time Server 56
TV 17
TYPE 22, 82

V
Video cable

K
Key Distribution Server

L
Logout 89
Long video cable

M
Miniature coax cable
Multicast 29

N
N 89
N_Port Login

O
Optional headers
Association_Header

I-105

2,
2,

End of
Document

10/15/96

UGC NET Computer Science Previous Questions and Answer (PDFDrive)
No ratings yet
UGC NET Computer Science Previous Questions and Answer (PDFDrive)
313 pages
Designware Apb Ssi
No ratings yet
Designware Apb Ssi
226 pages
Siemens Hipath 2000 v2
No ratings yet
Siemens Hipath 2000 v2
324 pages
Small Form Factor Committee Specification Of: Status: Review
No ratings yet
Small Form Factor Committee Specification Of: Status: Review
224 pages
Siemens Hipath 2000 v1.0
No ratings yet
Siemens Hipath 2000 v1.0
282 pages
VSC7424-02, VSC7425-02, VSC7426-02, and VSC7427-02
No ratings yet
VSC7424-02, VSC7425-02, VSC7426-02, and VSC7427-02
772 pages
IBM Z Connectivity Handbook
No ratings yet
IBM Z Connectivity Handbook
216 pages
SG 245444
No ratings yet
SG 245444
216 pages
Entity Properties and Parameters 7 1 5
No ratings yet
Entity Properties and Parameters 7 1 5
623 pages
Installation Guide
0% (1)
Installation Guide
256 pages
Sinumerik 840
No ratings yet
Sinumerik 840
141 pages
Fibre Channel Docs
No ratings yet
Fibre Channel Docs
388 pages
GR 78 Corei02
No ratings yet
GR 78 Corei02
235 pages
FC PH PDF
No ratings yet
FC PH PDF
478 pages
Published SFF-8024
No ratings yet
Published SFF-8024
33 pages
Fibre Channel Interface
No ratings yet
Fibre Channel Interface
316 pages
Hipath 4000 Hipath 4500: Initial Installation/Startup
100% (1)
Hipath 4000 Hipath 4500: Initial Installation/Startup
292 pages
Mipi RFFE Specification v1-10
No ratings yet
Mipi RFFE Specification v1-10
90 pages
E84aycer Profinet Mci Module v3-0 en
No ratings yet
E84aycer Profinet Mci Module v3-0 en
101 pages
XMP1 System Description R5.5 PDF
No ratings yet
XMP1 System Description R5.5 PDF
374 pages
Errata Final Combinc4
No ratings yet
Errata Final Combinc4
78 pages
SG 248158
No ratings yet
SG 248158
280 pages
075366r01ZB AFG-ZigBee Cluster Library Public Download Version
No ratings yet
075366r01ZB AFG-ZigBee Cluster Library Public Download Version
420 pages
SFF-8024 R4.10
No ratings yet
SFF-8024 R4.10
30 pages
Fibre Channel Cable
No ratings yet
Fibre Channel Cable
170 pages
E84aycib Interbus Mci Module v4-0 en
No ratings yet
E84aycib Interbus Mci Module v4-0 en
75 pages
LIS Emerald22
No ratings yet
LIS Emerald22
48 pages
CELL-DYN Emerald
No ratings yet
CELL-DYN Emerald
48 pages
ECSS E 30part3a (25april2000) PDF
No ratings yet
ECSS E 30part3a (25april2000) PDF
66 pages
Z909-E1-01 Cs - CJ Eip21 Ethernet Ip Units
No ratings yet
Z909-E1-01 Cs - CJ Eip21 Ethernet Ip Units
77 pages
Understanding Zoning
No ratings yet
Understanding Zoning
108 pages
At API
No ratings yet
At API
224 pages
Eb-2013-00002 Reminder Meeting Minutes Requirements
No ratings yet
Eb-2013-00002 Reminder Meeting Minutes Requirements
1 page
11 329v0
No ratings yet
11 329v0
31 pages
Eb 2012 00375
No ratings yet
Eb 2012 00375
12 pages
OpenScape Voice V9, SIP To SP Interface Manual
No ratings yet
OpenScape Voice V9, SIP To SP Interface Manual
155 pages
Neca301 09 Foa Member P
100% (2)
Neca301 09 Foa Member P
38 pages
Published SFF-8024
No ratings yet
Published SFF-8024
32 pages
Space Engineering: Multipaction Design and Test
No ratings yet
Space Engineering: Multipaction Design and Test
88 pages
Network Buses
No ratings yet
Network Buses
125 pages
Fiber Saver (2029) Implementation Guide
No ratings yet
Fiber Saver (2029) Implementation Guide
256 pages
GR 909 TOC.i02
No ratings yet
GR 909 TOC.i02
20 pages
61992e PDF
No ratings yet
61992e PDF
177 pages
Iec 14165-115
No ratings yet
Iec 14165-115
11 pages
sg245444 - IBM Z Connectivity Handbook
No ratings yet
sg245444 - IBM Z Connectivity Handbook
238 pages
Migration To 400g 800g Part 2
No ratings yet
Migration To 400g 800g Part 2
25 pages
SFF Module Management Reference Code Tables
No ratings yet
SFF Module Management Reference Code Tables
29 pages
Tactical Communications Protocol 2
100% (2)
Tactical Communications Protocol 2
111 pages
Digital Logic Quiz for Students
No ratings yet
Digital Logic Quiz for Students
182 pages
E84aycer Profinet Mci Module v2-0 en
No ratings yet
E84aycer Profinet Mci Module v2-0 en
94 pages
Fast Multiplication Algorithms
No ratings yet
Fast Multiplication Algorithms
171 pages
Importing Exporting Project Data PDF
No ratings yet
Importing Exporting Project Data PDF
28 pages
CPL Lab Interview Questions
No ratings yet
CPL Lab Interview Questions
53 pages
1x9 Modules Eoptolink
No ratings yet
1x9 Modules Eoptolink
12 pages
Logic Families Mukesh
No ratings yet
Logic Families Mukesh
13 pages
Ex4200 Metro Ring With MX Series Head-End: Using Virtual Chassis Technology in The Wan
No ratings yet
Ex4200 Metro Ring With MX Series Head-End: Using Virtual Chassis Technology in The Wan
23 pages
Dte Unit 2
No ratings yet
Dte Unit 2
91 pages
Frequency Changer
No ratings yet
Frequency Changer
12 pages
Logic Design Lab Manual 2023/24
No ratings yet
Logic Design Lab Manual 2023/24
86 pages
Redes - Capa Fisica
No ratings yet
Redes - Capa Fisica
76 pages
Iso/Iec JTC 1/Sc N: New Work Item Proposal
No ratings yet
Iso/Iec JTC 1/Sc N: New Work Item Proposal
4 pages
Standards Feature Map: Henry May Lou Ricci 12/04/2012
No ratings yet
Standards Feature Map: Henry May Lou Ricci 12/04/2012
5 pages
Consideration of The Participants
No ratings yet
Consideration of The Participants
5 pages
Chapter 10 Digital Integrated Circuits
No ratings yet
Chapter 10 Digital Integrated Circuits
57 pages
32GFC SMF 10km Optical Proposal: Dave Lewis 1/3/2013 13-001v0
No ratings yet
32GFC SMF 10km Optical Proposal: Dave Lewis 1/3/2013 13-001v0
6 pages
Integrated Electronics Lab Manual MCE 2231
No ratings yet
Integrated Electronics Lab Manual MCE 2231
72 pages
Lynn Barra: Due by
No ratings yet
Lynn Barra: Due by
3 pages
Lynn Barra: Due by
No ratings yet
Lynn Barra: Due by
3 pages
MSQS-2 Teleconference Minutes 1/8/13
No ratings yet
MSQS-2 Teleconference Minutes 1/8/13
2 pages
Digital Electronics Lab Manual
No ratings yet
Digital Electronics Lab Manual
37 pages
Adopted International Standards
No ratings yet
Adopted International Standards
20 pages
Policies and Guidelines: Incits Rd-1
No ratings yet
Policies and Guidelines: Incits Rd-1
27 pages
Sav 4241
No ratings yet
Sav 4241
39 pages
DELD Unit I & Unit II MCQ
No ratings yet
DELD Unit I & Unit II MCQ
39 pages
1 Shortening FIP FLOGI Timeout
No ratings yet
1 Shortening FIP FLOGI Timeout
1 page
Interfacing Between ECL / LVECL / PECL / Lvpecl - To - TTL / LVTTL / Cmos / Lvcmos
No ratings yet
Interfacing Between ECL / LVECL / PECL / Lvpecl - To - TTL / LVTTL / Cmos / Lvcmos
6 pages
Call For Patents: Patent Declaration Form
No ratings yet
Call For Patents: Patent Declaration Form
1 page
INCITS Statement On The World Conference On International Telecommunications (WCIT)
No ratings yet
INCITS Statement On The World Conference On International Telecommunications (WCIT)
1 page
Eb 2012 00002
No ratings yet
Eb 2012 00002
1 page
Tipos de Contratos en Colombia
No ratings yet
Tipos de Contratos en Colombia
41 pages
Call For Patents: Patent Declaration Form
No ratings yet
Call For Patents: Patent Declaration Form
1 page
TTL
No ratings yet
TTL
35 pages
Vlsi Question Bank
No ratings yet
Vlsi Question Bank
10 pages
Installing and Testing Fiber Optics: NECA/FOA 301-2009
No ratings yet
Installing and Testing Fiber Optics: NECA/FOA 301-2009
38 pages
Logic Circuits for Engineering Students
No ratings yet
Logic Circuits for Engineering Students
36 pages
Digital Logic Families
No ratings yet
Digital Logic Families
7 pages
UM8717 - 2740-2745 Digitizers User Manual Rev6
No ratings yet
UM8717 - 2740-2745 Digitizers User Manual Rev6
60 pages
Sav 4221
No ratings yet
Sav 4221
28 pages
Nist HB105 5 1997
No ratings yet
Nist HB105 5 1997
15 pages
Comparison of I C Logic Families
No ratings yet
Comparison of I C Logic Families
2 pages
Telcordia GR-771-Documentation Information
No ratings yet
Telcordia GR-771-Documentation Information
6 pages
1340TNPC Agere Systems
No ratings yet
1340TNPC Agere Systems
12 pages
Digital Electronics
No ratings yet
Digital Electronics
19 pages
Digital Electronics Lab Sample Questions
No ratings yet
Digital Electronics Lab Sample Questions
12 pages
UNIT-5: Realization of Logic Gates and Sampling Gates
No ratings yet
UNIT-5: Realization of Logic Gates and Sampling Gates
11 pages
DCHD Assignment
No ratings yet
DCHD Assignment
8 pages
Digital Logic Families - Electronics Tutorial
100% (1)
Digital Logic Families - Electronics Tutorial
7 pages
5 - Mux - Model 907 Ecl Sonar
No ratings yet
5 - Mux - Model 907 Ecl Sonar
2 pages
Vlsi Design Thesis Topics
100% (2)
Vlsi Design Thesis Topics
8 pages
Logic Families: CMOS, TTL, ECL
No ratings yet
Logic Families: CMOS, TTL, ECL
5 pages
AMCA204-05 (R2012) - Balance Quality and Vibration Levels For Fans
100% (1)
AMCA204-05 (R2012) - Balance Quality and Vibration Levels For Fans
25 pages
API Stan Ndard RD 2R RD: Dynam Mic Ris Sers For Floatin NG Prod Duction System Ms
No ratings yet
API Stan Ndard RD 2R RD: Dynam Mic Ris Sers For Floatin NG Prod Duction System Ms
3 pages
ASME BPVC User & Manufacturer Guide
No ratings yet
ASME BPVC User & Manufacturer Guide
1 page