
org.jscsi.parser.datasegment.OperationalTextKey Maven / Gradle / Ivy
/**
* Copyright (c) 2012, University of Konstanz, Distributed Systems Group All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
* following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of
* conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation and/or other materials provided with the
* distribution. * Neither the name of the University of Konstanz nor the names of its contributors may be used to
* endorse or promote products derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
package org.jscsi.parser.datasegment;
import java.util.HashMap;
import java.util.Map;
/**
* This enumeration defines all valid operational text keys, which are defined in the iSCSI STandard (RFC 3720).
*/
public enum OperationalTextKey {
/**
* Use: During Login - Security Negotiation Senders: Initiator and Target Scope: connection AuthMethod =
* <list-of-values> The main item of security negotiation is the authentication method (AuthMethod). The
* authentication methods that can be used (appear in the list-of-values) are either those listed in the following
* table or are vendor-unique methods:
*
*
*
* Name
* Description
*
*
* KRB5
* Kerberos V5 - defined in [RFC1510]
*
*
* SPKM1
* Simple Public-Key GSS-API Mechanism defined in [RFC2025]
*
*
* SPKM2
* Simple Public-Key GSS-API Mechanism defined in [RFC2025]
*
*
* SRP
* Secure Remote Password defined in [RFC2945]
*
*
* CHAP
* Challenge Handshake Authentication Protocol defined in [RFC1994]
*
*
* None
* No authentication
*
*
*
* The AuthMethod selection is followed by an "authentication exchange" specific to the authentication method
* selected. The authentication method proposal may be made by either the initiator or the target. However the
* initiator MUST make the first step specific to the selected authentication method as soon as it is selected. It
* follows that if the target makes the authentication method proposal the initiator sends the first keys(s) of the
* exchange together with its authentication method selection. The authentication exchange authenticates the
* initiator to the target, and optionally, the target to the initiator. Authentication is OPTIONAL to use but MUST
* be supported by the target and initiator. The initiator and target MUST implement CHAP. All other authentication
* methods are OPTIONAL. Private or public extension algorithms MAY also be negotiated for authentication methods.
* Whenever a private or public extension algorithm is part of the default offer (the offer made in absence of
* explicit administrative action) the implementer MUST ensure that CHAP is listed as an alternative in the default
* offer and "None" is not part of the default offer. Extension authentication methods MUST be named using one of
* the following two formats:
*
* - Z-reversed.vendor.dns_name.do_something=
* - Z<#><IANA-registered-string>=
*
* Authentication methods named using the Z- format are used as private extensions. Authentication methods named
* using the Z# format are used as public extensions that must be registered with IANA and MUST be described by an
* informational RFC. For all of the public or private extension authentication methods, the method specific keys
* MUST conform to the format specified in Section 5.1 Text Format for standard-label. To identify the vendor for
* private extension authentication methods, we suggest you use the reversed DNS-name as a prefix to the proper
* digest names. The part of digest-name following Z- and Z# MUST conform to the format for standard-label specified
* in Section 5.1 Text Format. Support for public or private extension authentication methods is OPTIONAL. The
* following subsections define the specific exchanges for each of the standardized authentication methods. As
* mentioned earlier the first step is always done by the initiator.
*/
AUTH_METHOD("AuthMethod"),
/**
* Use: IO
* Senders: Initiator and Target
* Scope: CO
*
* HeaderDigest = <list-of-values>
* DataDigest = <list-of-values>
*
* Default is None for both HeaderDigest and DataDigest.
*
* Digests enable the checking of end-to-end, non-cryptographic data integrity beyond the integrity checks provided
* by the link layers and the covering of the whole communication path including all elements that may change the
* network level PDUs such as routers, switches, and proxies.
* The following table lists cyclic integrity checksums that can be negotiated for the digests and that MUST be
* implemented by every iSCSI initiator and target. These digest options only have error detection significance.
*
*
*
* Name
* Description
* Generator
*
*
* CRC32CDigest
* 32 bit CRC
* 0x11edc6f41
*
*
* None
* no digest
*
*
*
* The generator polynomial for this digest is given in hex-notation (e.g., 0x3b stands for 0011 1011 and the
* polynomial is x**5+X**4+x**3+x+1).
*
* When the Initiator and Target agree on a digest, this digest MUST be used for every PDU in Full Feature Phase.
* Padding bytes, when present in a segment covered by a CRC, SHOULD be set to 0 and are included in the CRC.
* The CRC MUST be calculated by a method that produces the same results as the following process:
*
* - The PDU bits are considered as the coefficients of a polynomial M(x) of degree n-1; bit 7 of the lowest
* numbered byte is considered the most significant bit (x^n-1), followed by bit 6 of the lowest numbered byte
* through bit 0 of the highest numbered byte (x^0).
* - The most significant 32 bits are complemented.
* - The polynomial is multiplied by x^32 then divided by G(x). The generator polynomial produces a remainder R(x)
* of degree <= 31.
* - The coefficients of R(x) are considered a 32 bit sequence.
* - The bit sequence is complemented and the result is the CRC.
* - The CRC bits are mapped into the digest word. The x^31 coefficient in bit 7 of the lowest numbered byte of
* the digest continuing through to the byte up to the x^24 coefficient in bit 0 of the lowest numbered byte,
* continuing with the x^23 coefficient in bit 7 of next byte through x^0 in bit 0 of the highest numbered byte.
* - Computing the CRC over any segment (data or header) extended to include the CRC built using the generator
* 0x11edc6f41 will always get the value 0x1c2d19ed as its final remainder (R(x)). This value is given here in its
* polynomial form (i.e., not mapped as the digest word).
*
* For a discussion about selection criteria for the CRC, see [RFC3385]. For a detailed analysis of the iSCSI
* polynomial, see [Castagnoli93].
* Private or public extension algorithms MAY also be negotiated for digests. Whenever a private or public digest
* extension algorithm is part of the default offer (the offer made in absence of explicit administrative action)
* the implementer MUST ensure that CRC32CDigest is listed as an alternative in the default offer and "None" is not
* part of the default offer.
* Extension digest algorithms MUST be named using one of the following two formats:
*
* - Y-reversed.vendor.dns_name.do_something=
* - Y<#><IANA-registered-string>=
*
* Digests named using the Y- format are used for private purposes (unregistered). Digests named using the Y# format
* (public extension) must be registered with IANA and MUST be described by an informational RFC.
* For private extension digests, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to
* the proper digest names.
* The part of digest-name following Y- and Y# MUST conform to the format for standard-label specified in Section
* 5.1 Text Format. Support for public or private extension digests is OPTIONAL.
*/
HEADER_DIGEST("HeaderDigest"),
/**
* See for the details in the HEADER_DIGEST documentation above.
*/
DATA_DIGEST("DataDigest"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery
*
* MaxConnections=<numerical-value-from-1-to-65535>
*
* Default is 1
.
* Result function is Minimum.
*
* Initiator and target negotiate the maximum number of connections requested/acceptable.
*/
MAX_CONNECTIONS("MaxConnections"),
/**
* Use: FFPO
* Senders: Initiator
* Scope: SW
*
* For a complete description, see Appendix D. - SendTargets Operation -.
*/
SEND_TARGETS("SendTargets"),
/**
* Use: IO by initiator, FFPO by target - only as response to a SendTargets, Declarative, Any-Stage
* Senders: Initiator and Target
* Scope: SW
*
* TargetName=<iSCSI-name-value>
*
* Examples:
* TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678
* TargetName=eui.020000023B040506
*
* The initiator of the TCP connection MUST provide this key to the remote endpoint in the first login request if
* the initiator is not establishing a discovery session. The iSCSI Target Name specifies the worldwide unique name
* of the target.
* The TargetName key may also be returned by the "SendTargets" text request (which is its only use when issued by a
* target). TargetName MUST not be redeclared within the login phase.
*/
TARGET_NAME("TargetName"),
/**
* Use: IO, Declarative, Any-Stage
* Senders: Initiator
* Scope: SW
*
* InitiatorName=<iSCSI-name-value>
*
* Examples:
* InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345
* InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90
*
* The initiator of the TCP connection MUST provide this key to the remote endpoint at the first Login of the Login
* Phase for every connection. The InitiatorName key enables the initiator to identify itself to the remote
* endpoint.
* InitiatorName MUST not be redeclared within the login phase.
*/
INITIATOR_NAME("InitiatorName"),
/**
* Use: ALL, Declarative, Any-Stage
* Senders: Target
* Scope: SW
* TargetAlias=<iSCSI-local-name-value>
*
* Examples: TargetAlias=Bob-s Disk
* TargetAlias=Database Server 1 Log Disk
* TargetAlias=Web Server 3 Disk 20
*
* If a target has been configured with a human-readable name or description, this name SHOULD be communicated to
* the initiator during a Login Response PDU if SessionType=Normal (see Section 12.21 SessionType). This string is
* not used as an identifier, nor is it meant to be used for authentication or authorization decisions. It can be
* displayed by the initiator’s user interface in a list of targets to which it is connected.
*/
TARGET_ALIAS("TargetAlias"),
/**
* Use: ALL, Declarative, Any-Stage
* Senders: Initiator
* Scope: SW
*
* InitiatorAlias=<iSCSI-local-name-value>
*
* Examples:
* InitiatorAlias=Web Server 4
* InitiatorAlias=spyalley.nsa.gov
* InitiatorAlias=Exchange Server
*
* If an initiator has been configured with a human-readable name or description, it SHOULD be communicated to the
* target during a Login Request PDU. If not, the host name can be used instead. This string is not used as an
* identifier, nor is meant to be used for authentication or authorization decisions. It can be displayed by the
* target's user interface in a list of initiators to which it is connected.
*/
INITIATOR_ALIAS("InitiatorAlias"),
/**
* Use: ALL, Declarative, Any-Stage
* Senders: Target
* Scope: SW
* TargetAddress=domainname[:port][,portal-group-tag]
*
* The domainname can be specified as either a DNS host name, a dotted-decimal IPv4 address, or a bracketed IPv6
* address as specified in [RFC2732].
*
* If the TCP port is not specified, it is assumed to be the IANA-assigned default port for iSCSI (see Section 13
* IANA Considerations).
* If the TargetAddress is returned as the result of a redirect status in a login response, the comma and portal
* group tag MUST be omitted. If the TargetAddress is returned within a SendTargets response, the portal group tag
* MUST be included.
*
* Examples:
* TargetAddress=10.0.0.1:5003,1
* TargetAddress=[1080:0:0:0:8:800:200C:417A],65
* TargetAddress=[1080::8:800:200C:417A]:5003,1
* TargetAddress=computingcenter.example.com,23
*
* Use of the portal-group-tag is described in Appendix D. - SendTargets Operation -. The formats for the port and
* portal-group-tag are the same as the one specified in Section 12.9 TargetPortalGroupTag.
*/
TARGET_ADDRESS("TargetAddress"),
/**
* Use: IO by target, Declarative, Any-Stage
* Senders: Target
* Scope: SW
*
* TargetPortalGroupTag=<16-bit-binary-value>
*
* Examples:
* TargetPortalGroupTag=1
*
* The target portal group tag is a 16-bit binary-value that uniquely identifies a portal group within an iSCSI
* target node. This key carries the value of the tag of the portal group that is servicing the Login request. The
* iSCSI target returns this key to the initiator in the Login Response PDU to the first Login Request PDU that has
* the C bit set to 0 when TargetName is given by the initiator.
* For the complete usage expectations of this key see Section 5.3 Login Phase.
*/
TARGET_PORTAL_GROUP_TAG("TargetPortalGroupTag"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery
*
* InitialR2T=<boolean-value>
*
* Examples:
* I->InitialR2T=No
* T->InitialR2T=No
*
* Default is Yes.
* Result function is OR.
*
* The InitialR2T key is used to turn off the default use of R2T for unidirectional and the output part of
* bidirectional commands, thus allowing an initiator to start sending data to a target as if it has received an
* initial R2T with Buffer Offset=Immediate Data Length and Desired Data Transfer Length=(min(FirstBurstLength,
* Expected Data Transfer Length) - Received Immediate Data Length).
* The default action is that R2T is required, unless both the initiator and the target send this key-pair attribute
* specifying InitialR2T=No. Only the first outgoing data burst (immediate data and/or separate PDUs) can be sent
* unsolicited (i.e., not requiring an explicit R2T).
*/
INITIAL_R2T("InitialR2T"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery
*
* ImmediateData=<boolean-value>
*
* Default is Yes.
* Result function is AND.
*
* The initiator and target negotiate support for immediate data. To turn immediate data off, the initiator or
* target must state its desire to do so. ImmediateData can be turned on if both the initiator and target have
* ImmediateData=Yes.
* If ImmediateData is set to Yes and InitialR2T is set to Yes (default), then only immediate data are accepted in
* the first burst. If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send
* unsolicited data and the target MUST reject unsolicited data with the corresponding response code.
* If ImmediateData is set to No and InitialR2T is set to No, then the initiator MUST NOT send unsolicited immediate
* data, but MAY send one unsolicited burst of Data-Out PDUs.
* If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate
* data and/or one unsolicited burst of Data-Out PDUs.
*
* The following table is a summary of unsolicited data options:
*
*
* InitialR2T
* ImmediateData
* Unsolicited Data Out PDUs
* Immediate Data
*
*
* No
* No
* Yes
* No
*
*
* No
* Yes
* Yes
* Yes
*
*
* Yes
* No
* No
* No
*
*
* Yes
* Yes
* No
* Yes
*
*
*/
IMMEDIATE_DATA("ImmediateData"),
/**
* Use: ALL, Declarative
* Senders: Initiator and Target
*
* Scope: CO
*
* MaxRecvDataSegmentLength=<numerical-value-512-to-(2**24-1)>
*
* Default is 8192 bytes.
*
* The initiator or target declares the maximum data segment length in bytes it can receive in an iSCSI PDU.
* The transmitter (initiator or target) is required to send PDUs with a data segment that does not exceed
* MaxRecvDataSegmentLength of the receiver.
* A target receiver is additionally limited by MaxBurstLength for solicited data and FirstBurstLength for
* unsolicited data. An initiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor unsolicited PDUs
* exceeding FirstBurstLength (or FirstBurstLength-Immediate Data Length if immediate data were sent).
*/
MAX_RECV_DATA_SEGMENT_LENGTH("MaxRecvDataSegmentLength"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery
*
* MaxBurstLength=<numerical-value-512-to-(2**24-1)>
*
* Default is 262144
(256
Kbytes).
* Result function is Minimum.
*
* The initiator and target negotiate maximum SCSI data payload in bytes in a Data-In or a solicited Data-Out iSCSI
* sequence. A sequence consists of one or more consecutive Data-In or Data-Out PDUs that end with a Data-In or
* Data-Out PDU with the F bit set to one.
*/
MAX_BURST_LENGTH("MaxBurstLength"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery
* Irrelevant when: ( InitialR2T=Yes and ImmediateData=No )
*
* FirstBurstLength=<numerical-value-512-to-(2**24-1)>
*
* Default is 65536
(64
Kbytes).
* Result function is Minimum.
*
* The initiator and target negotiate the maximum amount in bytes of unsolicited data an iSCSI initiator may send to
* the target during the execution of a single SCSI command. This covers the immediate data (if any) and the
* sequence of unsolicited Data-Out PDUs (if any) that follow the command.
* FirstBurstLength MUST NOT exceed MaxBurstLength.
*/
FIRST_BURST_LENGTH("FirstBurstLength"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
*
* DefaultTime2Wait=<numerical-value-0-to-3600>
*
* Default is 2
.
* Result function is Maximum.
*
* The initiator and target negotiate the minimum time, in seconds, to wait before attempting an explicit/implicit
* logout or an active task reassignment after an unexpected connection termination or a connection reset.
* A value of 0
indicates that logout or active task reassignment can be attempted immediately.
*/
DEFAULT_TIME_2_WAIT("DefaultTime2Wait"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
*
* DefaultTime2Retain=<numerical-value-0-to-3600>
*
* Default is 20
. Result function is Minimum.
*
* The initiator and target negotiate the maximum time, in seconds after an initial wait (Time2Wait), before which
* an active task reassignment is still possible after an unexpected connection termination or a connection reset.
* This value is also the session state timeout if the connection in question is the last LOGGED_IN connection in
* the session. A value of 0 indicates that connection/task state is immediately discarded by the target.
*/
DEFAULT_TIME_2_RETAIN("DefaultTime2Retain"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
*
* MaxOutstandingR2T=<numerical-value-from-1-to-65535>
*
* Irrelevant when: SessionType=Discovery
* Default is 1
.
* Result function is Minimum.
*
* Initiator and target negotiate the maximum number of outstanding R2Ts per task, excluding any implied initial R2T
* that might be part of that task. An R2T is considered outstanding until the last data PDU (with the
* F
bit set to 1
) is transferred, or a sequence reception timeout (Section 6.1.4.1
* Recovery Within-command) is encountered for that data sequence.
*/
MAX_OUTSTANDING_R2T("MaxOutstandingR2T"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery
*
* DataPDUInOrder=<boolean-value>
*
* Default is Yes.
* Result function is OR.
*
* No is used by iSCSI to indicate that the data PDUs within sequences can be in any order. Yes is used to indicate
* that data PDUs within sequences have to be at continuously increasing addresses and overlays are forbidden.
*/
DATA_PDU_IN_ORDER("DataPDUInOrder"),
/**
* Use: LO
* Senders: Initiator and Target
* Scope: SW
* Irrelevant when: SessionType=Discovery
*
* DataSequenceInOrder=<boolean-value>
*
* Default is Yes.
* Result function is OR.
*
* A Data Sequence is a sequence of Data-In or Data-Out PDUs that end with a Data-In or Data-Out PDU with the F bit
* set to one. A Data-Out sequence is sent either unsolicited or in response to an R2T. Sequences cover an
* offset-range.
* If DataSequenceInOrder is set to No, Data PDU sequences may be transferred in any order.
* If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing
* sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data
* sequence).
* If DataSequenceInOrder is set to Yes, a target may retry at most the last R2T, and an initiator may at most
* request retransmission for the last read data sequence. For this reason, if ErrorRecoveryLevel is not
* 0
and DataSequenceInOrder is set to Yes then MaxOustandingR2T MUST be set to 1
.
*/
DATA_SEQUENCE_IN_ORDER("DataSequenceInOrder"),
/**
* Use: LO
*
* Senders: Initiator and Target
*
* Scope: SW
*
*
* ErrorRecoveryLevel=<numerical-value-0-to-2>
*
* Default is 0
.
*
* Result function is Minimum.
*
* The initiator and target negotiate the recovery level supported. Recovery levels represent a combination of
* recovery capabilities. Each recovery level includes all the capabilities of the lower recovery levels and adds
* some new ones to them.
*
* In the description of recovery mechanisms, certain recovery classes are specified. Section 6.1.5 Error Recovery
* Hierarchy describes the mapping between the classes and the levels.
*/
ERROR_RECOVERY_LEVEL("ErrorRecoveryLevel"),
/**
* Use: LO, Declarative, Any-Stage
*
* Senders: Initiator
*
* Scope: SW
*
>
* SessionType= <Discovery|Normal>
*
* Default is Normal.
*
* The initiator indicates the type of session it wants to create. The target can either accept it or reject it.
*
* A discovery session indicates to the Target that the only purpose of this Session is discovery. The only requests
* a target accepts in this type of session are a text request with a SendTargets key and a logout request with
* reason "close the session".
*
* The discovery session implies MaxConnections = 1
and overrides both the default and an explicit
* setting.
*/
SESSION_TYPE("SessionType"),
/**
* Use: LO, Declarative, Any-Stage
*
* Senders: Initiator
*
* Scope: SW
*
>
* SessionBalancer= <RoundRobinSessionBalancer|ParallelSessionBalancer>
*
* Default is RoundRobinSessionBalancer.
*
* The SessionBalancer to use;
*
*/
SESSION_BALANCER("SessionBalancer"),
/**
* OFMarker = <boolean-value>
*
* IFMarker = <boolean-value>
*
* Default is No
. Result function is AND
.
*
* IFMarker is used to turn on or off the target to initiator markers on the connection.
*
* Examples:
*
* I->OFMarker=Yes,IFMarker=Yes
*
* T->OFMarker=Yes,IFMarker=Yes
*
* Results in the Marker being used in both directions while:
*
* I->OFMarker=Yes,IFMarker=Yes
*
* T->OFMarker=Yes,IFMarker=No
*
* Results in Marker being used from the initiator to the target, but not from the target to initiator.
*/
IF_MARKER("IFMarker"),
/**
* OFMarkInt is Irrelevant when: OFMarker = No
*
* IFMarkInt is Irrelevant when: IFMarker = No
*
* Offering:
*
* OFMarkInt=<numeric-range-from-1-to-65535>
* IFMarkInt=<numeric-range-from-1-to-65535>
*
* Responding:
*
* OFMarkInt=<numeric-value-from-1-to-65535>|Reject
* IFMarkInt=<numeric-value-from-1-to-65535>|Reject
*
* IFMarkInt is used to set the interval for the target to initiator markers on the connection.
*
* For the offering, the initiator or target indicates the minimum to maximum interval (in 4-byte words) it wants
* the markers for one or both directions. In case it only wants a specific value, only a single value has to be
* specified. The responder selects a value within the minimum and maximum offered or the only value offered or
* indicates through the xFMarker key=value its inability to set and/or receive markers. When the interval is
* unacceptable the responder answers with "Reject". Reject is resetting the marker function in the specified
* direction (Output or Input) to No.
*
* The interval is measured from the end of a marker to the beginning of the next marker. For example, a value of
* 1024
means 1024
words (4096
bytes of iSCSI payload between markers).
*
* The default is 2048
.
*
* @see #IF_MARKER
*/
IF_MARK_INT("IFMarkInt"),
/**
* OFMarker is used to turn on or off the initiator to target markers on the connection.
*
*
* @see #IF_MARKER
*/
OF_MARKER("OFMarker"),
/**
* OFMarkInt is used to set the interval for the initiator to target markers on the connection.
*
* @see #OF_MARKER
* @see #IF_MARK_INT
*/
OF_MARK_INT("OFMarkInt");
private final String value;
private static Map mapping;
static {
OperationalTextKey.mapping = new HashMap();
for (OperationalTextKey s : values()) {
OperationalTextKey.mapping.put(s.value, s);
}
}
private OperationalTextKey (final String newValue) {
value = newValue;
}
/**
* Returns the value of this enumeration.
*
* @return The value of this enumeration.
*/
public final String value () {
return value;
}
/**
* Returns the constant defined for the given value
.
*
* @param value The value to search for.
* @return The constant defined for the given value
. Or null
, if this value is not defined
* by this enumeration.
*/
public static final OperationalTextKey valueOfEx (final String value) {
return OperationalTextKey.mapping.get(value);
}
// --------------------------------------------------------------------------
// --------------------------------------------------------------------------
// --------------------------------------------------------------------------
// --------------------------------------------------------------------------
}