|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] IPS-All: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting)Hi all, The authors of the FCIP document have requested that the following NAT/NAPT solution be reviewed. This and the security requirements are the two remaining outstanding issues of the FCIP document. The NAT/NAPT problem is a difficult one for the FCIP draft, and the authors would like input on this proposal prior to incorporating the text into the final draft before Salt Lake City. The are especially interested in input from those interested in FCIP as well as those who have experience in NAPTs. Comments and feedback by November 9 would be appreciated. Thanks, Elizabeth -----Original Message----- From: Ralph Weber [mailto:ralphoweber@compuserve.com] Sent: Wednesday, October 24, 2001 4:44 PM To: IPS Reflector Subject: 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: Sat Nov 10 12:17:40 2001 7742 messages in chronological order |