(IPv6) Specification", RFC 2460, December 1998.
[AARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[PMTUD] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[IEEE-LLC] IEEE Std 802-2001, "IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture".
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References
[IPFC] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP
over Fibre Channel", RFC 2625, June 1999.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)",
http://standards.ieee.org/db/oui/tutorials/EUI64.html
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[IPv6-1394] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
over IEEE 1394 Networks", RFC 3146, October 2001.
A. Transmission of a Broadcast FC Sequence over FC Topologies
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].
a) 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.
b) The source NL_Port then removes the OPN(fr) signal when it returns
to it.
c) 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 which 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
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 LIP in a loop topology
[FC-AL-2] or after 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 LR. In a point-to-point topology,
NOS/OLS causes implicit Logout of each N_Port and after a 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 either ADISC or
PDISC [FC-FS].
For a requester, this specification prohibits PDISC and requires
ADISC. As a responder, an implementation may need to respond to both
ADISC and PDISC for compatibility with other FC specifications.
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 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.
B.5. FC Layer Address Validation in a Fabric Topology
No validation is required after LR (link reset).
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 21 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 21: Fibre Channel Bit Numbering
Author’s Address
Claudio DeSanti
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 853-9172
EMail: cds@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 currently provided by the
Internet Society.