RFC 3821
Fibre Channel Over TCP/IP (FCIP)
11. References
11.1. Normative References
The references in this section were current as of the time this specification was approved. This specification is intended to operate with newer versions of the referenced documents and looking for newer reference documents is recommended. [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Fibre Channel Backbone (FC-BB), ANSI INCITS.342:2001, December 12, 2001. [3] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July 25, 2003. [4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI INCITS.355:2001, December 12, 2001. [5] Fibre Channel Framing and Signaling (FC-FS), ANSI INCITS.373:2003, October 27, 2003. [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[7] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989. [8] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [10] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [13] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998. [14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [15] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [16] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [17] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999. [18] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "SACK Extension", RFC 2883, July 2000. [19] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia, C. and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003. [20] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", RFC 3822, July 2004. [21] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[22] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003. [23] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.11.2. Informative References
[24] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [25] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [26] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [27] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. [28] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and Ipv6 Headers", RFC 2474, December 1998. [29] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [30] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "An Assured Forwarding PHB", RFC 2597, June 1999. [31] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB Group", RFC 2598, June 1999. [32] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January, 2001. [33] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003. [34] Kembel, R., "The Fibre Channel Consultant: A Comprehensive Introduction", Northwest Learning Associates, 1998.
12. Acknowledgments
The developers of this specification thank Mr. Jim Nelson for his assistance with FC-FS related issues. The developers of this specification express their appreciation to Mr. Mallikarjun Chadalapaka and Mr. David Black for their detailed and helpful reviews.
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 11, is cut and pasted at the top of figure 7, figure 9, and figure 17. 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 11: Fibre Channel Data Structure Bit and Byte Numbering Fibre Channel bit numbering for the pFlags field can be observed if the data structure heading, shown in figure 12, is cut and pasted at the top of figure 8. |----------------Bit--------------------| | | | 31 30 29 28 27 26 25 24 | Figure 12: Fibre Channel pFlags Bit Numbering Fibre Channel bit numbering for the Connection Usage Flags field can be observed if the data structure heading, shown in figure 13, is cut and pasted at the top of figure 10. |------------------------------Bit------------------------------| | | | 31 30 29 28 27 26 25 24 | Figure 13: Fibre Channel Connection Usage Flags Bit NumberingAppendix B. IANA Considerations
IANA has made the following port assignments to FCIP: - fcip-port 3225/tcp FCIP - fcip-port 3225/udp FCIP IANA has changed the authority for these port allocations to reference this RFC. Use of UDP with FCIP is prohibited even though IANA has allocated a port.
The FC Frame encapsulation used by this specification employs Protocol# value 1, as described in the IANA Considerations appendix of the FC Frame Encapsulation [19] specification.Appendix C. FCIP Usage of Addresses and Identifiers
In support of network address translators, FCIP does not use IP Addresses to identify FCIP Entities or FCIP_LEPs. The only use of IP Addresses for identification occurs when initiating new TCP connect requests (see section 8.1.2.3) where the IP Address destination of the TCP connect request is used to answer the question: "Have previous TCP connect requests been made to the same destination FCIP Entity?" The correctness of this assumption is further checked by sending the Destination FC Fabric Entity World Wide Name in the FCIP Special Frame (FSF) and having the value checked by the FCIP Entity that receives the TCP connect request and FSF (see section 8.1.3). For the purposes of processing incoming TCP connect requests, the source FCIP Entity is identified by the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier fields in the FSF sent from the TCP connect requestor to the TCP connect recipient as the first bytes following the TCP connect request (see section 8.1.2.3 and section 8.1.3). FC-BB-2 [3] provides the definitions for each of the following FSF fields: - Source FC Fabric Entity World Wide Name, - Source FC/FCIP Entity Identifier, and - Destination FC Fabric Entity World Wide Name. As described in section 8.1.3, FCIP Entities segregate their FCIP_LEPs between: - Connections resulting from TCP connect requests initiated by the FCIP Entity, and - Connections resulting from TCP connect requests received by the FCIP Entity. Within each of these two groups, the following information is used to further identify each FCIP_LEP: - Source FC Fabric Entity World Wide Name, - Source FC/FCIP Entity Identifier, and - Destination FC Fabric Entity World Wide Name.
Appendix D. Example of Synchronization Recovery Algorithm
The contents of this annex are informative. Synchronization may be recovered as specified in section 5.6.2.3. An example of an algorithm for searching the bytes delivered to the Encapsulated Frame Receiver Portal for a valid FCIP Frame header is provided in this annex. This resynchronization uses the principle that a valid FCIP data stream must contain at least one valid header every 2176 bytes (the maximum length of an encapsulated FC Frame). Although other data patterns containing apparently valid headers may be contained in the stream, the FC CRC or FCIP Frame validity of the data patterns contained in the data stream will always be either interrupted by or resynchronized with the valid FCIP Frame headers. Consider the case shown in figure 14. A series of short FCIP Frames, perhaps from a trace, are embedded in larger FCIP Frames, say as a result of a trace file being transferred from one disk to another. The headers for the short FCIP Frames are denoted SFH and the long FCIP Frame headers are marked as LFH. +-+--+-+----+-+----+-+----+-+-+-+---+-+--- |L| |S| |S| |S| |S| |L| |S| |F| |F| |F| |F| |F| |F| |F|... |H| |H| |H| |H| |H| |H| |H| +-+--+-+----+-+----+-+----+-+-+-+---+-+--- | | |<---------2176 bytes-------->| Figure 14: Example of resynchronization data stream A resynchronization attempt that starts just to the right of an LFH will find several SFH FCIP Frames before discovering that they do not represent the transmitted stream of FCIP Frames. Within 2176 bytes plus or minus, however, the resynchronization attempt will encounter an SFH whose length does not match up with the next SFH because the LFH will fall in the middle of the short FCIP Frame pushing the next header farther out in the byte stream. Note that the resynchronization algorithm cannot forward any prospective FC Frames to the FC Frame Transmitter Portal because, until synchronization is completely established, there is no certainty that anything that looked like an FCIP Frame really was one. For example, an SFH might fortuitously contain a length that
points exactly to the beginning of an LFH. The LFH would identify
the correct beginning of a transmitted FCIP Frame, but that in no way
guarantees that the SFH was also a correct FCIP Frame header.
There exist some data streams that cannot be resynchronized by this
algorithm. If such a data stream is encountered, the algorithm
causes the TCP Connection to be closed.
The resynchronization assumes that security and authentication
procedures outside the FCIP Entity are protecting the valid data
stream from being replaced by an intruding data stream containing
valid FCIP data.
The following steps are one example of how an FCIP_DE might
resynchronize with the data stream entering the Encapsulated Frame
Receiver Portal.
1) Search for candidate and strong headers:
The data stream entering the Encapsulated Frame Receiver Portal is
searched for 12 bytes in a row containing the required values for:
a) Protocol field,
b) Version field,
c) ones complement of the Protocol field,
d) ones complement of the Version field,
e) replication of encapsulation word 0 in word 1, and
f) pFlags field and its ones complement.
If such a 12-byte grouping is found, the FCIP_DE assumes that it
has identified bytes 0-2 of a candidate FCIP encapsulation header.
All bytes up to and including the candidate header byte are
discarded.
If no candidate header has been found after searching a specified
number of bytes greater than some multiple of 2176 (the maximum
length of an FCIP Frame), resynchronization has failed and the
TCP/IP connection is closed.
Word 3 of the candidate header contains the Frame Length and Flags
fields and their ones complements. If the fields are consistent
with their ones complements, the candidate header is considered a
strong candidate header. The Frame Length field is used to
determine where in the byte stream the next strong candidate
header should be and processing continues at step 2).
2) Use multiple strong candidate headers to locate a verified
candidate header:
The Frame Length in one strong candidate header is used to skip
incoming bytes until the expected location of the next strong
candidate header is reached. Then the tests described in step 1)
are applied to see if another strong candidate header has
successfully been located.
All bytes skipped and all bytes in all strong candidate headers
processed are discarded.
Strong candidate headers continue to be verified in this way for
at least 4352 bytes (twice the maximum length of an FCIP Frame).
If at any time a verification test fails, processing restarts at
step 1 and a retry counter is incremented. If the retry counter
exceeds 3 retries, resynchronization has failed and the TCP
Connection is closed, and the FC entity is notified with the
reason for the closure.
After strong candidate headers have been verified for at least
4352 bytes, the next header identified is a verified candidate
header, and processing continues at step 3).
Note: If a strong candidate header was part of the data content of
an FCIP Frame, the FCIP Frame defined by that or a subsequent
strong candidate header will eventually cross an actual header in
the byte stream. As a result it will either identify the actual
header as a strong candidate header or it will lose
synchronization again because of the extra 28 bytes in the length,
returning to step 1 as described above.
3) Use multiple strong candidate headers to locate a verified
candidate header:
Incoming bytes are inspected and discarded until the next verified
candidate header is reached. Inspection of the incoming bytes
includes testing for other candidate headers using the criteria
described in step 1. Each verified candidate header is tested
against the tests listed in section 5.6.2.2 as would normally be
the case.
Verified candidate headers continue to be located and tested in
this way for a minimum of 4352 bytes (twice the maximum length of
an FCIP Frame). If all verified candidate headers encountered are
valid, the last verified candidate header is a valid header. At
this point the FCIP_DE stops discarding bytes and begins normal
FCIP de-encapsulation, including for the first time since
synchronization was lost, delivery of FC Frames through the FC
Frame Transmitter Portal according to normal FCIP rules.
If any verified candidate headers are invalid but meet all the
requirements of a strong candidate header, increment the retry
counter and return to step 2). If any verified candidate headers
are invalid and fail to meet the tests for a strong candidate
header, or if inspection of the bytes between verified candidate
headers discovers any candidate headers, increment the retry
counter and return to step 1. If the retry counter exceeds 4
retries, resynchronization has failed and the TCP/IP connection is
closed.
A flowchart for this algorithm can be found in figure 15.
Synchronization is lost
|
_____________v_______________
| |
| Search for candidate header |
+----------->| |
| | Found Not Found |
| | (Strong candidate) |
| |_____________________________|
| | |
| | + --------->close TCP
| _______v_____________________ Connection
| | | and notify
| | Enough strong candidate | the FC Entity
| +---->| headers identified? | with the reason
| | | | for closure
| | | No Yes |
| | | (Verified candidate) |
| | |_____________________________|
|___________________| |
^ | |
| | |
| | _______________________v_____
| | | |
| | | Enough verified candidate |
| | | headers validated? |
| | | |
| | | No Yes |
| | | (Resynchronized) |
| | |_____________________________|
| | | |
| | ______v__________ | Resume
| | | | + ---> Normal
| | | Synchronization | De-encapsulation
| | | Lost? |
| | | |
| | | No Yes |
| | |_________________|
| | | |
| |________| |
|___________________________|
Figure 15: Flow diagram of simple synchronization example
Appendix E. Relationship between FCIP and IP over FC (IPFC)
The contents of this annex are informative. IPFC (RFC 2625) describes the encapsulation of IP packets in FC Frames. It is intended to facilitate IP communication over an FC network. FCIP describes the encapsulation of FC Frames in TCP segments, which in turn are encapsulated inside IP packets for transporting over an IP network. It gives no consideration to the type of FC Frame that is being encapsulated. Therefore, the FC Frame may actually contain an IP packet as described in the IP over FC specification (RFC 2625). In such a case, the data packet would have: - Data Link Header - IP Header - TCP Header - FCIP Header - FC Header - IP Header Note: The two IP headers would not be identical to each other. One would have information pertaining to the final destination, while the other would have information pertaining to the FCIP Entity. The two documents focus on different objectives. As mentioned above, implementation of FCIP will lead to IP encapsulation within IP. While perhaps inefficient, this should not lead to issues with IP communication. One caveat: if a Fibre Channel device is encapsulating IP packets in an FC Frame (e.g., an IPFC device), and that device is communicating with a device running IP over a non-FC medium, a second IPFC device may need to act as a gateway between the two networks. This scenario is not specifically addressed by FCIP. There is nothing in either of the specifications to prevent a single device from implementing both FCIP and IP-over-FC (IPFC), but this is implementation specific, and is beyond the scope of this document.
Appendix F. FC Frame Format
Note: All users of the words "character" or "characters" in this section refer to 8bit/10bit link encoding wherein each 8 bit "character" within a link frame is encoded as a 10 bit "character" for link transmission. These words do not refer to ASCII, Unicode, or any other form of text characters, although octets from such characters will occur as 8 bit "characters" for this encoding. This usage is employed here for consistency with the ANSI T11 standards that specify Fibre Channel. The contents of this annex are informative. All FC Frames have a standard format (see FC-FS [5]) much like LAN's 802.x protocols. However, the exact size of each FC Frame varies depending on the size of the variable fields. The size of the variable field ranges from 0 to 2112-bytes as shown in the FC Frame Format in figure 16, resulting in the minimum size FC Frame of 36 bytes and the maximum size FC Frame of 2148 bytes. Valid FC Frame lengths are always a multiple of four bytes. +------+--------+-----------+----//-------+------+------+ | SOF |Frame |Optional | Frame | CRC | EOF | | (4B) |Header |Header | Payload | (4B) | (4B) | | |(24B) |<----------------------->| | | | | | Data Field = (0-2112B) | | | +------+--------+-----------+----//-------+------+------+ Figure 16: FC Frame Format SOF and EOF Delimiters On an FC link, Start-of-Frame (SOF) and End-Of-Frame (EOF) are called Ordered Sets and are sent as special words constructed from the 8B/10B comma character (K28.5) followed by three additional 8B/10B data characters making them uniquely identifiable in the data stream. On an FC link, the SOF delimiter serves to identify the beginning of an FC Frame and prepares the receiver for FC Frame reception. The SOF contains information about the FC Frame's Class of Service, position within a sequence, and in some cases, connection status. The EOF delimiter identifies the end of the FC Frame and the final FC Frame of a sequence. In addition, it serves to force the running disparity to negative. The EOF is used to end the connection in connection-oriented classes of service.
A special EOF delimiter called EOFa (End Of Frame - Abort) is used
to terminate a partial FC Frame resulting from a malfunction in a
link facility during transmission. Since an FCIP Entity functions
like a transmission link with respect to the rest of the FC
Fabric, FCIP_DEs may use EOFa in their error recovery procedures.
It is therefore important to preserve the information conveyed by
the delimiters across the IP-based network, so that the receiving
FCIP Entity can correctly reconstruct the FC Frame in its original
SOF and EOF format before forwarding it to its ultimate FC
destination on the FC link.
When an FC Frame is encapsulated and sent over a byte-oriented
interface, the SOF and EOF delimiters are represented as sequences
of four consecutive bytes, which carry the equivalent Class of
Service and FC Frame termination information as the FC ordered
sets.
The representation of SOF and EOF in an encapsulation FC Frame is
described in FC Frame Encapsulation [19].
Frame Header
The FC Frame Header is transparent to the FCIP Entity. The FC
Frame Header is 24 bytes long and has several fields that are
associated with the identification and control of the payload.
Current FC Standards allow up to 3 Optional Header fields [5]:
- Network_Header (16-bytes)
- Association_Header (32-bytes)
- Device_Header (up to 64-bytes).
Frame Payload
The FC Frame Payload is transparent to the FCIP Entity. An FC
application level payload is called an Information Unit at the
FC-4 Level. This is mapped into the FC Frame Payload of the FC
Frame. A large Information Unit is segmented using a structure
consisting of FC Sequences. Typically, a Sequence consists of
more than one FC Frame. FCIP does not maintain any state
information regarding the relationship of FC Frames within an FC
Sequence.
CRC
The FC CRC is 4 bytes long and uses the same 32-bit polynomial
used in FDDI and is specified in ANSI X3.139 Fiber Distributed
Data Interface. This CRC value is calculated over the entire FC
header and the FC payload; it does not include the SOF and EOF
delimiters.
Note: When FC Frames are encapsulated into FCIP Frames, the FC
Frame CRC is untouched by the FCIP Entity.
Appendix G. FC Encapsulation Format
This annex contains a reproduction of the FC Encapsulation Format
[19] as it applies to FCIP Frames that encapsulate FC Frames. The
information in this annex is not intended to represent the FCIP
Special Frame (FSF) that is described in section 7.
The information in this annex was correct as of the time this
specification was approved. The information in this annex is
informative only.
If there are any differences between the information here and the FC
Encapsulation Format specification [19], the FC Encapsulation Format
specification takes precedence.
If there are any differences between the information here and the
contents of section 5.6.1, then the contents of section 5.6.1 take
precedence.
Figure 17 applies the requirements stated in section 5.6.1 and in the
FC Encapsulation Frame format resulting in a summary of the FC Frame
format. Where FCIP requires specific values, those values are shown
in hexadecimal in parentheses. Detailed requirements for the FCIP
usage of the FC Encapsulation Format are in section 5.6.1.
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| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 1| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 2| pFlags | Reserved | -pFlags | -Reserved | | (0x00) | (0x00) | (0xFF) | (0xFF) | +-----------+---+---------------+-----------+---+---------------+ 3| Flags | Frame Length | -Flags | -Frame Length | | (0x00) | | (0x3F) | | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC (Reserved in FCIP) | | (0x00-00-00-00) | +---------------+---------------+---------------+---------------+ 7| SOF | SOF | -SOF | -SOF | +---------------+---------------+---------------+---------------+ 8| | +----- FC Frame content (see appendix F) -----+ | | +---------------+---------------+---------------+---------------+ n| EOF | EOF | -EOF | -EOF | +---------------+---------------+---------------+---------------+ Figure 17: FCIP Frame Format The names of fields are generally descriptive on their contents and the FC Encapsulation Format specification [19] is referenced for details. Field names preceded by a minus sign are ones complement values of the named field. Note: Figure 17 does not represent the FSF that is described in section 7.
Appendix H. FCIP Requirements on an FC Entity
The contents of this annex are informative for FCIP but might be considered normative on FC-BB-2. The capabilities that FCIP requires of an FC Entity include: 1) The FC Entity must deliver FC Frames to the correct FCIP Data Engine (in the correct FCIP Link Endpoint). 2) Each FC Frame delivered to an FCIP_DE must be accompanied by a time value synchronized with the clock maintained by the FC Entity at the other end of the FCIP Link (see section 6). If a synchronized time value is not available, a value of zero must accompany the FC Frame. 3) When FC Frames exit FCIP Data Engine(s) via the FC Frame Transmitter Portal(s), the FC Entity should forward them to the FC Fabric. However, before forwarding an FC Frame, the FC Entity must compute the end-to-end transit time for the FC Frame using the time value supplied by the FCIP_DE (taken from the FCIP header) and a synchronized time value (see section 6). If the end-to-end transit time exceeds the requirements of the FC Fabric, the FC Entity is responsible for discarding the FC Frame. 4) The only delivery ordering guarantee provided by FCIP is correctly ordered delivery of FC Frames between a pair of FCIP Data Engines. FCIP expects the FC Entity to implement all other FC Frame delivery ordering requirements. 5) When a TCP connect request is received and that request would add a new TCP Connection to an existing FCIP_LEP, the FC Entity must authenticate the source of the TCP connect request before use of the new TCP connection is allowed. 6) The FC Entity may participate in determining allowed TCP Connections, TCP Connection parameters, quality of service usage, and security usage by modifying interactions with the FCIP Entity that are modelled as a "shared" database in section 8.1.1. 7) The FC Entity may require the FCIP Entity to perform TCP close requests. 8) The FC Entity may recover from connection failures. 9) The FC Entity must recover from events that the FCIP Entity cannot handle, such as:
a) loss of synchronization with FCIP Frame headers from the
Encapsulated Frame Receiver Portal requiring resetting the TCP
Connection; and
b) recovering from FCIP Frames that are discarded as a result of
synchronization problems (see section 5.6.2.2 and section
5.6.2.3).
10) The FC Entity must work cooperatively with the FCIP Entity to
manage flow control problems in either the IP Network or FC
Fabric.
11) The FC Entity may test for failed TCP Connections.
Note that the Fibre Channel standards must be consulted for a
complete understanding of the requirements placed on an FC
Entity.
Table 2 shows the explicit interactions between the FCIP Entity
and the FC Entity.
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| 5.6 | FC Frame ready | | Provide FC |
| FCIP Data | for IP transfer | | Frame and |
| Engine | | | time stamp at |
| | | | FC Frame |
| | | | Receiver Portal |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 1 of 5)
+-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | continued | +-------------+-----------------+-----------------+-----------------+ | 5.6 | FCIP Frame | Provide FC | | | FCIP Data | received from | Frame and | | | Engine | IP Network | time stamp at | | | | | FC Frame Trans- | | | | | mitter Portal | | +-------------+-----------------+-----------------+-----------------+ | 5.6.2.2 | FCIP_DE | Inform FC | | | Errors | discards bytes | Entity that | | | in FCIP | delivered | bytes have been | | | Headers and | through | discarded with | | | Discarding | Encapsulated | reason | | | FCIP Frames | Frame Receiver | | | | | Portal | | | +-------------+-----------------+-----------------+-----------------+ | 5.6.2.3 | FCIP Entity | Inform FC | | | Synchron- | closes TCP | Entity that TCP | | | ization | Connection due | Connection has | | | Failures | to synchron- | been closed | | | | ization failure | with reason | | | | | for closure | | +-------------+-----------------+-----------------+-----------------+ | 8.1.2.3 | Receipt of the | Inform FC | | | Connection | echoed FSF | Entity that TCP | | | Setup | takes too long | Connection has | | | Following a | or the FSF | been closed | | | Successful | contents have | with reason | | | TCP Connect | changed | for closure | | | Request | | | | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ | continued | +-------------------------------------------------------------------+ Table 2: FC/FCIP Entity pair interactions (part 2 of 5)
+-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | continued | +-------------+-----------------+-----------------+-----------------+ | 8.1.2.1 | New TCP | Inform FC | | | Non-Dynamic | Connection | Entity of | | | Creation of | created based | new or existing | | | a New TCP | on "shared" | FCIP_LEP and | | | Connections | database | new FCIP_DE | | | | information | along with | | | | | Destination FC | | | | | Fabric Entity | | | | | WWN, Connection | | | | | Usage Flags, | | | | | Connection | | | | | Usage Code and | | | | | Connection | | | | | Nonce | | +-------------+-----------------+-----------------+-----------------+ | 8.1.2.2 | New TCP | Inform FC | | | Dynamic | Connection | Entity of | | | Creation of | created based | new or existing | | | a New TCP | on SLP service | FCIP_LEP and | | | Connections | advertisement | new FCIP_DE | | | | and "shared" | along with | | | | database | Destination FC | | | | information | Fabric Entity | | | | | WWN, Connection | | | | | Usage Flags, | | | | | Connection | | | | | Usage Code and | | | | | Connection | | | | | Nonce | | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ | continued | +-------------------------------------------------------------------+ Table 2: FC/FCIP Entity pair interactions (part 3 of 5)
+-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | continued | +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | New TCP | Inform FC | | | Processing | Connection | Entity of | | | Incoming | created based | new or existing | | | TCP Connect | on incoming TCP | FCIP_LEP and | | | Requests | Connect request | new FCIP_DE | | | | and "shared" | along with | | | | database | Source FC | | | | information | Fabric Entity | | | | | WWN, Source | | | | | FC/FCIP Entity | | | | | Identifier, | | | | | Connection | | | | | Usage Flags, | | | | | Connection | | | | | Usage Code and | | | | | Connection | | | | | Nonce | | +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | TCP Connect | Request FC | Yes or No | | Processing | Request wants | Entity to | answer about | | Incoming | to add a new | authenticate | whether the | | TCP Connect | TCP Connection | the source of | source of the | | Requests | to an existing | the TCP Connect | TCP Connect | | | FCIP_LEP | Request | Request can be | | | | | authenticated | +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | Receipt of the | Inform FC | | | Processing | FSF takes too | Entity that TCP | | | Incoming | long or | Connection has | | | TCP Connect | duplicate | been closed | | | Requests | Connection | with reason | | | | Nonce value | for closure | | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ | continued | +-------------------------------------------------------------------+ Table 2: FC/FCIP Entity pair interactions (part 4 of 5)
+-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | concluded | +-------------+-----------------+-----------------+-----------------+ | 8.2 | FC Entity | Acknowledgement | Identification | | Closing TCP | determines | of TCP | of the FCIP_DE | | Connections | that a TCP | Connection | whose TCP | | | Connection | closure | Connection | | | needs to be | | needs to be | | | closed | | closed | +-------------+-----------------+-----------------+-----------------+ | 8.4 | Discovery that | Inform FC | | | TCP | TCP connectiv- | Entity that TCP | | | Connection | ity has been | Connection has | | | Considera- | lost | been closed | | | tions | | with reason | | | | | for closure | | +-------------+-----------------+-----------------+-----------------+ | 9.4.1 | IKE phase 1 | Inform FC | | | FCIP | failed, result- | Entity that TCP | | | Link | ing in termin- | Connection can | | | Initializ- | ation of link | not be opened | | | ation Steps | initialization | with reason for | | | | | failure | | +-------------+-----------------+-----------------+-----------------+ | 9.4.3 | Excessive | Inform FC | | | Handling | numbers of | Entity that TCP | | | data | dropped | Connection has | | | integrity | datagrams | been closed | | | and confi- | detected and | with reason | | | dentiality | TCP Connection | for closure | | | violations | closed | | | +-------------+-----------------+-----------------+-----------------+ | RFC 3723 | TCP Connection | Inform FC | | | | closed due to | Entity that TCP | | | Handling SA | SA parameter | Connection has | | | parameter | mismatch | been closed | | | mismatches | problems | with reason | | | | | for closure | | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ Table 2: FC/FCIP Entity pair interactions (part 5 of 5)
Editors and Contributors Acknowledgements
During the development of this specification, Murali Rajagopal, Elizabeth Rodriguez, Vi Chau, and Ralph Weber served consecutively as editors. Raj Bhagwat contributed substantially to the initial basic FCIP concepts. Venkat Rangan contributed the Security section and continues to coordinate security issues with the ips Working Group and IETF. Andy Helland contributed a substantial revision of Performance section, aligning it with TCP/IP QoS concepts. Dave Peterson contributed the dynamic discovery section and edits to RFC 3822. Anil Rijhsinghani contributed material related to the FCIP MIB and edits the FCIP MIB document. Bob Snively contributed material related to error detection and recovery including the bulk of the synchronization recovery example annex. Lawrence J. Lamers contributed numerous ideas focused on keeping FCIP compatible with B_Port devices. Milan Merhar contributed several of the FCIP conceptual modifications necessary to support NATs. Don Fraser contributed material related to link failure detection and reporting. Bill Krieg contributed a restructuring of the TCP Connection setup sections that made them more linear with respect to time and more readable. Several T11 leaders supported this effort and advised the editors of this specification regarding coordination with T11 documents and projects. These T11 leaders are: Jim Nelson (Framing and Signaling), Neil Wanamaker (Framing and Signaling), Craig Carlson (Generic Services), Ken Hirata (Switch Fabric), Murali Rajagopal (Backbone), Steve Wilson (Switch Fabric), and Michael O'Donnell (Security Protocols).
Editors and Contributors Addresses
Neil Wanamaker Akara 10624 Icarus Court Austin, TX 78726 USA Phone: +1 512 257 7633 Fax: +1 512 257 7877 EMail: nwanamaker@akara.com Ralph Weber ENDL Texas, representing Brocade Suite 102 PMB 178 18484 Preston Road Dallas, TX 75252 USA Phone: +1 214 912 1373 EMail: roweber@ieee.org Elizabeth G. Rodriguez Dot Hill Systems Corp. 6305 El Camino Real Carlsbad, CA 92009 USA Phone: +1 760 431 4435 EMail: elizabeth.rodriguez@dothill.com Steve Wilson Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA. 95110 USA Phone: +1 408 333 8128 EMail: swilson@brocade.com
Bob Snively Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA 95110 USA Phone: +1 408 303 8135 EMail: rsnively@brocade.com David Peterson Cisco Systems - SRBU 6450 Wedgwood Road Maple Grove, MN 55311 USA Phone: +1 763 398 1007 Cell: +1 612 802 3299 EMail: dap@cisco.com Donald R. Fraser Hewlett-Packard 301 Rockrimmon Blvd., Bldg. 5 Colorado Springs, CO 80919 USA Phone: +1 719 548 3272 EMail: Don.Fraser@HP.com R. Andy Helland LightSand Communications, Inc. 375 Los Coches Street Milpitas, CA 95035 USA Phone: +1 408 404 3119 Fax: +1 408 941 2166 EMail: andyh@lightsand.com Raj Bhagwat LightSand Communications, Inc. 24411 Ridge Route Dr. Suite 135 Laguna Hills, CA 92653 USA Phone: +1 949 837 1733 x104 EMail: rajb@lightsand.com
Bill Krieg Lucent Technologies 200 Lucent Lane Cary, NC 27511 USA Phone: +1 919 463 4020 Fax: +1 919 463 4041 EMail: bkrieg@lucent.com Michael E. O'Donnell McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA Phone: +1 303 460 4142 Fax: +1 303 465 4996 EMail: modonnell@mcdata.com Anil Rijhsinghani McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA Phone: +1 508 870 6593 EMail: anil.rijhsinghani@mcdata.com Milan J. Merhar 43 Nagog Park Pirus Networks Acton, MA 01720 USA Phone: +1 978 206 9124 EMail: Milan@pirus.com Craig W. Carlson QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 USA Phone: +1 952 932 4064 EMail: craig.carlson@qlogic.com
Venkat Rangan Rhapsody Networks Inc. 3450 W. Warren Ave. Fremont, CA 94538 USA Phone: +1 510 743 3018 Fax: +1 510 687 0136 EMail: venkat@rhapsodynetworks.com Lawrence J. Lamers SAN Valley Systems, Inc. 6320 San Ignacio Ave. San Jose, CA 95119-1209 USA Phone: +1 408 234 0071 EMail: ljlamers@ieee.org Murali Rajagopal Broadcom Corporation 16215 Alton Parkway Irvine,CA 92619 USA Phone: +1 949 450 8700 EMail: muralir@broadcom.com Ken Hirata Vixel Corporation 15245 Alton Parkway, Suite 100 Irvine, CA 92618 USA Phone: +1 949 788 6368 Fax: +1 949 753 9500 EMail: ken.hirata@vixel.com Vi Chau USA Email: vchau1@cox.net
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.