org.jscsi.parser

Enum OperationCode

java.lang.Object

java.lang.Enum<OperationCode>

org.jscsi.parser.OperationCode

All Implemented Interfaces:

Serializable, Comparable<OperationCode>

public enum OperationCode
extends Enum<OperationCode>

OperationCode

This enumeration defines all valid operation codes, which are conform to iSCSI Protocol (RFC 3720).

0x00	NOP-Out
0x01	SCSI Command (encapsulates a SCSI Command Descriptor Block)
0x02	SCSI Task Management function request
0x03	Login Request
0x04	Text Request
0x05	SCSI Data-Out (for WRITE operations)
0x06	Logout Request
0x10	SNACK Request
0x1c-0x1e	Vendor specific codes
0x20	NOP-In
0x21	SCSI Response - contains SCSI status and possibly sense information or other response information.
0x22	SCSI Task Management function response
0x23	Login Response
0x24	Text Response
0x25	SCSI Data-In - for READ operations.
0x26	Logout Response
0x31	Ready To Transfer (R2T) - sent by target when it is ready to receive data.
0x32	Asynchronous Message - sent by target to indicate certain special conditions.
0x3c-0x3e	Vendor specific codes
0x3f	Reject

Not Supported: 0x1c-0x1e Vendor specific codes

Author:

Volker Wildi

Enum Constant Summary

Enum Constants

Enum Constant and Description
ASYNC_MESSAGE Asynchronous Messages are used to carry SCSI asynchronous events (AEN) and iSCSI asynchronous messages.
LOGIN_REQUEST Login Requests and Responses are used exclusively during the Login Phase of each connection to set up the session and connection parameters.
LOGIN_RESPONSE Login Requests and Responses are used exclusively during the Login Phase of each connection to set up the session and connection parameters.
LOGOUT_REQUEST Logout Requests and Responses are used for the orderly closing of connections for recovery or maintenance.
LOGOUT_RESPONSE Logout Requests and Responses are used for the orderly closing of connections for recovery or maintenance.
NOP_IN This request/response pair may be used by an initiator and target as a "ping" mechanism to verify that a connection/session is still active and all of its components are operational.
NOP_OUT This request/response pair may be used by an initiator and target as a "ping" mechanism to verify that a connection/session is still active and all of its components are operational.
R2T R2T is the mechanism by which the SCSI target "requests" the initiator for output data.
REJECT Reject enables the target to report an iSCSI error condition (e.g., protocol, unsupported option) that uses a Reason field in the PDU header and includes the complete header of the bad PDU in the Reject PDU data segment.
SCSI_COMMAND This request carries the SCSI CDB and all the other SCSI execute command procedure call (see [SAM2]) IN arguments such as task attributes, Expected Data Transfer Length for one or both transfer directions (the latter for bidirectional commands), and Task Tag (as part of the I_T_L_x nexus).
SCSI_DATA_IN SCSI Data-Out and SCSI Data-In are the main vehicles by which SCSI data payload is carried between initiator and target.
SCSI_DATA_OUT SCSI Data-Out and SCSI Data-In are the main vehicles by which SCSI data payload is carried between initiator and target.
SCSI_RESPONSE The SCSI-Response carries all the SCSI execute-command procedure call (see [SAM2]) OUT arguments and the SCSI execute-command procedure call return value.
SCSI_TM_REQUEST The Task Management function request provides an initiator with a way to explicitly control the execution of one or more SCSI Tasks or iSCSI functions.
SCSI_TM_RESPONSE The Task Management function response carries an indication of function completion for a Task Management function request including how it was completed (response and qualifier) and additional information for failure responses.
SNACK_REQUEST With the SNACK Request, the initiator requests retransmission of numbered-responses or data from the target.
TEXT_REQUEST Text requests and responses are designed as a parameter negotiation vehicle and as a vehicle for future extension.
TEXT_RESPONSE Text requests and responses are designed as a parameter negotiation vehicle and as a vehicle for future extension.

Method Summary

Methods

Modifier and Type	Method and Description
byte	value() Returns the value of this enumeration.
static OperationCode	valueOf(byte value) Returns the constant defined for the given value.
static OperationCode	valueOf(String name) Returns the enum constant of this type with the specified name.
static OperationCode[]	values() Returns an array containing the constants of this enum type, in the order they are declared.

Methods inherited from class java.lang.Enum

clone, compareTo, equals, finalize, getDeclaringClass, hashCode, name, ordinal, toString, valueOf

Methods inherited from class java.lang.Object

getClass, notify, notifyAll, wait, wait, wait

Enum Constant Detail

NOP_OUT

public static final OperationCode NOP_OUT

This request/response pair may be used by an initiator and target as a "ping" mechanism to verify that a connection/session is still active and all of its components are operational. Such a ping may be triggered by the initiator or target. The triggering party indicates that it wants a reply by setting a value different from the default 0xffffffff in the corresponding Initiator/Target Transfer Tag. NOP-In/NOP-Out may also be used "unidirectional" to convey to the initiator/target command, status or data counter values when there is no other "carrier" and there is a need to update the initiator/ target.

SCSI_COMMAND

public static final OperationCode SCSI_COMMAND

This request carries the SCSI CDB and all the other SCSI execute command procedure call (see [SAM2]) IN arguments such as task attributes, Expected Data Transfer Length for one or both transfer directions (the latter for bidirectional commands), and Task Tag (as part of the I_T_L_x nexus). The I_T_L nexus is derived by the initiator and target from the LUN field in the request and the I_T nexus is implicit in the session identification. In addition, the SCSI-command PDU carries information required for the proper operation of the iSCSI protocol - the command sequence number ( CmdSN) for the session and the expected status number ( ExpStatSN) for the connection. All or part of the SCSI output (write) data associated with the SCSI command may be sent as part of the SCSI-Command PDU as a data segment.

SCSI_TM_REQUEST

public static final OperationCode SCSI_TM_REQUEST

The Task Management function request provides an initiator with a way to explicitly control the execution of one or more SCSI Tasks or iSCSI functions. The PDU carries a function identifier (which task management function to perform) and enough information to unequivocally identify the task or task-set on which to perform the action, even if the task(s) to act upon has not yet arrived or has been discarded due to an error. The referenced tag identifies an individual task if the function refers to an individual task. The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is identified by the LUN and the session identification (the session identifies an I_T nexus). For task sets, the CmdSN of the Task Management function request helps identify the tasks upon which to act, namely all tasks associated with a LUN and having a CmdSN preceding the Task Management function request CmdSN. For a Task Management function, the coordination between responses to the tasks affected and the Task Management function response is done by the target.

LOGIN_REQUEST

public static final OperationCode LOGIN_REQUEST

Login Requests and Responses are used exclusively during the Login Phase of each connection to set up the session and connection parameters. (The Login Phase consists of a sequence of login requests and responses carrying the same Initiator Task Tag.) A connection is identified by an arbitrarily selected connection-ID (CID) that is unique within a session. Similar to the Text Requests and Responses, Login Requests/Responses carry key=value text information with a simple syntax in the data segment. The Login Phase proceeds through several stages (security negotiation, operational parameter negotiation) that are selected with two binary coded fields in the header -- the "current stage" (CSG) and the "next stage" (NSG ) with the appearance of the latter being signaled by the "transit" flag (T). The first Login Phase of a session plays a special role, called the leading login, which determines some header fields (e.g., the version number, the maximum number of connections, and the session identification). The CmdSN initial value is also set by the leading login. StatSN for each connection is initiated by the connection login. A login request may indicate an implied logout (cleanup) of the connection to be logged in (a connection restart) by using the same Connection ID (CID) as an existing connection, as well as the same session identifying elements of the session to which the old connection was associated.

TEXT_REQUEST

public static final OperationCode TEXT_REQUEST

Text requests and responses are designed as a parameter negotiation vehicle and as a vehicle for future extension. In the data segment, Text Requests/Responses carry text information using a simple "key=value" syntax. Text Request/Responses may form extended sequences using the same Initiator Task Tag. The initiator uses the F (Final) flag bit in the text request header to indicate its readiness to terminate a sequence. The target uses the F (Final) flag bit in the text response header to indicate its consent to sequence termination. Text Request and Responses also use the Target Transfer Tag to indicate continuation of an operation or a new beginning. A target that wishes to continue an operation will set the Target Transfer Tag in a Text Response to a value different from the default 0xffffffff. An initiator willing to continue will copy this value into the Target Transfer Tag of the next Text Request. If the initiator wants to restart the current target negotiation (start fresh) will set the Target Transfer Tag to 0xffffffff. Although a complete exchange is always started by the initiator, specific parameter negotiations may be initiated by the initiator or target.

SCSI_DATA_OUT

public static final OperationCode SCSI_DATA_OUT

SCSI Data-Out and SCSI Data-In are the main vehicles by which SCSI data payload is carried between initiator and target. Data payload is associated with a specific SCSI command through the Initiator Task Tag. For target convenience, outgoing solicited data also carries a Target Transfer Tag (copied from R2T) and the LUN. Each PDU contains the payload length and the data offset relative to the buffer address contained in the SCSI execute command procedure call. In each direction, the data transfer is split into "sequences". An end-of-sequence is indicated by the F bit. An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in response to an R2T. Input sequences are built to enable the direction switching for bidirectional commands. For input, the target may request positive acknowledgement of input data. This is limited to sessions that support error recovery and is implemented through the A bit in the SCSI Data-In PDU header. Data-In and Data-Out PDUs also carry the DataSN to enable the initiator and target to detect missing PDUs (discarded due to an error). In addition, StatSN is carried by the Data-In PDUs. To enable a SCSI command to be processed while involving a minimum number of messages, the last SCSI Data-In PDU passed for a command may also contain the status if the status indicates termination with no exceptions (no sense or response involved).

LOGOUT_REQUEST

public static final OperationCode LOGOUT_REQUEST

Logout Requests and Responses are used for the orderly closing of connections for recovery or maintenance. The logout request may be issued following a target prompt (through an asynchronous message) or at an initiators initiative. When issued on the connection to be logged out, no other request may follow it.

SNACK_REQUEST

public static final OperationCode SNACK_REQUEST

With the SNACK Request, the initiator requests retransmission of numbered-responses or data from the target. A single SNACK request covers a contiguous set of missing items, called a run, of a given type of items. The type is indicated in a type field in the PDU header. The run is composed of an initial item (StatSN, DataSN, R2TSN) and the number of missed Status, Data, or R2T PDUs. For long Data-In sequences, the target may request (at predefined minimum intervals) a positive acknowledgement for the data sent. A SNACK request with a type field that indicates ACK and the number of Data-In PDUs acknowledged conveys this positive acknowledgement.

NOP_IN

public static final OperationCode NOP_IN

This request/response pair may be used by an initiator and target as a "ping" mechanism to verify that a connection/session is still active and all of its components are operational. Such a ping may be triggered by the initiator or target. The triggering party indicates that it wants a reply by setting a value different from the default 0xffffffff in the corresponding Initiator/Target Transfer Tag. NOP-In/NOP-Out may also be used "unidirectional" to convey to the initiator/target command, status or data counter values when there is no other "carrier" and there is a need to update the initiator/ target.

SCSI_RESPONSE

public static final OperationCode SCSI_RESPONSE

The SCSI-Response carries all the SCSI execute-command procedure call (see [SAM2]) OUT arguments and the SCSI execute-command procedure call return value. The SCSI-Response contains the residual counts from the operation, if any, an indication of whether the counts represent an overflow or an underflow, and the SCSI status if the status is valid or a response code (a non-zero return value for the execute-command procedure call) if the status is not valid. For a valid status that indicates that the command has been processed, but resulted in an exception (e.g., a SCSI CHECK CONDITION), the PDU data segment contains the associated sense data. The use of Autosense ([SAM2]) is REQUIRED by iSCSI. Some data segment content may also be associated (in the data segment) with a non-zero response code. In addition, the SCSI-Response PDU carries information required for the proper operation of the iSCSI protocol:

• The number of Data-In PDUs that a target has sent (to enable the initiator to check that all have arrived).
• StatSN - the Status Sequence Number on this connection
• ExpCmdSN - the next Expected Command Sequence Number at the target.
• MaxCmdSN - the maximum CmdSN acceptable at the target from this initiator.

SCSI_TM_RESPONSE

public static final OperationCode SCSI_TM_RESPONSE

The Task Management function response carries an indication of function completion for a Task Management function request including how it was completed (response and qualifier) and additional information for failure responses. After the Task Management response indicates Task Management function completion, the initiator will not receive any additional responses from the affected tasks.

LOGIN_RESPONSE

public static final OperationCode LOGIN_RESPONSE

Login Requests and Responses are used exclusively during the Login Phase of each connection to set up the session and connection parameters. (The Login Phase consists of a sequence of login requests and responses carrying the same Initiator Task Tag.) A connection is identified by an arbitrarily selected connection-ID (CID) that is unique within a session. Similar to the Text Requests and Responses, Login Requests/Responses carry key=value text information with a simple syntax in the data segment. The Login Phase proceeds through several stages (security negotiation, operational parameter negotiation) that are selected with two binary coded fields in the header -- the "current stage" (CSG) and the "next stage" (NSG ) with the appearance of the latter being signaled by the "transit" flag (T). The first Login Phase of a session plays a special role, called the leading login, which determines some header fields (e.g., the version number, the maximum number of connections, and the session identification). The CmdSN initial value is also set by the leading login. StatSN for each connection is initiated by the connection login. A login request may indicate an implied logout (cleanup) of the connection to be logged in (a connection restart) by using the same Connection ID (CID) as an existing connection, as well as the same session identifying elements of the session to which the old connection was associated.

TEXT_RESPONSE

public static final OperationCode TEXT_RESPONSE

Text requests and responses are designed as a parameter negotiation vehicle and as a vehicle for future extension. In the data segment, Text Requests/Responses carry text information using a simple "key=value" syntax. Text Request/Responses may form extended sequences using the same Initiator Task Tag. The initiator uses the F (Final) flag bit in the text request header to indicate its readiness to terminate a sequence. The target uses the F (Final) flag bit in the text response header to indicate its consent to sequence termination. Text Request and Responses also use the Target Transfer Tag to indicate continuation of an operation or a new beginning. A target that wishes to continue an operation will set the Target Transfer Tag in a Text Response to a value different from the default 0xffffffff. An initiator willing to continue will copy this value into the Target Transfer Tag of the next Text Request. If the initiator wants to restart the current target negotiation (start fresh) will set the Target Transfer Tag to 0xffffffff. Although a complete exchange is always started by the initiator, specific parameter negotiations may be initiated by the initiator or target.

SCSI_DATA_IN

public static final OperationCode SCSI_DATA_IN

SCSI Data-Out and SCSI Data-In are the main vehicles by which SCSI data payload is carried between initiator and target. Data payload is associated with a specific SCSI command through the Initiator Task Tag. For target convenience, outgoing solicited data also carries a Target Transfer Tag (copied from R2T) and the LUN. Each PDU contains the payload length and the data offset relative to the buffer address contained in the SCSI execute command procedure call. In each direction, the data transfer is split into "sequences". An end-of-sequence is indicated by the F bit. An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in response to an R2T. Input sequences are built to enable the direction switching for bidirectional commands. For input, the target may request positive acknowledgement of input data. This is limited to sessions that support error recovery and is implemented through the A bit in the SCSI Data-In PDU header. Data-In and Data-Out PDUs also carry the DataSN to enable the initiator and target to detect missing PDUs (discarded due to an error). In addition, StatSN is carried by the Data-In PDUs. To enable a SCSI command to be processed while involving a minimum number of messages, the last SCSI Data-In PDU passed for a command may also contain the status if the status indicates termination with no exceptions (no sense or response involved).

LOGOUT_RESPONSE

public static final OperationCode LOGOUT_RESPONSE

Logout Requests and Responses are used for the orderly closing of connections for recovery or maintenance. The Logout Response indicates that the connection or session cleanup is completed and no other responses will arrive on the connection (if received on the logging out connection). In addition, the Logout Response indicates how long the target will continue to hold resources for recovery (e.g., command execution that continues on a new connection) in the text key Time2Retain and how long the initiator must wait before proceeding with recovery in the text key Time2Wait.

R2T

public static final OperationCode R2T

R2T is the mechanism by which the SCSI target "requests" the initiator for output data. R2T specifies to the initiator the offset of the requested data relative to the buffer address from the execute command procedure call and the length of the solicited data. To help the SCSI target associate the resulting Data-Out with an R2T, the R2T carries a Target Transfer Tag that will be copied by the initiator in the solicited SCSI Data-Out PDUs. There are no protocol specific requirements with regard to the value of these tags, but it is assumed that together with the LUN, they will enable the target to associate data with an R2T. R2T also carries information required for proper operation of the iSCSI protocol, such as:

• R2TSN (to enable an initiator to detect a missing R2T)
• StatSN
• ExpCmdSN
• MaxCmdSN

ASYNC_MESSAGE

public static final OperationCode ASYNC_MESSAGE

Asynchronous Messages are used to carry SCSI asynchronous events (AEN) and iSCSI asynchronous messages. When carrying an AEN, the event details are reported as sense data in the data segment.

REJECT

public static final OperationCode REJECT

Reject enables the target to report an iSCSI error condition (e.g., protocol, unsupported option) that uses a Reason field in the PDU header and includes the complete header of the bad PDU in the Reject PDU data segment.

Method Detail

values

public static OperationCode[] values()

Returns an array containing the constants of this enum type, in the order they are declared. This method may be used to iterate over the constants as follows:

for (OperationCode c : OperationCode.values())
    System.out.println(c);

Returns:

an array containing the constants of this enum type, in the order they are declared

valueOf

public static OperationCode valueOf(String name)

Returns the enum constant of this type with the specified name. The string must match exactly an identifier used to declare an enum constant in this type. (Extraneous whitespace characters are not permitted.)

Parameters:

name - the name of the enum constant to be returned.

Returns:

the enum constant with the specified name

Throws:

IllegalArgumentException - if this enum type has no constant with the specified name

NullPointerException - if the argument is null

value

public final byte value()

Returns the value of this enumeration.

Returns:

The value of this enumeration.

valueOf

public static final OperationCode valueOf(byte value)

Returns the constant defined for the given value.

Parameters:

value - The value to search for.

Returns:

The constant defined for the given value. Or null, if this value is not defined by this enumeration.