[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/
EUI64.html
A. Transmission of a Broadcast FC Sequence over FC Topologies
(Informative)
A.1. Point-to-Point Topology
No particular mechanisms are required for this case. The Nx_Port
connected at the other side of the cable receives the broadcast FC
Sequence having D_ID 0xFFFFFF.
A.2. Private Loop Topology
An NL_Port attached to a private loop must transmit a Class 3
broadcast FC Sequence by using the OPN(fr) primitive signal
[FC-AL-2].
1) The source NL_Port first sends an Open Broadcast Replicate
(OPN(fr)) primitive signal, forcing all the NL_Ports in the loop
(except itself) to replicate the frames that they receive while
examining the FC Header’s D_ID field.
2) The source NL_Port then removes the OPN(fr) signal when it returns
to it.
3) The source NL_Port then sends the Class 3 broadcast FC Sequence
having D_ID 0xFFFFFF.
A.3. Public Loop Topology
An NL_Port attached to a public loop must not use the OPN(fr)
primitive signal. Rather, it must send the Class 3 broadcast FC
Sequence having D_ID 0xFFFFFF to the FL_Port at AL_PA = 0x00
[FC-AL-2].
The Fabric propagates the broadcast to all other FC_Ports [FC-FS],
including the FL_Port that the broadcast arrives on. This includes
all F_Ports, and other FL_Ports.
Each FL_Port propagates the broadcast by using the primitive signal
OPN(fr), in order to prepare the loop to receive the broadcast
sequence.
A.4. Fabric Topology
An N_Port connected to an F_Port must transmit the Class 3 broadcast
FC Sequence having D_ID 0xFFFFFF to the F_Port. The Fabric
propagates the broadcast to all other FC_Ports [FC-FS].
B. Validation of the <N_Port_Name, N_Port_ID> Mapping
(Informative)
B.1. Overview
At all times, the <N_Port_Name, N_Port_ID> mapping must be valid
before use.
After an FC link interruption occurs, the N_Port_ID of an Nx_Port may
change, as well as the N_Port_IDs of all other Nx_Ports that have
previously performed Port Login with this Nx_Port. Because of this,
address validation is required after a Loop Initialization Primitive
Sequence (LIP) in a loop topology [FC-AL-2] or after Not_Operational
Primitive Sequence / Offline Primitive Sequence (NOS/OLS) in a
point-to-point topology [FC-FS].
N_Port_IDs do not change as a result of Link Reset (LR) [FC-FS];
thus, address validation is not required in this case.
B.2. FC Layer Address Validation in a Point-to-Point Topology
No validation is required after Link Reset (LR). In a point-to-point
topology, NOS/OLS causes implicit Logout of each N_Port and after an
NOS/OLS each N_Port must again perform a Port Login [FC-FS].
B.3. FC Layer Address Validation in a Private Loop Topology
After a LIP [FC-AL-2], an NL_Port must not transmit any data to
another NL_Port until the address of the other port has been
validated. The validation consists of completing the Address
Discovery procedure with the ADISC ELS [FC-FS].
If the three FC addresses (N_Port_ID, N_Port_Name, Node_Name) of a
logged remote NL_Port exactly match the values prior to the LIP, then
any active Exchange with that NL_Port may continue.
If any of the three FC addresses has changed, then the remote NL_Port
must be logged out.
If an NL_Port’s N_Port_ID changes after a LIP, then all active
logged-in NL_Ports must be logged out.
B.4. FC Layer Address Validation in a Public Loop Topology
A Fabric Address Notification (FAN) ELS may be sent by the Fabric to
all known previously logged-in NL_Ports following an initialization
event. Therefore, after a LIP [FC-AL-2], NL_Ports may wait for this
notification to arrive, or they may perform an FLOGI.
If the F_Port_Name and Fabric_Name contained in the FAN ELS or FLOGI
response exactly match the values before the LIP and if the AL_PA
[FC-AL-2] obtained by the NL_Port is the same as the one before the
LIP, then the port may resume all Exchanges. If not, then FLOGI must
be performed with the Fabric and all logged-in Nx_Ports must be
logged out.
A public loop NL_Port must perform the private loop validation as
specified in section B.3 to any NL_Port on the local loop that has an
N_Port_ID of the form 0x00-00-XX (i.e., to any private loop NL_Port).
B.5. FC Layer Address Validation in a Fabric Topology
No validation is required after Link Reset (LR).
After NOS/OLS, an N_Port must perform FLOGI. If, after FLOGI, the
N_Port’s N_Port_ID, the F_Port_Name, and the Fabric_Name are the same
as before the NOS/OLS, then the N_Port may resume all Exchanges. If
not, all logged-in Nx_Ports must be logged out [FC-FS].
C. Fibre Channel Bit and Byte Numbering Guidance
Both Fibre Channel and IETF standards use the same byte transmission
order. However, the bit numbering is different.
Fibre Channel bit numbering can be observed if the data structure
heading shown in figure 24 is cut and pasted at the top of the
figures present in this document.
3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Fibre Channel Bit Numbering
D. Changes from RFC 2625
- Nx_Ports with N_Port_Name format 0x2, 0x5, 0xC, 0xD, 0xE, and 0xF
are supported, in addition to format 0x1;
- An IP-capable Nx_Port MUST support Class 3;
- An IP-capable Nx_Port MUST support continuously increasing
SEQ_CNT;
- An IP-capable Nx_Port SHOULD support a receive data field size for
Device_Data FC frames of at least 1024 octets;
- The FC ESP_Header MAY be used;
- FC Classes of services other than 3 are not recommended;
- Defined a new FC ARP format;
- Removed support for FARP because some FC implementations do not
tolerate receiving broadcast ELSes;
- Added support for IPv4 multicast;
- Clarified the usage of the CS_CTL and Parameter fields of the FC
Header;
- Clarified the usage of FC Classes of service;
- Clarified the usage of FC Sequences and Exchanges.
E. Changes from RFC 3831
- Clarified the usage of the CS_CTL and Parameter fields of the FC
Header;
- Clarified the usage of FC Classes of service;
- Clarified and updated the mapping of IPv6 multicast on Fibre
Channel;
- Clarified the usage of FC Sequences and Exchanges;
- Clarified and updated the format of the Neighbor Discovery
Link-layer option for Fibre Channel.
Authors’ Addresses
Claudio DeSanti
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 853-9172
EMail: cds@cisco.com
Craig W. Carlson
QLogic Corporation
6321 Bury Drive
Eden Prairie, MN 55346
USA
Phone: +1 952 932-4064
EMail: craig.carlson@qlogic.com
Robert Nixon
Emulex
3333 Susan Street
Costa Mesa, CA 92626
USA
Phone: +1 714 885-3525
EMail: bob.nixon@emulex.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).