FC Entity. Further, such errors SHOULD be considered carefully,
since some may be synchronization errors.
Whenever an FCIP_DE discards bytes delivered through the Encapsulated
Frame Receiver Portal, it SHALL cause the FCIP Entity to notify the
FC Entity of the condition and provide a suitable description of the
reason bytes were discarded.
The burden for recovering from discarded data falls on the FC Entity
and other components of the FC Fabric, and is outside the scope of
this specification.
5.6.2.3. Synchronization Failures
If an FCIP_DE determines that it cannot find the next FCIP Frame
header in the byte stream entering through the Encapsulated Frame
Receiver Portal, the FCIP_DE SHALL do one of the following:
a) close the TCP Connection [6] [7] and notify the FC Entity with the
reason for the closure;
b) recover synchronization by searching the bytes delivered by the
Encapsulated Frame Receiver Portal for a valid FCIP Frame header
having the correct properties (see section 5.6.2.2), and
discarding bytes delivered by the Encapsulated Frame Receiver
Portal until a valid FCIP Frame header is found; or
c) attempt to recover synchronization as described in b) and if
synchronization cannot be recovered, close the TCP Connection as
described in a), including notification of the FC Entity with the
reason for the closure.
If the FCIP_DE attempts to recover synchronization, the
resynchronization algorithm used SHALL meet the following
requirements:
a) discard or identify with an EOFa (see appendix section F.1) those
FC Frames and fragments of FC Frames identified before
synchronization has again been completely verified. The number of
FC Frames not forwarded may vary based on the algorithm used;
b) return to forwarding FC Frames through the FC Frame Transmitter
Portal only after synchronization on the transmitted FCIP Frame
stream has been verified; and
c) close the TCP/IP connection if the algorithm ends without
verifying successful synchronization. The probability of failing
to synchronize successfully and the time necessary to determine
whether or not synchronization was successful may vary with the
algorithm used.
An example algorithm meeting these requirements can be found in
appendix D.
The burden for recovering from the discarding of FCIP Frames during
the optional resynchronization process described in this section
falls on the FC Entity and other components of the FC Fabric, and is
outside the scope of this specification.
6. Checking FC Frame Transit Times in the IP Network
FC-BB-2 [3] defines how the measurement of IP Network transit time is
performed, based on the requirements stated in the FC Frame
Encapsulation [19] specification. The choice to place this
implementation requirement on the FC Entity is based on a desire to
include the transit time through the FCIP Entities when computing the
IP Network transit time experienced by the FC Frames.
Each FC Frame that enters the FCIP_DE through the FC Frame Receiver
Portal SHALL be accompanied by a time stamp value that the FCIP_DE
SHALL place in the Time Stamp [integer] and Time Stamp [fraction]
fields of the encapsulation header of the FCIP Frame that contains
the FC Frame. If no synchronized time stamp value is available to
accompany the entering FC Frame, a value of zero SHALL be used.
Each FC Frame that exits the FCIP_DE through the FC Frame Transmitter
Portal SHALL be accompanied by the time stamp value taken from the
FCIP Frame that encapsulated the FC Frame.
The FC Entity SHALL use suitable internal clocks and either Fibre
Channel services or an SNTP Version 4 server [26] to establish and
maintain the required synchronized time value. The FC Entity SHALL
verify that the FC Entity it is communicating with on an FCIP Link is
using the same synchronized time source, either Fibre Channel
services or SNTP server.
Note that since the FC Fabric is expected to have a single
synchronized time value throughout, reliance on the Fibre Channel
services means that only one synchronized time value is needed for
all FCIP_DEs regardless of their connection characteristics.
7. The FCIP Special Frame (FSF)
7.1. FCIP Special Frame Format
Figure 9 shows the FSF format.
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) | | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0b000000)| (0b0000010011) | (0b111111)| (0b1111101100) |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC (Reserved in FCIP) |
| (0x00-00-00-00) |
+-------------------------------+-------------------------------+
7| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
8| |
+----- Source FC Fabric Entity World Wide Name -----+
9| |
+---------------------------------------------------------------+
10| |
+----- Source FC/FCIP Entity Identifier -----+
11| |
+---------------------------------------------------------------+
12| |
+----- Connection Nonce -----+
13| |
+---------------+---------------+-------------------------------+
(Continued)
Figure 9: FSF Format (part 1 of 2)
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|
| |
| (Concluded) |
+---------------------------------------------------------------+
14| Connection | Reserved | Connection Usage Code |
| Usage Flags | (0x00) | <defined in FC-BB-2> |
+---------------+---------------+-------------------------------+
15| |
+----- Destination FC Fabric Entity World Wide Name -----+
16| |
+---------------------------------------------------------------+
17| K_A_TOV |
+-------------------------------+-------------------------------+
18| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
Figure 9: FSF Format (part 2 of 2)
The FSF SHALL only be sent as the first bytes transmitted in each
direction on a newly formed TCP Connection, and only one FSF SHALL be
transmitted in each direction.
The contents of the FSF SHALL be as described for encapsulated FC
Frames, except for the fields described in this section.
All FSFs SHALL have the pFlags SF bit set to 1 (see section 5.6.1).
The Source FC Fabric Entity World Wide Name field SHALL contain the
Fibre Channel Name_Identifier [5] for the FC Fabric entity associated
with the FC/FCIP Entity pair that generates (as opposed to echoes)
the FSF. For example, if the FC Fabric entity is a FC Switch, the FC
Fabric Entity World Wide Name field SHALL contain the Switch_Name
[4]. The Source FC Fabric Entity World Wide Name SHALL be world wide
unique.
The Source FC/FCIP Entity Identifier field SHALL contain a unique
identifier for the FC/FCIP Entity pair that generates (as opposed to
echoes) the FSF. The value is assigned by the FC Fabric entity whose
world wide name appears in the Source FC Fabric Entity World Wide
Name field.
Note: The combination of the Source FC Entity World Wide Name and
Source FC/FCIP Entity Identifier fields uniquely identifies every
FC/FCIP Entity pair in the IP Network.
The Connection Nonce field shall contain a 64-bit random number
generated to uniquely identify a single TCP connect request. In
order to provide sufficient security for the connection nonce, the
Randomness Recommendations for Security [9] SHOULD be followed.
The Connection Usage Flags field identifies the types of SOF values
[19] to be carried on the connection as shown in figure 10.
|------------------------------Bit------------------------------|
| |
| 0 1 2 3 4 5 6 7 |
+-------+-------+-------+-------+-------------------------------+
| SOFf | SOF?2 | SOF?3 | SOF?4 | Reserved |
+-------+-------+-------+-------+-------------------------------+
Figure 10: Connection Usage Flags Field Format
If the SOFf bit is one, then FC Frames containing SOFf are intended
to be carried on the connection.
If the SOF?2 bit is one, then FC Frames containing SOFi2 and SOFn2
are intended to be carried on the connection.
If the SOF?3 bit is one, then FC Frames containing SOFi3 and SOFn3
are intended to be carried on the connection.
If the SOF?4 bit is one, then FC Frames containing SOFi4, SOFn4, and
SOFc4 are intended to be carried on the connection.
All or none of the SOFf, SOF?2, SOF?3, and SOF?4 bits MAY be set to
one. If all of the SOFf, SOF?2, SOF?3, and SOF?4 bits are zero, then
the types of FC Frames intended to be carried on the connection have
no specific relationship to the SOF code.
The FCIP Entity SHALL NOT enforce the SOF usage described by the
Connection Usage Flags field and SHALL only use the contents of the
field as described below.
The Connection Usage Code field contains Fibre Channel defined
information regarding the intended usage of the connection as
specified in FC-BB-2 [3].
The FCIP Entity SHALL use the contents of the Connection Usage Flags
and Connection Usage Code fields to locate appropriate QoS settings
in the "shared" database of TCP Connection information (see section
8.1.1) and apply those settings to a newly formed connection.
The Destination FC Fabric Entity World Wide Name field MAY contain
the Fibre Channel Name_Identifier [5] for the FC Fabric entity
associated with the FC/FCIP Entity pair that echoes (as opposed to
generates) the Special Frame.
The K_A_TOV field SHALL contain the FC Keep Alive Timeout value to be
applied to the new TCP Connection as specified in FC-BB-2 [3].
For each new incoming TCP connect request and subsequent FSF
received, the FCIP Entity SHALL send the contents of the Source FC
Fabric Entity World Wide Name, Source FC/FCIP Identifier, Connection
Usage Flags and Connection Usage Code fields to the FC Entity along
with the other connection information (e.g., FCIP_LEP and FCIP_DE
information).
7.2. Overview of FSF Usage in Connection Establishment
When a new TCP Connection is established, an FCIP Special Frame makes
one round trip from the FCIP Entity initiating the TCP connect
operation to the FCIP Entity receiving the TCP connect request and
back. This FSF usage serves three functions:
- Identification of the FCIP Link endpoints
- Conveyance of a few critical parameters shared by the FC/FCIP
Entity pairs involved in the FCIP Link
- Configuration discovery (used in place of SLP only when allowed by
site security policies)
The specific format and protocol requirements for this usage of the
FSF are found in sections 7.1 and 8.1.2.3. This section provides an
overview of the FSF usage without stating requirements.
Because FCIP is only a tunnel for a Fibre Channel Fabric and because
the Fabric has its own complex link setup algorithm that can be
employed for many FCIP link setup needs, it is desirable to minimize
the complexity of the FSF usage during TCP Connection setup. With
this in mind, this FSF usage is not a login or parameter negotiation
mechanism. A single FSF transits each newly established TCP
connection as the first bytes sent in each direction.
Note: This usage of the FSF cannot be eliminated entirely because a
newly created TCP Connection must be associated with the correct FCIP
Link before FC Fabric initialization of the connection can commence.
The first bytes sent from the TCP connect request initiator to the
receiver are an FSF identifying both the sender and who the sender
thinks is the receiver. If the contents of this FSF are correct and
acceptable to the receiver, the unchanged FSF is echoed back to the
sender. This send/echo process is the only set of actions that
allows the TCP Connection to be used to carry FC Fabric traffic. If
the send and unchanged echo process does not occur, the algorithm
followed at one or both ends of the TCP Connection results in the
closure of the TCP Connection (see section 8.1 for specific algorithm
requirements).
Note: Owing to the limited manner in which the FSF is used and the
requirement that the FSF be echoed without changes before a TCP
Connection is allowed to carry user data, no error checking beyond
that provided by TCP is deemed necessary.
As described above, the primary purpose of the FSF usage during TCP
Connection setup is identifying the FCIP Link to which the new TCP
Connection belongs. From these beginnings, it is only a small
stretch to envision using the FSF as a simplified configuration
discovery tool, and the mechanics of such a usage are described in
section 8.1.
However, use of the FSF for configuration discovery lacks the broad
range of capabilities provided by SLPv2 and most particularly lacks
the security capabilities of SLPv2. For these reasons, using the FSF
for configuration discovery is not appropriate for all environments.
Thus the choice to use the FSF for discovery purposes is a policy
choice to be included in the TCP Connection Establishment "shared"
database described in section 8.1.1.
When FSF-based configuration discovery is enabled, the normal TCP
Connection setup rules outlined above are modified as follows.
Normally, the algorithm executed by an FCIP Entity receiving an FSF
includes verifying that its own identification information in the
arriving FSF is correct and closing the TCP Connection if it is not.
This can be viewed as requiring the initiator of a TCP connect
request to know in advance the identity of the FCIP Entity that is
the target of that request (using SLP, for example), and through the
FSF effectively saying, "I think I’m talking to X." If the party at
the other end of the TCP connect request is really Y, then it simply
hangs up.
FSF-based discovery allows the "I think I’m talking to X" to be
replaced with "Please tell me who I am talking to?", which is
accomplished by replacing an explicit value in the Destination FC
Fabric Entity World Wide Name field with zero.
If the policy at the receiving FCIP Entity allows FSF-based
discovery, the zero is replaced with the correct Destination FC
Fabric Entity World Wide Name value in the echoed FSF. This is still
subject to the rules of sending with unchanged echo, and so closure
of TCP Connection occurs after the echoed FSF is received by the TCP
connect initiator.
Despite the TCP Connection closure, however, the TCP connect
initiator now knows the correct Destination FC Fabric Entity World
Wide Name identity of the FCIP Entity at a given IP Address and a
subsequent TCP Connection setup sequence probably will be successful.
The Ch bit in the pFlags field (see section 5.6.1) allows for
differentiation between changes in the FSF resulting from
transmission errors and changes resulting from intentional acts by
the FSF recipient.
8. TCP Connection Management
8.1. TCP Connection Establishment
8.1.1. Connection Establishment Model
The description of the connection establishment process is a model
for the interactions between an FC Entity and an FCIP Entity during
TCP Connection establishment. The model is written in terms of a
"shared" database that the FCIP Entity consults to determine the
properties of the TCP Connections to be formed combined with routine
calls to the FC Entity when connections are successfully established.
Whether the FC Entity contributes information to the "shared"
database is not critical to this model. However, the fact that the
FCIP Entity MAY consult the database at any time to determine its
actions relative to TCP Connection establishment is important.
It is important to remember that this description is only a model for
the interactions between an FC Entity and an FCIP Entity. Any
implementation that has the same effects on the FC Fabric and IP
Network as those described using the model meets the requirements of
this specification. For example, an implementation might replace the
"shared" database with a routine interface between the FC and FCIP
Entities.
8.1.2. Creating New TCP Connections
8.1.2.1. Non-Dynamic Creation of New TCP Connections
When an FCIP Entity discovers that a new TCP Connection needs to be
established, it SHALL determine the IP Address to which the TCP
Connection is to be made and establish all enabled IP security
features for that IP Address as described in section 9. Then the
FCIP Entity SHALL determine the following information about the new
connection in addition to the IP Address:
- The expected Destination FC Fabric Entity World Wide Name of the
FC/FCIP Entity pair to which the TCP Connection is being made
- TCP Connection Parameters (see section 8.3)
- Quality of Service Information (see section 10)
Based on this information, the FCIP Entity SHALL generate a TCP
connect request [6] to the FCIP Well-Known Port of 3225 (or other
configuration specific port number) at the specified IP Address.
If the TCP connect request is rejected, the FCIP Entity SHALL act to
limit unnecessary repetition of attempts to establish similar
connections. For example, the FCIP Entity might wait 60 seconds
before trying to re-establish the connection.
If the TCP connect request is accepted, the FCIP Entity SHALL follow
the steps described in section 8.1.2.3 to complete the establishment
of a new FCIP_DE.
It is RECOMMENDED that an FCIP Entity not initiate TCP connect
requests to another FCIP Entity if incoming TCP connect requests from
that FCIP Entity have already been accepted.
8.1.2.2. Dynamic Creation of New TCP Connections
If dynamic discovery of participating FCIP Entities is supported, the
function SHALL be performed using the Service Location Protocol
(SLPv2) [17] in the manner defined for FCIP usage [20].
Upon discovering that dynamic discovery is to be used, the FCIP
Entity SHALL enable IP security features for the SLP discovery
process as described in [20] and then:
1) Determine the one or more FCIP Discovery Domain(s) to be used in
the dynamic discovery process;
2) Establish an SLPv2 Service Agent to advertise the availability of
this FCIP Entity to peer FCIP Entities in the identified FCIP
Discovery Domain(s); and
3) Establish an SLPv2 User Agent to locate service advertisements for
peer FCIP Entities in the identified FCIP Discovery Domain(s).
For each peer FCIP Entity dynamically discovered through the SLPv2
User Agent, the FCIP Entity SHALL establish all enabled IP security
features for the discovered IP Address as described in section 9 and
then determine the following information about the new connection:
- The expected Destination FC Fabric Entity World Wide Name of the