📄 rfc2625.txt
字号:
Rajagopal, et al. Standards Track [Page 22]
RFC 2625 IP and ARP over Fibre Channel June 1999
+------------------------------------------------------------------+
| Match Address Code Points |
+------------------------------------------------------------------+
| LSBits | Bit name | Action |
+-----------+--------------------+---------------------------------+
| 000 | Reserved | |
+-----------+--------------------+---------------------------------+
| 001 | MATCH_WW_PN | If 'WW_PN of Responder' = |
| | | Node's WW_PN then respond |
+-----------+--------------------+---------------------------------+
| 010 | MATCH_WW_NN | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 100 | MATCH_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
When a node receives a FARP-REQ with Code Point b'001', it checks its
WW_PN against the one set in 'WW_PN of Responder' field of the FARP-
REQ command. If there is a match, then the node issues a response
according to the action indicated by the FARP Responder Flag. See
table below.
WW_NN and IPv4 address fields are not used with the b'001' Code Point
operation. They SHALL be set to '0' or a valid address either by the
Requester or the Requester and the Responder.
Note that there can be utmost one FARP-REPLY per FARP-REQ.
5.5 Responder Flags
The Responder Flags define what Responder action to take if the
result of the Match Address Code Points is successful. 'Responder
Flags' is an 8-bit field (bits 0-7) and is defined in the table
below. This field is used only in a FARP-REQ. This field is retained
unchanged in a FARP-REPLY. If no bits are set, the Responder will
take no action.
Rajagopal, et al. Standards Track [Page 23]
RFC 2625 IP and ARP over Fibre Channel June 1999
+----------+-------------------------------------------------------+
| | FARP Responder Flag |
+----------+----------------+--------------------------------------+
| Bit | Bit Name | Action |
| Position | | |
+----------+----------------+--------------------------------------+
| 0 | INIT_P_LOGI | Initiate a P_LOGI to the Requester |
+----------+----------------+--------------------------------------+
| 1 | INIT_REPLY | Send FARP_REPLY to Requester |
+----------+----------------+--------------------------------------+
| 2 to 7 | Reserved | |
+----------+----------------+--------------------------------------+
If INIT_P_LOGI bit is set then, a Login is performed with the port
identified by "Port_ID of Requester" field.
If INIT_REPLY is set then, a FARP-REPLY is sent to the Port
Identified by "Port_ID of Requester" field.
If both bits are set at the same time, then both Actions are
performed.
All other bit patterns are undefined at this time and are reserved
for possible future use.
5.6 FARP Support Requirements
Responder action - FARP-REPLY and/or Port Login - for a successful
MATCH_WW_PN is always REQUIRED. If there is no address match then a
silent behavior is specified.
Support for all other Match Address Code Points is OPTIONAL and a
silent behavior from the Responder is valid when it is not supported.
Recipients of the FARP-REQ ELS SHALL NOT issue a Service Reject
(LS_RJT) if FARP OPTIONAL mechanisms are not supported.
In all cases, if there are no matches, then a silent behavior is
specified.
If an implementation issues a FARP-REQ with a Match Address Code
Point that is OPTIONAL, and fails to receive a response, and the
implementation has not obtained the Port_ID of the Responder's port
by other means (e.g., prior FARP-REQ with other Code Points), then
the implementation SHALL reattempt the FARP-REQ with the MATCH_WW_PN
Code Point.
Rajagopal, et al. Standards Track [Page 24]
RFC 2625 IP and ARP over Fibre Channel June 1999
Getting multiple FARP Replies corresponding to a single FARP-REQ
should normally never occur. It is beyond the scope of this document
to specify conditions under which this error may occur or what the
corrective action ought to be.
6. Exchange Management
6.1 Exchange Origination
FC Exchanges shall be established to transfer data between ports.
Frames on IP exchanges shall not transfer Sequence Initiative. See
Appendix E for a discussion on FC Exchanges.
6.2 Exchange Termination
With the exception of the recommendations in Appendix F, Section F.1,
"Reliability in Class 3", the mechanism for aging or expiring
exchanges based on activity, timeout, or other method is outside the
scope of this document.
Exchanges may be terminated by either port. The Exchange Originator
may terminate Exchanges by setting the LS bit, following normal FC
standard FC-PH [2] rules. This specification prohibits the use of the
NOP ELS with LS set for Exchange termination.
Exchanges may be torn down by the Exchange Originator or Exchange
Responder by using the ABTS_LS protocol. The use of ABTS_LS for
terminating aged Exchanges or error recovery is outside the scope of
this document.
The termination of IP Exchanges by Logout is discouraged, since this
may terminate active Exchanges on other FC-4s.
7. Summary of Supported Features
Note: 'Settable' means support is as specified in the relevant
standard; all other key words are as defined earlier in this
document.
7.1 FC-4 Header
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Type Code ( = 5) ISO8802-2 LLC/SNAP | REQUIRED | 2 |
| Network_Headers | REQUIRED | 3 |
| Other Optional Headers | MUST NOT | |
+--------------------------------------------------------------------+
Rajagopal, et al. Standards Track [Page 25]
RFC 2625 IP and ARP over Fibre Channel June 1999
Notes:
1. This table applies only to FC-4 related data, such as IP and
ARP packets. This table does not apply to link services and
other non-FC-4 sequences (PLOGI, for example) that must occur
for normal operation.
2. The TYPE field in the FC Header (Word 2 bits 31-24) MUST
indicate ISO 8802-2 LLC/SNAP Encapsulation (Type 5). This
revision of the document focuses solely on the issues related
to running IP and ARP over FC. All other issues are outside
the scope of this document, including full support for IEEE
802.2 LLC.
3. DF_CTL field (Word 3, bits 23-16 of FC-Header) MUST indicate
the presence of a Network_Header (0010 0000) on the First
logical Frame of FC-4 Sequences. It should not indicate the
presence of a Network_Header on any subsequent frames of the
Sequence.
7.2 R_CTL
R_CTL in FC-Header: Word 0, bits 31-24
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Information Category (R_CTL Routing): | | |
| | | |
| FC-4 Device Data | REQUIRED | 1 |
| Extended Link Data | REQUIRED | |
| FC-4 Link Data | MUST NOT | |
| Video Data | MUST NOT | |
| Basic Link Data | REQUIRED | |
| Link Control | REQUIRED | |
| | | |
| R_CTL information : | | |
| | | |
| Uncategorized | MUST NOT | |
| Solicited Data | MUST NOT | |
| Unsolicited Control | REQUIRED | |
| Solicited Control | REQUIRED | |
| Unsolicited Data | REQUIRED | 1 |
| Data Descriptor | MUST NOT | |
| Unsolicited Command | MUST NOT | |
| Command Status | MUST NOT | |
+--------------------------------------------------------------------+
Rajagopal, et al. Standards Track [Page 26]
RFC 2625 IP and ARP over Fibre Channel June 1999
Notes:
1. This is REQUIRED for FC-4 (IP and ARP) packets
- Routing bits of R_CTL field MUST indicate Device Data
frames (0000)
- Information Category of R_CTL field MUST indicate
Unsolicited Data (0100)
7.3 F_CTL
F_CTL in FC-Header: Word 2, bits 23-0
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Exchange Context | Settable | |
| Sequence Context | Settable | |
| First / Last / End Sequence (FS/LS/ES) | Settable | |
| Chained Sequence | MUST NOT | |
| Sequence Initiative (SI) | Settable | 1 |
| X_ID Reassigned / Invalidate | MUST NOT | |
| Unidirectional Transmit | Settable | |
| Continue Sequence Condition | REQUIRED | 2 |
| Abort Seq. Condition -continue and single Seq.| REQUIRED | 3 |
| Relative Offset - Unsolicited Data | Settable | 4 |
| Fill Bytes | Settable | |
+--------------------------------------------------------------------+
Notes
1. For FC-4 frames, each N_Port shall have a dedicated OX_ID for
sending data to each N_Port in the network and a dedicated
RX_ID for receiving data from each N_Port as well. Exchanges
are used in a unidirectional mode, thus setting Sequence
Initiative is not valid for FC-4 frames. Sequence Initiative is
valid when using Extended Link Services.
2. This field is required to be 00, no information.
3. Sequence error policy is requested by an exchange originator in
the F_CTL Abort Sequence Condition bits in the first data frame
of the exchange. For Classes 1 and 2, ACK frame is required to
be "continuous sequence".
4. Relative offset prohibited on all other types (Information
Category) of frames.
Rajagopal, et al. Standards Track [Page 27]
RFC 2625 IP and ARP over Fibre Channel June 1999
7.4 Sequences
+---------------------------------------------------------------------+
| Feature | Support |Notes |
+---------------------------------------------------------------------+
| Class 2 open Sequences / Exchange | 1 | 1 |
| Length of Seq. not limited by end-to-end credit | REQUIRED | 2 |
| IP and ARP Packet and FC Data Field sizes | REQUIRED | 3 |
| Capability to receive Sequence of maximum size | OPTIONAL | 4 |
| Sequence Streaming | MUST NOT | 5 |
| Stop Sequence P⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -