|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting)
The following is proposed as a solution to the NAPTs problem in FCIP.
This proposal is based on draft-ietf-ips-fcovertcpip-06.txt and should
contain sufficient detail for evaluation purposes.
This is not a detailed proposal for changes and it is assumed that
the FCIP editor will cleanup any loose ends. This proposal assumes
familiarity with FCIP and makes no attempt to explain existing FCIP
models, structures, or functionality.
Those who were at the Irvine Interim meeting will remember that
the problem with FCIP and NAPTS is a reliance on IP address in
the determination of which incoming TCP connections belong in a
given FCIP Link. This proposal solves that problem by requiring
that FC Entity World Wide Name be transmitted in the first bytes
sent by the FCIP Entity that initiates a TCP Connect request.
This allows the FCIP Entity that receives a TCP Connect request
to match it with any previously received TCP Connect requests
from the same source. Since the transmitted World Wide Name is
required to be unique within Fibre Channel, the FCIP Entity
that receives this information can correctly assign FCIP Link
relationships without relying on IP Addresses.
To allow a given FC Entity to have multiple distinct FC/FCIP
ports, the World Wide Name is qualified by a 32-bit FC/FCIP
Entity identifier.
Optional suggestions about how a TCP Connection should be used
are also provided in the first bytes send by the FCIP Entity
that initiates a TCP Connect request.
It is believed that the proposed changes will work even with
the manual discovery option provided for in the FCIP draft.
However, the most reliable end-to-end knowledge of who is
talking to whom is achieved if SLPv2 discovery is used and
each SLP service advertisement includes the advertiser's
World Wide Name and FC/FCIP Entity identifier.
A summary of the proposed changes follows.
[Change 1] Add a new section between 6 and 7. Note all other section
number have been adjusted to reflect this addition.
7. FCIP Short Frame
Figure x shows the FCIP Short Frame format.
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|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
1| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
| (0x01) | (0x00) | (0xFE) | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0x00) | (0x00-0E) | (0x3F) | (0x03-F1) |
+-----------+-------------------+-----------+-------------------+
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| |
+----- FC Fabric Entity World Wide Name -----+
9| |
+---------------------------------------------------------------+
10| FC/FCIP Entity Identifier |
+---------------+---------------+-------------------------------+
11| Connection | Reserved | Connection Usage Code |
| Usage Flags | (0x00) | <defined in FC-BB-2> |
+---------------+---------------+-------------------------------+
12| Reserved |
| (0x00-00-00-00) |
+---------------------------------------------------------------+
13| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
Fig. x FCIP Short Frame Format
pFlags: The pFlags bits provide information about the protocol specific
usage of the FC Encapsulation Header as shown in figure y.
|----------------Bit--------------------|
| |
| 31 30 29 28 27 26 25 24 |
+----------------------------------+----+
| Reserved | SF |
+----------------------------------+----+
Fig. y - pFlags Field Format
In the Short Frame, the SF (Short Frame) bit SHALL be one. FCIP
Encapsulated frames the SF bit SHALL be zero.
The FC Fabric Entity World Wide Name field SHALL contain the Fibre
Channel Name_Identifier [FC-FS] for the FC Fabric entity associated
with the FC Entity FCIP Entity pair that generated the Short Frame.
For example, if the FC Fabric entity is a FC Switch, the FC Fabric
Entity World Wide Name field SHALL contain the Switch_Name [FC-SW-2]
provided that name is world wide unique. The FC Fabric Entity World
Wide Name SHALL be world wide unique.
The FC/FCIP Entity Identifier field SHALL contain a unique identifier
for the FC Entity FCIP Entity pair that generated the Short Frame that
is assigned by the FC Fabric entity whose world wide name appears in
the FC Fabric Entity World Wide Name field. The FC/FCIP Entity
Identifier is statically assigned to represent the configuration
relationship of the FC Entity FCIP Entity pair to the FC Fabric entity.
Note: The combination of the FC Entity World Wide Name and FCIP
Entity Identifier fields uniquely identifies every FC Entity FCIP
Entity pair in the IP Network.
An FCIP Entity that receives a TCP Connect request SHALL use the
contents of the FC Fabric Entity World Wide Name and FC/FCIP
Identifier fields to determine the FCIP_LEP to which the FCIP_DE
associated with the TCP connection is assigned. This may be an
existing FCIP_LEP or a new FCIP_LEP, depending on whether the
FCIP Entity has received the same FC Fabric Entity World Wide Name
and FC/FCIP Identifier field values before. If an FCIP Short Frame
is received on a TCP connection that has already been assigned to
an FCIP_LEP, the FC Fabric Entity World Wide Name and FC/FCIP
Identifier fields SHALL be ignored.
The Connection Usage Flags field identifies the types of SOF values
[FC Encapsulation] to be carried on the connection as shown in
figure z.
|------------------------------Bit------------------------------|
| |
| 31 30 29 28 27 26 25 24 |
+---------------------------------------------------------------+
| SOFf | SOF?2 | SOF?3 | Reserved |
+---------------------------------------------------------------+
Fig. z - Connection Usage Flags Field Format
If the SOFf bit is one, then frames containing SOFf are intended
to be carried on the connection.
If the SOF?2 bit is one, then frames containing SOFi2 and SOFn2 are
intended to be carried on the connection.
If the SOF?3 bit is one, then frames containing SOFi3 and SOFn3 are
intended to be carried on the connection.
All or none of the SOFf, SOF?2, and SOF?3 bits MAY be set to one.
If all of the SOFf, SOF?2, and SOF?3 bits are zero, then the types
of FC Frames intended to be carried on the connection has no
specific relationship to 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.
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 8.1.1) and apply those settings to a newly formed connection.
If an FCIP Short Frame is received after QOS settings have been
established, the Connection Usage Flags and Connection Usage Code
fields SHOULD be ignored.
For each new incoming TCP Connect request received, the FCIP Entity
SHALL send the contents of the FC Fabric Entity World Wide Name,
FC/FCIP Identifier, Connection Usage Flags and Connection Usage
Code fields to the FC Entity along with the other new connection
information.
[Change 2] In 5.6.1, add the pFlags field definition and require
all FCIP Encapsulated Frames except Short Frames to have SF equal
to zero. Note: Some part of the pFlags description above will
go in 5.6.1 not in the new section but the description above is
structured for easier reading in this proposal.
[Change 3] Some place in 5.6 (the description of the FCIP_DE),
require the FCIP_DE to pass all FCIP Short Frames to the Control
& Services Module.
[Change 4] In 7.1.3 and 7.1.4 (the two sections where TCP Connect
requests are generated), require the FCIP Entity to:
1) Acquire the Connection Usage and other information from the
"shared" database (see section 7.1.1);
2) Send a FCIP Short Frame as the first bytes passing through
the Encapsulated Frame Transmitter Portal following establishment
of a TCP connection;
3) Compare the first bytes received through the Encapsulated Frame
Receiver Portal to the FCIP Short Frame sent and close the TCP
connection if the bytes are not an FCIP Short Frame whose
contents (words 7 through 13 inclusive) exactly match the FCIP
Short Frame passed through the Encapsulated Frame Transmitter
Portal.
It is recommended that an FCIP Entity not initiate TCP Connect requests
to another FCIP Entity if incoming TCP Connects requests from that FCIP
Entity have already been accepted.
[Change 5] In 7.1.5 (the section where TCP Connect requests are
accepted) change the requirements about binding the new connection
to an FCIP_LEP more or less as follows:
1) Require the FCIP Entity to expect a FCIP Short Frame
as the first bytes to pass through the Encapsulated Frame
Receiver Portal following completion of an incoming TCP
Connect request;
2) Require the FCIP Entity to transmit the FCIP Short Frame contents
received (words 7 through 13 inclusive) through the Encapsulated
Frame Transmitter Portal immediately upon receipt with out
alteration of any kind;
3) Require use of the FC Entity WWN and FCIP Entity Identifier
fields in the FCIP Short Frames to determine if there is an
existing FCIP_LEP to bind to; and
4) Recommend that the Connection Usage fields contents be used in
conjunction with the "shared" database (see section 7.1.1) to
determine the QOS settings for the newly created connection.
If the local FCIP Entity determines that the TCP Connect request
just received is for a remote FCIP Entity to which the local FCIP
Entity has already initiated TCP Connect requests and the
connection request is otherwise valid, the local FCIP
Entity SHALL accept TCP Connect request. The FCIP Entity SHALL
notify the FC Entity of the reverse direction TCP Connect request
and the FC Entity SHALL determine whether both connections are
permitted and, if one is not permitted, request that the FCIP
Entity close the appropriate connection.
[Change 6] In 5.4, replace the following sentence:
"An FC Fabric to IP Network interface product SHALL contain one
FCIP Entity for each IP Address assigned to the product."
with:
"An FC Fabric to IP Network interface product SHALL provide each
FC Entity 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)."
Home Last updated: Tue Oct 30 20:17:39 2001 7457 messages in chronological order |