instances of the FC/FCIP Entity pair shown on either the right-hand
or left-hand side of figure 3.
|<--------- FCIP Link -------->|
| |
+----------+ /\/\/\/\/\/\ +----------+
| FCIP | \ IP / | FCIP |
| Entity |=========/ Network \=========| Entity |
+----------+ \/\/\/\/\/\/ +----------+
| FC | | FC |
| Entity | | Entity |
+----------+ +----------+
| |
/\/\/\/\/\/\ /\/\/\/\/\/\
\ FC / \ FC /
/ Fabric \ / Fabric \
\/\/\/\/\/\/ \/\/\/\/\/\/
Figure 3: Model for Two Connected FC/FCIP Entity Pairs
In general, the combination of an FCIP Link and two FC/FCIP Entity
pairs is intended to provide a non-Fibre Channel backbone transport
between Fibre Channel components. For example, this combination can
be used to function as the hard-wire connection between two Fibre
Channel switches.
The interface between the FC and FCIP Entities is implementation
specific. The functional requirements placed on an FC Entity by this
specification are listed in appendix H. More information about FC
Entities can be found in the Fibre Channel standards and an example
of an FC Entity can be found in FC-BB-2 [3].
5.4. FCIP Entity
The model for an FCIP Entity is shown in figure 4.
.......................................................
: FCIP Entity :
: :
: +-----------+ :
: | FCIP | :
: |Control and|------------------------------------+ :
: | Services | | :
: | Module | | :
: +-----------+ | :
: | +--------------------+ | :
: | +-------+--------------------+|----+ | :
: | |+-----+--------------------+|----+| | :
: | ||+----| FCIP Link Endpoint |----+|| | :
: | ||| +--------------------+ ||| | :
:.............................................|||.....:
| ||| ||| |
| ||| ||| o<--+
| ||| unique TCP ||| | |
| ||| connections-->||| | |
| ||| ||| | |
+----------+ /\/\/\/\/\/\ |
| FC | \ IP / |
| Entity | / Network \ |
+----------+ \/\/\/\/\/\/ |
| |
/\/\/\/\/\/\ +------------------+
\ FC / +->TCP port for
/ Fabric \ incoming
\/\/\/\/\/\/ connections
Figure 4: FCIP Entity Model
The FCIP Entity receives TCP connect requests on behalf of the
FCIP_LEPs that it manages. In support of this, the FCIP Entity is
the sole owner of at least one TCP port/IP Address combination used
to form TCP Connections. The TCP port may be the FCIP well known
port at a given IP Address. An FC Fabric to IP Network interface
product SHALL provide each FC/FCIP Entity pair contained in the
product with a unique combination of FC Fabric Entity World Wide
Identifier and FC/FCIP Entity Identifier values (see section 7).
An FCIP Entity contains an FCIP Control and Services Module to
control FCIP link initialization, FCIP link dissolution, and to
provide the FC Entity with an interface to key IP Network features.
The interfaces to the IP Network features are implementation
specific, however, REQUIRED TCP/IP functional support is specified in
this document, including:
- TCP Connections - see section 8
- Security - see section 9
- Performance - see section 10
- Dynamic Discovery - see section 8.1.2.2
The FCIP Link Endpoints in an FCIP Entity provide the FC Frame
encapsulation and transmission features of FCIP.
5.5. FCIP Link Endpoint (FCIP_LEP)
As shown in figure 5, the FCIP Link Endpoint contains one FCIP Data
Engine for each TCP Connection in the FCIP Link.
................................................
: FCIP Link Endpoint :
: +------------------+ :
: +-------+------------------+|----+ :
: |+-----+------------------+|----+| :
: ||+----| FCIP Data Engine |----+|| :
: ||| +------------------+ ||| :
:..............................................:
||| |||
+----------+ /\/\/\/\/\/\
| FC | \ IP /
| Entity | / Network \
+----------+ \/\/\/\/\/\/
|
/\/\/\/\/\/\
\ FC /
/ Fabric \
\/\/\/\/\/\/
Figure 5: FCIP Link Endpoint Model
Each time a TCP Connection is formed with a new FC/FCIP Entity pair
(including all the actions described in section 8.1), the FCIP
Entity SHALL create a new FCIP Link Endpoint containing one FCIP Data
Engine.
An FCIP_LEP is a transparent data translation point between an FC
Entity and an IP Network. A pair of FCIP_LEPs communicating over one
or more TCP Connections create an FCIP Link to join two islands of an
FC Fabric, producing a single FC Fabric.
The IP Network over which the two FCIP_LEPs communicate is not aware
of the FC payloads that it is carrying. Likewise, the FC End Nodes
connected to the FC Fabric are unaware of the TCP/IP based transport
employed in the structure of the FC Fabric.
An FCIP_LEP uses normal TCP based flow control mechanisms for
managing its internal resources and matching them with the advertised
TCP Receiver Window Size (see sections 8.3.2, 8.5). An FCIP_LEP MAY
communicate with its local FC Entity counterpart to coordinate flow
control.
5.6. FCIP Data Engine (FCIP_DE)
The model for one of the multiple FCIP_DEs that MAY be present in an
FCIP_LEP is shown in figure 6.
+--------------------------------+
| |
F |-+ +------------------+ +-|
C |p| | Encapsulation | |p| N
-->|1|--->| Engine |--->|2|--> e
E |-+ +------------------+ +-| t
n | | I w
t |-+ +------------------+ +-| P o
i |p| | De-Encapsulation | |p| r
t <--|4|<---| Engine |<---|3|<-- k
y |-+ +------------------+ +-|
| |
+--------------------------------+
Figure 6: FCIP Data Engine Model
Data enters and leaves the FCIP_DE through four portals (p1 - p4).
The portals do not process or examine the data that passes through
them. They are only the named access points where the FCIP_DE
interfaces with the external world. The names of the portals are as
follows:
p1) FC Frame Receiver Portal - The interface through which an FC
Frame and time stamp enters an FCIP_DE from the FC Entity.
p2) Encapsulated Frame Transmitter Portal - The TCP interface through
which an FCIP Frame is transmitted to the IP Network by an
FCIP_DE.
p3) Encapsulated Frame Receiver Portal - The TCP interface through
which an FCIP Frame is received from the IP Network by an
FCIP_DE.
p4) FC Frame Transmitter Portal - The interface through which a
reconstituted FC Frame and time stamp exits an FCIP_DE to the FC
Entity.
The work of the FCIP_DE is done by the Encapsulation and De-
Encapsulation Engines. The Engines have two functions:
1) Encapsulating and de-encapsulating FC Frames using the
encapsulation format described in FC Frame Encapsulation [19] and
in section 5.6.1 of this document, and
2) Detecting some data transmission errors and performing minimal
error recovery as described in section 5.6.2.
Data flows through a pair of IP Network connected FCIP_DEs in the
following seven steps:
1) An FC Frame and time stamp arrives at the FC Frame Receiver Portal
and is passed to the Encapsulation Engine. The FC Frame is
assumed to have been processed by the FC Entity according to the
applicable FC rules and is not validated by the FCIP_DE. If the
FC Entity is in the Unsynchronized state with respect to a time
base as described in the FC Frame Encapsulation [19]
specification, the time stamp delivered with the FC Frame SHALL be
zero.
2) In the Encapsulation Engine, the encapsulation format described in
FC Frame Encapsulation [19] and in section 5.6.1 of this document
SHALL be applied to prepare the FC Frame and associated time stamp
for transmission over the IP Network.
3) The entire encapsulated FC Frame (a.k.a. the FCIP Frame) SHALL be
passed to the Encapsulated Frame Transmitter Portal where it SHALL
be inserted in the TCP byte stream.
4) Transmission of the FCIP Frame over the IP Network follows all the
TCP rules of operation. This includes, but is not limited to, the
in-order delivery of bytes in the stream, as specified by TCP [6].
5) The FCIP Frame arrives at the partner FCIP Entity where it enters
the FCIP_DE through the Encapsulated Frame Receiver Portal and is
passed to the De-Encapsulation Engine for processing.
6) The De-Encapsulation Engine SHALL validate the incoming TCP byte
stream as described in section 5.6.2.2 and SHALL de-encapsulate
the FC Frame and associated time stamp according to the
encapsulation format described in FC Frame Encapsulation [19] and
in section 5.6.1 of this document.
7) In the absence of errors, the de-encapsulated FC Frame and time
stamp SHALL be passed to the FC Frame Transmitter Portal for
delivery to the FC Entity. Error handling is discussed in section
5.6.2.2.
Every FC Frame that arrives at the FC Frame Receiver Portal SHALL be
transmitted on the IP Network as described in steps 1 through 4
above. In the absence of errors, data bytes arriving at the
Encapsulated Frame Receiver Portal SHALL be de-encapsulated and
forwarded to the FC Frame Transmitter Portal as described in steps 5
through 7.
5.6.1. FCIP Encapsulation of FC Frames
The FCIP encapsulation of FC Frames employs FC Frame Encapsulation
[19].
The features from FC Frame Encapsulation that are unique to
individual protocols SHALL be applied as follows for the FCIP
encapsulation of FC Frames.
The Protocol# field SHALL contain 1 in accordance with the IANA
Considerations annex of FC Frame Encapsulation [19].
The Protocol Specific field SHALL have the format shown in figure 7.
Note: the word numbers in figure 7 are relative to the complete FC
Frame Encapsulation header, not to the Protocol Specific field.
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|
+---------------------------------------------------------------+
1| replication of encapsulation word 0 |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
+---------------+---------------+---------------+---------------+
Figure 7: FCIP Usage of FC Frame Encapsulation Protocol Specific
field
Word 1 of the Protocol Specific field SHALL contain an exact copy of
word 0 in FC Frame Encapsulation [19].
The pFlags (protocol specific flags) field provides information about
the protocol specific usage of the FC Encapsulation Header. Figure 8
shows the defined pFlags bits.
|----------------Bit--------------------|
| |
| 0 1 2 3 4 5 6 7 |
+----+-----------------------------+----+
| Ch | Reserved | SF |
+----+-----------------------------+----+
Figure 8: pFlags Field Bits
The SF (Special Frame) bit indicates whether the FCIP Frame is an
encapsulated FC Frame or an FSF (FCIP Special Frame, see section 7).
When the FCIP Frame contains an encapsulated FC Frame, the SF bit
SHALL be 0. When the FCIP Frame is an FSF, the SF bit SHALL be 1.
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 at that time (see section 8.1). After
that all FCIP Frames SHALL have the SF bit set to 0.
The Ch (Changed) bit indicates whether an echoed FSF has been
intentionally altered (see section 8.1.3). The Ch bit SHALL be 0
unless the FSF bit is 1. When the initial TCP Connection FSF is
sent, the Ch bit SHALL be 0. If the recipient of a TCP connect
request echoes the FSF without any changes, then the Ch bit SHALL
continue to be 0. If the recipient of a TCP connect request alters
the FSF before echoing it, then the Ch bit SHALL be changed to 1.
The -pFlags field SHALL contain the ones complement of the contents
of the pFlags field.
Table 1 summarizes the usage of the pFlags SF and Ch bits.
+----+----+------------+--------------------------------------+
| | | Originated | |
| SF | Ch | or Echoed | Validity/Description |
+----+----+------------+--------------------------------------+
| 0 | 0 | n/a | Encapsulated FC Frame |
+----+----+------------+--------------------------------------+
| 0 | 1 | n/a | Always Illegal |
+----+----+------------+--------------------------------------+
| 1 | 0 | Originated | Originated FSF |
+----+----+------------+--------------------------------------+
| 1 | 1 | Originated | Always Illegal |
+----+----+------------+--------------------------------------+
| 1 | 0 | Echoed | Echoed FSF without changes |
+----+----+------------+--------------------------------------+
| 1 | 1 | Echoed | Echoed FSF with changes |
+----+----+------------+--------------------------------------+
| Note 1: Echoed FSFs may contain changes resulting from |
| transmission errors, necessitating the comparison between |
| sent and received FSF bytes by the FSF originator described |
| in section 8.1.2.3. |
| |
| Note 2: Column positions in this table do not reflect the |
| bit positions of the SF and Ch bits in the pFlags field. |
+-------------------------------------------------------------+
Table 1: pFlags SF and Ch bit usage summary
The Reserved pFlags bits SHALL be 0.
The Reserved field (bits 23-16 in word 2): SHALL contain 0.
The -Reserved field (bits 7-0 in word 2): SHALL contain 255 (or
0xFF).
The CRCV (CRC Valid) Flag SHALL be set to 0.
The CRC field SHALL be set to 0.
In FCIP, the SOF and EOF codes listed as Class 2, Class 3, and Class
4 in the FC Frame Encapsulation [19] are legal.
5.6.2. FCIP Data Engine Error Detection and Recovery
5.6.2.1. TCP Assistance With Error Detection and Recovery
TCP [6] requires in order delivery, generation of TCP checksums, and
checking of TCP checksums. Thus, the byte stream passed from TCP to
the FCIP_LEP will be in order and free of errors detectable by the
TCP checksum. The FCIP_LEP relies on TCP to perform these functions.
5.6.2.2. Errors in FCIP Headers and Discarding FCIP Frames
Bytes delivered through the Encapsulated Frame Receiver Portal that
are not correctly delimited as defined by the FC Frame Encapsulation
[19] are considered to be in error.
The failure of the Protocol# and Version fields in the FCIP Frame
header to contain the values defined for an FCIP Frame SHALL be
considered an error.
Further, some errors in the encapsulation will result in the FCIP_DE
losing synchronization with the FC Frames in the byte stream entering
through the Encapsulated Frame Receiver Portal.
The Frame Length field in the FC Frame Encapsulation header is used
to determine where in the data stream the next FC Encapsulated Header
is located. The following tests SHALL be performed to verify
synchronization with the byte stream entering the Encapsulated Frame
Receiver Portal, and synchronization SHALL be considered lost if any
of the tests fail:
1) Frame Length field validation -- 15 < Frame Length < 545;
2) Comparison of Frame Length field to its ones complement; and
3) A valid EOF is found in the word preceding the start of the next
FCIP header as indicated by the Frame Length field, to be tested
as follows:
1) Bits 24-31 and 16-23 contain identical legal EOF values (the
list of legal EOF values is in the FC Frame Encapsulation
[19]); and
2) Bits 8-15 and 0-7 contain the ones complement of the EOF value
found in bits 24-31.
Note: The range of valid Frame Length values is derived as follows.
The FCIP Frame header is seven words, one word each is required for
the encoded SOF and EOF values, the FC Frame header is six words, and
the FC CRC requires one word, yielding a base Frame Length of 16
(7+1+1+6+1) words, if no FC Payload is present. Since the FC Payload
is optional, any Frame Length value greater than 15 is valid. The
maximum FC Payload size is 528 words, meaning that any Frame Length
value up to and including 544 (528+16) is valid.
If synchronization is lost, the FC Frame SHALL NOT be forwarded on to
the FC Entity and further recovery SHALL be handled as defined by
section 5.6.2.3.
In addition to the tests above, the validity and positioning of the
following FCIP Frame information SHOULD be used to detect
encapsulation errors that may or may not affect synchronization:
a) Protocol# ones complement field (1 test);
b) Version ones complement field (1 test);
c) Replication of encapsulation word 0 in word 1 (1 test);
d) Reserved field and its ones complement (2 tests);
e) Flags field and its ones complement (2 tests);
f) CRC field is equal to zero (1 test);
g) SOF fields and ones complement fields (4 tests);
h) Format and values of FC header (1 test);
i) CRC of FC Frame (2 tests);
j) FC Frame Encapsulation header information in the next FCIP
Frame (1 test).
At least 3 of the 16 tests listed above SHALL be performed. Failure
of any of the above tests actually performed SHALL indicate an
encapsulation error and the FC Frame SHALL NOT be forwarded on to the