sender and receiver. With the exceptions of SOF and EOF [3] all
discussion of FC frame content in this document is at the 8-bit byte
level, prior to the application of any such encoding.
The 8-bit bytes in the FC frame content can be translated directly
for transmission over an IP Network. However, the FC SOF and EOF
employ special 10b characters that have no 8b equivalents. Therefore,
special byte placement and 8-bit character encodings are required to
represent SOF and EOF.
5.2. Bit and Byte Ordering
The Encapsulation Header, SOF, FC frame content (see section 5.1),
and EOF are mapped to TCP using the big endian byte ordering, which
corresponds to the standard network byte order or canonical form [7].
5.3. FC SOF and EOF
As described in section 5.1, representation of FC SOF and EOF in an
IP Network byte stream requires special formatting and 8-bit code
definitions. Therefore, the encapsulated FC frame SHALL have the
format shown in Figure 5. The redundancy of the SOF/EOF
representation in the encapsulation format results from concerns that
the information be protected from transmission errors.
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+-------------------------------+
0| SOF | SOF | -SOF | -SOF |
+---------------+---------------+-------------------------------+
1| |
+----- FC frame content -----+
| |
+---------------+---------------+-------------------------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+-------------------------------+
Figure 5 - FC Frame Encapsulation Format
Note: The number of 8-bit bytes in the FC frame content is always a
multiple of four.
SOF: The SOF fields contain the encoded SOF value selected from table
2.
+-------+------+-------+ +-------+------+-------+
| FC | SOF | | | FC | SOF | |
| SOF | Code | Class | | SOF | Code | Class |
+-------+------+-------+ +-------+------+-------+
| SOFf | 0x28 | F | | SOFi4 | 0x29 | 4 |
| SOFi2 | 0x2D | 2 | | SOFn4 | 0x31 | 4 |
| SOFn2 | 0x35 | 2 | | SOFc4 | 0x39 | 4 |
| SOFi3 | 0x2E | 3 | +-------+------+-------+
| SOFn3 | 0x36 | 3 |
+-------+------+-------+
Table 2 Translation of FC SOF values to SOF field contents
-SOF: The -SOF fields contain the one’s complement of the value in
the SOF fields. Encapsulation receivers SHOULD validate the SOF
field according to a policy defined by the encapsulating protocol.
EOF: The EOF fields contain the encoded EOF value selected from
table 3.
+-------+------+---------+ +--------+------+-------+
| FC | EOF | | | FC | EOF | |
| EOF | Code | Class | | EOF | Code | Class |
+-------+------+---------+ +--------+------+-------+
| EOFn | 0x41 | 2,3,4,F | | EOFdt | 0x46 | 4 |
| EOFt | 0x42 | 2,3,4,F | | EOFdti | 0x4E | 4 |
| EOFni | 0x49 | 2,3,4,F | | EOFrt | 0x44 | 4 |
| EOFa | 0x50 | 2,3,4,F | | EOFrti | 0x4F | 4 |
+-------+------+---------+ +--------+------+-------+
Table 3 Translation of FC EOF values to EOF field contents
-EOF: The -EOF fields contain the one’s complement of the value in
the EOF fields. Encapsulation receivers SHOULD validate the EOF
field according to a policy defined by the encapsulating protocol.
Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 2 and
table 3 (e.g., SOFi1 and SOFn1). However, FC-MI [8] identifies these
codes as not interoperable, so they are not listed in this
specification.
6. Security Considerations
This document describes the encapsulation format only. Actual use of
this format in a encapsulating protocol requires an additional
document to specify the encapsulating protocol functionality and
appropriate security considerations. Because security considerations
for this encapsulation depend on how it is used by encapsulating
protocols, they SHALL be described in encapsulating protocol specific
documents.
7. References
7.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Fibre Channel Framing and Signaling (FC-FS), ANSI
INCITS.373:2003, October 27, 2003. Note: Published T11 standards
are available from the INCITS online store
http://www.incits.org, or the ANSI online store,
http://www.ansi.org.
[4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:2001,
December 12, 2002. Note: Published T11 standards are available
from the INCITS online store http://www.incits.org, or the ANSI
online store, http://www.ansi.org.
[5] Fibre Channel Physical Interfaces (FC-PI), ANSI NCITS.352:2002,
December 1, 2002. Note: Published T11 standards are available
from the INCITS online store http://www.incits.org, or the ANSI
online store, http://www.ansi.org.
[6] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July
25, 2003. Note: Published T11 standards are available from the
INCITS online store http://www.incits.org, or the ANSI online
store, http://www.ansi.org.
[7] Narten, T. and C. Burton, "A Caution on The Canonical Ordering
of Link-Layer Addresses", RFC 2469, December 1998.
7.2. Informative References
[8] Fibre Channel Methodologies for Interconnects (FC-MI), ANSI
INCITS/TR-30:2002, November 1, 2002. Note: Published T11
standards are available from the INCITS online store
http://www.incits.org, or the ANSI online store,
http://www.ansi.org.
[9] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 2030, October 1996.
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[11] Rajagopal, M., Rodriguez, E., Weber, R., "Fibre Channel Over
TCP/IP (FCIP)", Work in Progress.
[12] Monia, C., et. al., "iFCP - A Protocol for Internet Fibre
Channel Storage Networking", Work in Progress.
8. Acknowledgements
The authors express their appreciation to Mr. Vi Chau
(vchau1@cox.net) for his contributions to the design team that
developed this document. Mr. Chau is no longer working in this
technology.
The authors are also grateful to Dr. David Black, Mr. Mallikarjun
Chadalapaka, and Mr. Robert Elliott for their reviews of this
specification.
Appendix A - Fibre Channel Bit and Byte Numbering Guidance
Both Fibre Channel and IETF standards use the same byte transmission
order. However, the bit and byte numbering is different.
Fibre Channel bit and byte numbering can be observed if the data
structure heading shown in Figure 6, is cut and pasted at the top of
Figure 2 and Figure 5.
W|------------------------------Bit------------------------------|
o| |
r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 |
d|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 6 - Fibre Channel Data Structure Bit and Byte Numbering
Fibre Channel bit numbering for the Flags field can be observed if
the data structure heading shown in Figure 7, is cut and pasted at
the top of Figure 3.
|------------------------Bit--------------------------|
| |
| 31 30 29 28 27 26 |
Figure 7 - Fibre Channel Flags Bit Numbering
Appendix B - Encapsulating Protocol Requirements
This appendix lists the requirements placed on the encapsulating
protocols that employ this encapsulation. The requirements listed
here are suggested or described elsewhere in this document, but their
collection in this appendix serves to assist encapsulating protocol
authors in meeting all obligations placed upon them.
Encapsulating Protocol Specific Data
Encapsulating protocols employing this encapsulation SHALL:
- specify the IANA assigned number used in the Protocol# field
- specify the contents of the Encapsulating Protocol Specific field
Encapsulating protocols employing this encapsulation SHALL define the
procedures and policies necessary for verifying that an FC
Encapsulation Header is being processed.
Encapsulating protocols employing this encapsulation SHALL define the
procedures and policies necessary for the detection of over age
frames. The items to be specified and the choices available to an
encapsulating protocol specification are as follows:
a) The encapsulating protocol requirements for measuring transit
times. The encapsulating protocol MAY allow implementation of
transit time measurement to be optional.
b) The requirements or guidelines for stability and resolution of the
entity’s time base.
c) The procedure for synchronizing an entity’s time base, including
the criteria for entering the Synchronized and Unsynchronized
states.
d) The forwarding (or lack of forwarding) of frame traffic while in
the Unsynchronized state.
The specification MAY allow an entity in the Unsynchronized state
to continue processing frame traffic.
e) The procedure to be followed when frames are received that do not
have a valid time stamp.
The specification MAY allow such frames to be accepted by the
entity.
f) Requirements for setting and testing the transit time limit and
the procedure to be followed when a received frame is discarded
due to its transit time exceeding the limit.
Appendix C - IANA Considerations
The Protocol# (Protocol Number) field is an identifier number used to
distinguish between the encapsulating protocols that employ this FC
frame encapsulation. Values used in the Protocol# field are to be
assigned from a new, separate registry that is maintained by IANA.
All values in the Protocol# field are to be registered with and
assigned by IANA with the following exceptions.
- Protocol# value 0 should not be assigned until after all other
values have been assigned.
- Protocol# values 240-255 inclusive must be set aside for private
use amongst cooperating systems.
Following the policies outlined in [10], Protocol# values not listed
above are to be assigned only for Standards Track RFCs approved by
the IESG.
In addition to creating the FC Frame Encapsulation Protocol Number
Registry, the standards action of this RFC allocates the following
two values from the registry:
- Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/
IP) encapsulating protocol [11].
- Protocol# value 2 assigned to the iFCP (A Protocol for Internet
Fibre Channel Storage Networking) encapsulating protocol [12].
Appendix D - Intellectual Property Rights Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF’s procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Authors’ Addresses
Ralph Weber
ENDL Texas
representing Brocade Comm.
Suite 102 PMB 178
18484 Preston Road
Dallas, TX 75252
USA
Phone: +1 214 912 1373
EMail: roweber@ieee.org
Murali Rajagopal
Broadcom
16215 Alton Parkway
PO Box 57013
Irvine, CA 92619
USA
Phone: +1 949 450 8700
EMail: muralir@broadcom.com
Franco Travostino
Technology Center
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821
USA
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com
Michael E. O’Donnell
McDATA Corporation
4 McDATA Parkway
Broomfield, Co. 80021
USA
Phone +1 720 558 4142
Fax +1 720 558 8999
EMail: mike.o’donnell@mcdata.com
Charles Monia
EMail: cmonia@pacbell.net
Milan J. Merhar
Sun Microsystems
43 Nagog Park
Acton, MA 01720
USA
Phone: +1 978 206 9124
EMail: milan.merhar@sun.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.