public enum OperationCode extends Enum<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
| 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.
|
| 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.
|
public static final OperationCode NOP_OUT
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.public static final OperationCode SCSI_COMMAND
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.public static final OperationCode SCSI_TM_REQUEST
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.public static final OperationCode LOGIN_REQUEST
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.public static final OperationCode TEXT_REQUEST
public static final OperationCode SCSI_DATA_OUT
public static final OperationCode LOGOUT_REQUEST
public static final OperationCode SNACK_REQUEST
public static final OperationCode NOP_IN
public static final OperationCode SCSI_RESPONSE
public static final OperationCode SCSI_TM_RESPONSE
public static final OperationCode LOGIN_RESPONSE
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.public static final OperationCode TEXT_RESPONSE
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.public static final OperationCode SCSI_DATA_IN
public static final OperationCode LOGOUT_RESPONSE
public static final OperationCode R2T
public static final OperationCode ASYNC_MESSAGE
public static final OperationCode REJECT
public static OperationCode[] values()
for (OperationCode c : OperationCode.values()) System.out.println(c);
public static OperationCode valueOf(String name)
name - the name of the enum constant to be returned.IllegalArgumentException - if this enum type has no constant
with the specified nameNullPointerException - if the argument is nullpublic final byte value()
public static final OperationCode valueOf(byte value)
value.value - The value to search for.value. Or null, if this value is
not defined by this
enumeration.Copyright © 2013 University of Konstanz, Distributed Systems Group. All Rights Reserved.