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.