T11-FC-SP-SA-MIB

InterfaceIndexOrZeroThis textual convention is an extension of the InterfaceIndex convention. The latter defines a greater than zero value used to identify an interface or interface sub-layer in the managed system. This extension permits the additional value of zero. the value zero is object-specific and must therefore be defined as part of the description of any object which uses this syntax. Examples of the usage of zero might include situations where interface was unknown, or when none or all interfaces need to be referenced. (0..2147483647) · Integer32 · hint d

This object has a non-zero value to identify a particular interface, or the value zero to indicate that the information in this row applies to all (of the management instance's) interfaces to the particular Fabric. If any row has a non-zero value of t11FcSpSaIfIndex, then all rows for the same Fibre Channel management instance must also have a non-zero value of t11FcSpSaIfIndex and thereby be specific to a particular interface. As and when zero values of t11FcSpSaIfIndex are used in this table, then they must also be used in each other table that has t11FcSpSaIfIndex in its INDEX clause.

T11FabricIndexA Fabric Index that is used as a unique index value to identify a particular Fabric within one (or more) physical infrastructures. In an environment that is conformant to FC-SW-3, where there is always exactly one Fabric in a single physical infrastructure, the value of this Fabric Index will always be 1. However, the current standard, FC-SW-4, defines how multiple Fabrics, each with its own management instrumentation, could operate within one (or more) physical infrastructures. When such multiple Fabrics are in use, this index value is used to uniquely identify a particular Fabric within a physical infrastructure. Note that the value of this textual convention has a range of (0..4095) so as to be consistent with FC-SW-4, which says that a 'VF_ID Bitmap' is 512 bytes long, with the high-order bit representing VF_ID zero, and the low-order bit representing 4095.Reference: Fibre Channel - Switch Fabric - 4 (FC-SW-4), ANSI INCITS 418-2006, section 6.1.27.2.4. (0..4095) · Unsigned32 · hint d

An index value that uniquely identifies a particular Fabric.

T11FcSpTransformsA list of the standardized transforms that are defined by FC-SP for use with ESP_Header, CT_Authentication, and/or IKEv2 Support.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Appendix A.3.1, tables A.23, A.24, A.25, A.26. · BITS

A list of the standardized transforms supported by this entity on this interface for ESP_Header protection. ⓘ

T11FcSpTransformsA list of the standardized transforms that are defined by FC-SP for use with ESP_Header, CT_Authentication, and/or IKEv2 Support.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Appendix A.3.1, tables A.23, A.24, A.25, A.26. · BITS

A list of the standardized transforms supported by this entity on this interface for CT_Authentication protection. ⓘ

T11FcSpTransformsA list of the standardized transforms that are defined by FC-SP for use with ESP_Header, CT_Authentication, and/or IKEv2 Support.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, Appendix A.3.1, tables A.23, A.24, A.25, A.26. · BITS

A list of the standardized transforms supported by this entity on this interface with IKEv2 protection. ⓘ

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

An indication of whether the entity is capable of supporting the IKEv2-AUTH protocol on this interface, i.e., concatenation of Authentication and SA Management Transactions, such that an SA Management Transaction is used to perform both the authentication function and SA management. ⓘ

StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. A row which is permanent(4) can be changed but not deleted. A row which is readOnly(5) cannot be changed nor deleted. If the value of an object with this syntax is either permanent(4) or readOnly(5), it cannot be written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable. · Integer32

This object specifies the memory realization of information related to FC-SP Security Associations for interface(s) to a particular Fabric; specifically, for rows created and/or modified in these tables: t11FcSpSaPropTable t11FcSpSaTSelDrByTable t11FcSpSaControlTable and, for modified information contained in the same row as an instance of this object. Even if an instance of this object has the value 'permanent(4)', none of the information defined in this MIB module for interface(s) to the given Fabric need to be writable.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This object indicates whether anti-replay protection is enabled for frame reception on this interface. Note that the replay-protection mechanism in FC-SP is conceptually similar to the corresponding mechanism in IPsec ESP. ⓘ

Unsigned32

The size of the replay window to be used when anti-replay protection is enabled for frame reception on this interface. Note that the replay-protection mechanism in FC-SP is conceptually similar to the corresponding mechanism in IPsec ESP. ⓘ

Counter32

The number of times that a dead peer condition has been detected on this interface. This counter has no discontinuities other than those that all Counter32's have when sysUpTime=0. ⓘ

INTEGER1 = noop2 = terminate · Integer32

Setting this object to 'terminate' is a request to terminate all outstanding Security Associations on this interface. When read, the value of this object is always 'noop'. Setting this object to 'noop' has no effect.

Counter64 (0..18446744073709551615)

The number of output frames that were dropped, instead of being transmitted on this interface, because they matched an active (at that time) Traffic Selector with an action of 'Drop'. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of output frames that were transmitted unchanged by FC-SP on this interface because they matched an active (at that time) Traffic Selector with an action of 'Bypass'. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of output frames that were protected by FC-SP before being transmitted on this interface because they matched an active (at that time) Traffic Selector with an action of 'Process'. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of frames that were transmitted unchanged by FC-SP on this interface because they did not match any Traffic Selector active at that time. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of frames received on this interface that were dropped because they were unprotected and did not match any Traffic Selector active at that time. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of times that a replay has been detected on a Security Association that is currently active or was previously active on this interface. Note that a frame that is discarded because it is 'behind' the window, i.e., too old, is counted as a replay. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of times that a frame received on this interface was dropped because it matched with a Traffic Selector for a Security Association that was active at the time of receipt but the frame was not protected as negotiated for that Security Association. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of times that a frame received on this interface was dropped because of a failure of one of the transforms negotiated for the Security Association on which it was received. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of frames received on this interface on a Security Association for which the transforms negotiated for that Security Association were successfully applied, and that matched a Traffic Selector for that Security Association. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of frames received on this interface that were dropped because they did not match any of the Traffic Selectors negotiated for the Security Association on which they were received, even though the Security Association's transforms were successfully applied. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Unsigned32 (1..4294967295)

An index value that uniquely identifies a particular proposal for use on one or more interfaces to a Fabric.

T11FcSpSecurityProtocolId1 = espHeader2 = ctAuthA Security Protocol identifier to identify the protocol by which traffic is to be protected, e.g., ESP_Header or CT_Authentication.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.3.2.2 and table 67. · Integer32

The Security Protocol identifier for this proposal, i.e., whether the proposal is for traffic to be protected using ESP_Header or CT_Authentication. ⓘ

Unsigned32

When the value of this object is non-zero, it points to the proposal's list of Traffic Selectors. The value must be non-zero in an active row of this table. The identified list is represented by all rows in the t11FcSpSaTSelPropTable for which t11FcSpSaTSelPropListIndex has the same value as this object (and with corresponding values of t11FcSpSaIfIndex and fcmInstanceIndex).

Unsigned32

When the value of this object is non-zero, it points to the proposal's list of Transforms. The value must be non-zero in an active row of this table. The identified list is represented by all rows in the t11FcSpSaTransTable for which t11FcSpSaTransListIndex has the same value as this object (and with corresponding values of t11FcSpSaIfIndex and fcmInstanceIndex).

INTEGER1 = intersection2 = union3 = other · Integer32

The algorithm by which an SA_Responder in an SA negotiation decides on which Traffic Selectors to specify in a response to an IKE_Create_Child_SA request. This algorithm is used when the Traffic Selectors specified by an SA_Initiator in an IKE_Create_Child_SA request overlap with this proposal's list of Traffic Selectors: intersection(1) - the SA_Responder specifies the largest subset of what the SA_Initiator proposed, which is also a subset of this proposal's Traffic Selectors. union(2) - the SA_Responder specifies the smallest superset of what the SA_Initiator proposed, which is also a superset of this proposal's Traffic Selectors. other(3) - the SA_Responder uses some other algorithm.

Counter64 (0..18446744073709551615)

The number of egress frames that have matched a Traffic Selector that was negotiated to select traffic for an SA based on this proposal being accepted. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) The status column has six defined values: - `active', which indicates that the conceptual row is available for use by the managed device; - `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated); - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management protocol retrieval operation: `notReady', `notInService' or `active'. That is, when queried, an existing conceptual row has only three states: it is either available for use by the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady'). NOTE WELL This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'. Also note that whenever any elements of a row exist, the RowStatus column must also exist. To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram: STATE +--------------+-----------+-------------+------------- | A | B | C | D | |status col.|status column| |status column | is | is |status column ACTION |does not exist| notReady | notInService| is active --------------+--------------+-----------+-------------+------------- set status |noError ->D|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndGo |inconsistent- | | | | Value| | | --------------+--------------+-----------+-------------+------------- set status |noError see 1|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndWait |wrongValue | | | --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError column to | Value| entValue| | active | | | | | | or | | | | | | | |see 2 ->D|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- set any other |see 4 |noError |noError |see 5 column to some| | | | value | | see 1| ->C| ->D --------------+--------------+-----------+-------------+------------- (1) goto B or C, depending on information available to the agent. (2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C. (4) at the discretion of the agent, the return value may be either: inconsistentName: because the agent does not choose to create such an instance when the corresponding RowStatus instance does not exist, or inconsistentValue: if the supplied value is inconsistent with the state of some other MIB object's value, or noError: because the agent chooses to create the instance. If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A. (5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc. Conceptual Row Creation There are four potential interactions when creating a conceptual row: selecting an instance-identifier which is not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device. Interaction 1: Selecting an Instance-Identifier The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics. In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.) Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different. Finally, the management station could select a pseudo-random number to use as the index. In the event that this index was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of a row. Values of object instances within an active row can be modified at any time. The status cannot be set to 'active' unless and until the instances of t11FcSpSaPropTSelListIndex and t11FcSpSaPropTransListIndex in the row have been set to point to active rows in the t11FcSpSaTSelPropTable and t11FcSpSaTransTable tables, respectively. A row in this table is deleted if the active rows it points to are deleted.

Unsigned32 (1..4294967295)

An index value that identifies a particular list of Traffic Selectors.

T11FcSpPrecedenceThe precedence of a Traffic Selector. If a frame matches with two or more Traffic Selectors, then the match that takes precedence is the one with the Traffic Selector having the numerically smallest precedence value. Note that precedence values are not necessarily contiguous. · Unsigned32 · hint d

The precedence of this Traffic Selector. Each Traffic Selector within a particular list of Traffic Selectors must have a different precedence. If an egress frame matches multiple Traffic Selectors, it should be transmitted on the SA associated with the Traffic Selector having the numerically smallest precedence value.

T11FcSaDirection1 = ingress2 = egressThe direction of frame transmission on a Security Association. Note that Security Associations are unidirectional, but they always exist as part of an SA pair of the same type in opposite directions. · Integer32

An indication of whether this Traffic Selector is to be proposed for ingress or egress traffic.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically smallest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector. ⓘ

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically largest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector. ⓘ

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically smallest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector. ⓘ

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically largest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector. ⓘ

T11FcRoutingControlA value stored in the R_CTL (Routing Control) 8-bit field of an FC-2 frame containing routing and information bits to categorize the frame function. For FC-2 frames, an R_CTL value typically distinguishes between control versus data frames and/or solicited versus unsolicited frames, and in combination with the TYPE field (see T11FcSpType), identifies a particular link-layer service/protocol using FC-2. For CT_Authentication, the information field in the R_CTL field contains '02'h for Request CT_IUs and '03'h for Response CT_IUs. The comparison of two values having this syntax is done by treating each string as an 8-bit numeric value.Reference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.3. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.5.2.4.2, 4.5.2.4.3 and table 12. SIZE (1) · OCTET STRING · hint 1x

The numerically smallest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector. ⓘ

T11FcRoutingControlA value stored in the R_CTL (Routing Control) 8-bit field of an FC-2 frame containing routing and information bits to categorize the frame function. For FC-2 frames, an R_CTL value typically distinguishes between control versus data frames and/or solicited versus unsolicited frames, and in combination with the TYPE field (see T11FcSpType), identifies a particular link-layer service/protocol using FC-2. For CT_Authentication, the information field in the R_CTL field contains '02'h for Request CT_IUs and '03'h for Response CT_IUs. The comparison of two values having this syntax is done by treating each string as an 8-bit numeric value.Reference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.3. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.5.2.4.2, 4.5.2.4.3 and table 12. SIZE (1) · OCTET STRING · hint 1x

The numerically largest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector. ⓘ

T11FcSpTypeA value, or combination of values, contained in a frame header used in identifying the link layer service/protocol of a frame. The value is always two octets: - for FC-2 frames, the first octet is zero and the second octet contains the Data structure type (TYPE) value defined by FC-FS-2. The TYPE value is used in combination with T11FcRoutingControl to identify a link layer service/protocol. - for Common Transport Information Units (CT_IUs), the first octet contains a GS_Type value and the second octet contains a GS_Subtype value, defined by FC-GS-5. The comparison of two values having this syntax is done by treating each string as the numeric value obtained by numerically combining the individual octet's value as follows: (256 * 1st-octet) + 2nd-octetReference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.6. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.3.2.4 and 4.3.2.5. SIZE (2) · OCTET STRING · hint 2x

The numerically smallest of a range of possible 'type' values of frames that will match with this Traffic Selector. ⓘ

T11FcSpTypeA value, or combination of values, contained in a frame header used in identifying the link layer service/protocol of a frame. The value is always two octets: - for FC-2 frames, the first octet is zero and the second octet contains the Data structure type (TYPE) value defined by FC-FS-2. The TYPE value is used in combination with T11FcRoutingControl to identify a link layer service/protocol. - for Common Transport Information Units (CT_IUs), the first octet contains a GS_Type value and the second octet contains a GS_Subtype value, defined by FC-GS-5. The comparison of two values having this syntax is done by treating each string as the numeric value obtained by numerically combining the individual octet's value as follows: (256 * 1st-octet) + 2nd-octetReference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.6. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.3.2.4 and 4.3.2.5. SIZE (2) · OCTET STRING · hint 2x

The numerically largest of a range of possible 'type' values of frames that will match with this Traffic Selector. ⓘ

StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. A row which is permanent(4) can be changed but not deleted. A row which is readOnly(5) cannot be changed nor deleted. If the value of an object with this syntax is either permanent(4) or readOnly(5), it cannot be written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable. · Integer32

This object specifies the memory realization of the information in this row. Even if an instance of this object has the value 'permanent(4)', none of the information in its row needs to be writable.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) The status column has six defined values: - `active', which indicates that the conceptual row is available for use by the managed device; - `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated); - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management protocol retrieval operation: `notReady', `notInService' or `active'. That is, when queried, an existing conceptual row has only three states: it is either available for use by the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady'). NOTE WELL This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'. Also note that whenever any elements of a row exist, the RowStatus column must also exist. To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram: STATE +--------------+-----------+-------------+------------- | A | B | C | D | |status col.|status column| |status column | is | is |status column ACTION |does not exist| notReady | notInService| is active --------------+--------------+-----------+-------------+------------- set status |noError ->D|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndGo |inconsistent- | | | | Value| | | --------------+--------------+-----------+-------------+------------- set status |noError see 1|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndWait |wrongValue | | | --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError column to | Value| entValue| | active | | | | | | or | | | | | | | |see 2 ->D|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- set any other |see 4 |noError |noError |see 5 column to some| | | | value | | see 1| ->C| ->D --------------+--------------+-----------+-------------+------------- (1) goto B or C, depending on information available to the agent. (2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C. (4) at the discretion of the agent, the return value may be either: inconsistentName: because the agent does not choose to create such an instance when the corresponding RowStatus instance does not exist, or inconsistentValue: if the supplied value is inconsistent with the state of some other MIB object's value, or noError: because the agent chooses to create the instance. If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A. (5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc. Conceptual Row Creation There are four potential interactions when creating a conceptual row: selecting an instance-identifier which is not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device. Interaction 1: Selecting an Instance-Identifier The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics. In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.) Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different. Finally, the management station could select a pseudo-random number to use as the index. In the event that this index was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this row. Values of object instances within the row can be modified at any time.

Unsigned32 (1..4294967295)

An index value that uniquely identifies a particular list of security transforms to be proposed, to be accepted, or already agreed upon.

Unsigned32 (1..4294967295)

An index value that uniquely identifies one security transform within a list identified by t11FcSpSaTransListIndex.

T11FcSpSecurityProtocolId1 = espHeader2 = ctAuthA Security Protocol identifier to identify the protocol by which traffic is to be protected, e.g., ESP_Header or CT_Authentication.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.3.2.2 and table 67. · Integer32

The Security Protocol identifier that indicates whether this transform is for traffic to be protected using ESP_Header or using CT_Authentication. ⓘ

AutonomousTypeRepresents an independently extensible type identification value. It may, for example, indicate a particular sub-tree with further MIB definitions, or define a particular type of protocol or hardware. · OBJECT IDENTIFIER

The Encryption Algorithm for this transform. ⓘ

Unsigned32

The key length in bits to be used with an encryption algorithm that has a variable length key. This object is ignored when the corresponding instance of t11FcSpSaTransEncryptAlg specifies an algorithm with a fixed length key. ⓘ

AutonomousTypeRepresents an independently extensible type identification value. It may, for example, indicate a particular sub-tree with further MIB definitions, or define a particular type of protocol or hardware. · OBJECT IDENTIFIER

The Integrity Algorithm for this transform. ⓘ

StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. A row which is permanent(4) can be changed but not deleted. A row which is readOnly(5) cannot be changed nor deleted. If the value of an object with this syntax is either permanent(4) or readOnly(5), it cannot be written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.) Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable. · Integer32

This object specifies the memory realization of the information in this row. Even if an instance of this object has the value 'permanent(4)', none of the information in its row needs to be writable.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) The status column has six defined values: - `active', which indicates that the conceptual row is available for use by the managed device; - `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated); - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management protocol retrieval operation: `notReady', `notInService' or `active'. That is, when queried, an existing conceptual row has only three states: it is either available for use by the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady'). NOTE WELL This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'. Also note that whenever any elements of a row exist, the RowStatus column must also exist. To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram: STATE +--------------+-----------+-------------+------------- | A | B | C | D | |status col.|status column| |status column | is | is |status column ACTION |does not exist| notReady | notInService| is active --------------+--------------+-----------+-------------+------------- set status |noError ->D|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndGo |inconsistent- | | | | Value| | | --------------+--------------+-----------+-------------+------------- set status |noError see 1|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndWait |wrongValue | | | --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError column to | Value| entValue| | active | | | | | | or | | | | | | | |see 2 ->D|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- set any other |see 4 |noError |noError |see 5 column to some| | | | value | | see 1| ->C| ->D --------------+--------------+-----------+-------------+------------- (1) goto B or C, depending on information available to the agent. (2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C. (4) at the discretion of the agent, the return value may be either: inconsistentName: because the agent does not choose to create such an instance when the corresponding RowStatus instance does not exist, or inconsistentValue: if the supplied value is inconsistent with the state of some other MIB object's value, or noError: because the agent chooses to create the instance. If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A. (5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc. Conceptual Row Creation There are four potential interactions when creating a conceptual row: selecting an instance-identifier which is not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device. Interaction 1: Selecting an Instance-Identifier The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics. In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.) Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different. Finally, the management station could select a pseudo-random number to use as the index. In the event that this index was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this row. When an instance of t11FcSpSaPairTransListIndex points to a row in this table, values of object instances in the row cannot be modified nor can the row be deleted. Otherwise, a row can be modified or deleted at any time.

T11FcSaDirection1 = ingress2 = egressThe direction of frame transmission on a Security Association. Note that Security Associations are unidirectional, but they always exist as part of an SA pair of the same type in opposite directions. · Integer32

An indication of whether this Traffic Selector is for ingress or egress traffic.

T11FcSpPrecedenceThe precedence of a Traffic Selector. If a frame matches with two or more Traffic Selectors, then the match that takes precedence is the one with the Traffic Selector having the numerically smallest precedence value. Note that precedence values are not necessarily contiguous. · Unsigned32 · hint d

The precedence of this Traffic Selector. If and when a frame is compared against multiple Traffic Selectors, and multiple of them have a match with the frame, the security action to be taken for the frame is that specified for the matching Traffic Selector having the numerically smallest precedence value.

INTEGER1 = drop2 = bypass · Integer32

The security action to be taken for a frame that matches this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically smallest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically largest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically smallest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically largest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector.

T11FcRoutingControlA value stored in the R_CTL (Routing Control) 8-bit field of an FC-2 frame containing routing and information bits to categorize the frame function. For FC-2 frames, an R_CTL value typically distinguishes between control versus data frames and/or solicited versus unsolicited frames, and in combination with the TYPE field (see T11FcSpType), identifies a particular link-layer service/protocol using FC-2. For CT_Authentication, the information field in the R_CTL field contains '02'h for Request CT_IUs and '03'h for Response CT_IUs. The comparison of two values having this syntax is done by treating each string as an 8-bit numeric value.Reference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.3. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.5.2.4.2, 4.5.2.4.3 and table 12. SIZE (1) · OCTET STRING · hint 1x

The numerically smallest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector.

T11FcRoutingControlA value stored in the R_CTL (Routing Control) 8-bit field of an FC-2 frame containing routing and information bits to categorize the frame function. For FC-2 frames, an R_CTL value typically distinguishes between control versus data frames and/or solicited versus unsolicited frames, and in combination with the TYPE field (see T11FcSpType), identifies a particular link-layer service/protocol using FC-2. For CT_Authentication, the information field in the R_CTL field contains '02'h for Request CT_IUs and '03'h for Response CT_IUs. The comparison of two values having this syntax is done by treating each string as an 8-bit numeric value.Reference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.3. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.5.2.4.2, 4.5.2.4.3 and table 12. SIZE (1) · OCTET STRING · hint 1x

The numerically largest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector.

T11FcSpTypeA value, or combination of values, contained in a frame header used in identifying the link layer service/protocol of a frame. The value is always two octets: - for FC-2 frames, the first octet is zero and the second octet contains the Data structure type (TYPE) value defined by FC-FS-2. The TYPE value is used in combination with T11FcRoutingControl to identify a link layer service/protocol. - for Common Transport Information Units (CT_IUs), the first octet contains a GS_Type value and the second octet contains a GS_Subtype value, defined by FC-GS-5. The comparison of two values having this syntax is done by treating each string as the numeric value obtained by numerically combining the individual octet's value as follows: (256 * 1st-octet) + 2nd-octetReference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.6. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.3.2.4 and 4.3.2.5. SIZE (2) · OCTET STRING · hint 2x

The numerically smallest of a range of possible 'type' values of frames that will match with this Traffic Selector.

T11FcSpTypeA value, or combination of values, contained in a frame header used in identifying the link layer service/protocol of a frame. The value is always two octets: - for FC-2 frames, the first octet is zero and the second octet contains the Data structure type (TYPE) value defined by FC-FS-2. The TYPE value is used in combination with T11FcRoutingControl to identify a link layer service/protocol. - for Common Transport Information Units (CT_IUs), the first octet contains a GS_Type value and the second octet contains a GS_Subtype value, defined by FC-GS-5. The comparison of two values having this syntax is done by treating each string as the numeric value obtained by numerically combining the individual octet's value as follows: (256 * 1st-octet) + 2nd-octetReference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.6. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.3.2.4 and 4.3.2.5. SIZE (2) · OCTET STRING · hint 2x

The numerically largest of a range of possible 'type' values of frames that will match with this Traffic Selector.

Counter64 (0..18446744073709551615)

The number of frames for which the action specified by the corresponding instance of t11FcSpSaTSelDrByAction was taken because of a match with this Traffic Selector. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) The status column has six defined values: - `active', which indicates that the conceptual row is available for use by the managed device; - `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated); - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management protocol retrieval operation: `notReady', `notInService' or `active'. That is, when queried, an existing conceptual row has only three states: it is either available for use by the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady'). NOTE WELL This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'. Also note that whenever any elements of a row exist, the RowStatus column must also exist. To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram: STATE +--------------+-----------+-------------+------------- | A | B | C | D | |status col.|status column| |status column | is | is |status column ACTION |does not exist| notReady | notInService| is active --------------+--------------+-----------+-------------+------------- set status |noError ->D|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndGo |inconsistent- | | | | Value| | | --------------+--------------+-----------+-------------+------------- set status |noError see 1|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndWait |wrongValue | | | --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError column to | Value| entValue| | active | | | | | | or | | | | | | | |see 2 ->D|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- set any other |see 4 |noError |noError |see 5 column to some| | | | value | | see 1| ->C| ->D --------------+--------------+-----------+-------------+------------- (1) goto B or C, depending on information available to the agent. (2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C. (4) at the discretion of the agent, the return value may be either: inconsistentName: because the agent does not choose to create such an instance when the corresponding RowStatus instance does not exist, or inconsistentValue: if the supplied value is inconsistent with the state of some other MIB object's value, or noError: because the agent chooses to create the instance. If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A. (5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc. Conceptual Row Creation There are four potential interactions when creating a conceptual row: selecting an instance-identifier which is not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device. Interaction 1: Selecting an Instance-Identifier The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics. In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.) Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different. Finally, the management station could select a pseudo-random number to use as the index. In the event that this index was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed. · Integer32

The status of this row. Values of object instances within the row can be modified at any time.

InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d

This object identifies the interface to the particular Fabric on which this SA pair is active.

T11FcSpiIndexAn SPI (Security Parameter Index) value is carried in the SPI field of a frame protected by the ESP_Header. An SPI is also carried in the SAID field of a Common Transport Information Unit (CT_IU) protected by CT_Authentication. An SPI value identifies the Security Association on which the frame is being transmitted.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 4.7.2 and 4.7.3. · Unsigned32

The SPI value that is used to indicate that an incoming frame was received on the ingress SA of this SA pair.

T11FcSpSecurityProtocolId1 = espHeader2 = ctAuthA Security Protocol identifier to identify the protocol by which traffic is to be protected, e.g., ESP_Header or CT_Authentication.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 6.3.2.2 and table 67. · Integer32

The object indicates whether this SA uses ESP_Header to protect FC-2 frames, or CT_Authentication to protect Common Transport Information Units (CT_IUs).

Unsigned32 (1..4294967295)

The combination of this value and the value of the corresponding instance of t11FcSpSaPairTransIndex identify the row in the t11FcSpSaTransTable that contains the transforms that are in use on this SA pair.

Unsigned32 (1..4294967295)

The combination of this value and the value of the corresponding instance of t11FcSpSaPairTransListIndex identify the row in the t11FcSpSaTransTable that contains the transforms that are in use on this SA pair.

T11FcSpLifetimeLeftThis TC is used for one object of an associated pair of objects. The object with this syntax specifies a remaining lifetime of something, e.g., of an SA, where the lifetime is given in the units specified by the other object of the pair which has T11FcSpLifetimeLeftUnits as its syntax. · Unsigned32

The remaining lifetime of this SA pair, given in the units specified by the value of the corresponding instance of t11FcSpSaPairLifetimeLeft.

T11FcSpLifetimeLeftUnits1 = seconds2 = kiloBytes3 = megaBytes4 = gigaBytes5 = teraBytes6 = petaBytes7 = exaBytes8 = zettaBytes9 = yottaBytesAn object, defined using T11FcSpLifetimeLeft TC as its syntax, is required to be one of an associated pair of objects such that the other object of the pair is defined with this T11FcSpLifetimeLeftUnits TC as its syntax and with its value specifying the units of the remaining lifetime given by the value of the T11FcSpLifetimeLeft object. · Integer32

The units in which the value of the corresponding instance of t11FcSpSaPairLifetimeLeft specifies the remaining lifetime of this SA pair.

INTEGER1 = noop2 = terminate · Integer32

Setting this object to 'terminate' is a request to terminate this pair of Security Associations. When read, the value of this object is always 'noop'. Setting this object to 'noop' has no effect.

Counter64 (0..18446744073709551615)

The number of frames received on this SA for which the SA's transforms were successfully applied to the frame, but the frame was still dropped because it did not match any of the SA's ingress Traffic Selectors. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of times that a replay has been detected on this Security Association. Note that a frame that is discarded because it is 'behind' the window, i.e., too old, is counted as a replay. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of times that a received frame was dropped because one of the transforms negotiated for this Security Association failed. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Counter64 (0..18446744073709551615)

The number of received frames for which the transforms negotiated for this Security Association, were successfully applied. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

Unsigned32 (1..4294967295)

An index value to distinguish an ingress Traffic Selector from all others currently in use by Security Associations on the same interface to a particular Fabric.

T11FcSpiIndexAn SPI (Security Parameter Index) value is carried in the SPI field of a frame protected by the ESP_Header. An SPI is also carried in the SAID field of a Common Transport Information Unit (CT_IU) protected by CT_Authentication. An SPI value identifies the Security Association on which the frame is being transmitted.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 4.7.2 and 4.7.3. · Unsigned32

The SPI of the ingress SA on which this Traffic Selector is in use. This value can be used to find the SA pair's row in the t11FcSpSaPairTable.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically smallest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically largest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically smallest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically largest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector.

T11FcRoutingControlA value stored in the R_CTL (Routing Control) 8-bit field of an FC-2 frame containing routing and information bits to categorize the frame function. For FC-2 frames, an R_CTL value typically distinguishes between control versus data frames and/or solicited versus unsolicited frames, and in combination with the TYPE field (see T11FcSpType), identifies a particular link-layer service/protocol using FC-2. For CT_Authentication, the information field in the R_CTL field contains '02'h for Request CT_IUs and '03'h for Response CT_IUs. The comparison of two values having this syntax is done by treating each string as an 8-bit numeric value.Reference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.3. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.5.2.4.2, 4.5.2.4.3 and table 12. SIZE (1) · OCTET STRING · hint 1x

The numerically smallest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector.

T11FcRoutingControlA value stored in the R_CTL (Routing Control) 8-bit field of an FC-2 frame containing routing and information bits to categorize the frame function. For FC-2 frames, an R_CTL value typically distinguishes between control versus data frames and/or solicited versus unsolicited frames, and in combination with the TYPE field (see T11FcSpType), identifies a particular link-layer service/protocol using FC-2. For CT_Authentication, the information field in the R_CTL field contains '02'h for Request CT_IUs and '03'h for Response CT_IUs. The comparison of two values having this syntax is done by treating each string as an 8-bit numeric value.Reference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.3. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.5.2.4.2, 4.5.2.4.3 and table 12. SIZE (1) · OCTET STRING · hint 1x

The numerically largest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector.

T11FcSpTypeA value, or combination of values, contained in a frame header used in identifying the link layer service/protocol of a frame. The value is always two octets: - for FC-2 frames, the first octet is zero and the second octet contains the Data structure type (TYPE) value defined by FC-FS-2. The TYPE value is used in combination with T11FcRoutingControl to identify a link layer service/protocol. - for Common Transport Information Units (CT_IUs), the first octet contains a GS_Type value and the second octet contains a GS_Subtype value, defined by FC-GS-5. The comparison of two values having this syntax is done by treating each string as the numeric value obtained by numerically combining the individual octet's value as follows: (256 * 1st-octet) + 2nd-octetReference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.6. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.3.2.4 and 4.3.2.5. SIZE (2) · OCTET STRING · hint 2x

The numerically smallest of a range of possible 'type' values of frames that will match with this Traffic Selector.

T11FcSpTypeA value, or combination of values, contained in a frame header used in identifying the link layer service/protocol of a frame. The value is always two octets: - for FC-2 frames, the first octet is zero and the second octet contains the Data structure type (TYPE) value defined by FC-FS-2. The TYPE value is used in combination with T11FcRoutingControl to identify a link layer service/protocol. - for Common Transport Information Units (CT_IUs), the first octet contains a GS_Type value and the second octet contains a GS_Subtype value, defined by FC-GS-5. The comparison of two values having this syntax is done by treating each string as the numeric value obtained by numerically combining the individual octet's value as follows: (256 * 1st-octet) + 2nd-octetReference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.6. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.3.2.4 and 4.3.2.5. SIZE (2) · OCTET STRING · hint 2x

The numerically largest of a range of possible 'type' values of frames that will match with this Traffic Selector.

Counter64 (0..18446744073709551615)

The number of times that a received frame was dropped because it matched with this Traffic Selector but the frame was not protected as negotiated for the Security Association identified by t11FcSpSaTSelNegInInboundSpi. This counter has no discontinuities other than those that all Counter64's have when sysUpTime=0.

T11FcSpPrecedenceThe precedence of a Traffic Selector. If a frame matches with two or more Traffic Selectors, then the match that takes precedence is the one with the Traffic Selector having the numerically smallest precedence value. Note that precedence values are not necessarily contiguous. · Unsigned32 · hint d

The precedence of this Traffic Selector. If and when a frame is compared against multiple Traffic Selectors, and multiple of them have a match with the frame, the security action to be taken for the frame is that specified for the matching Traffic Selector having the numerically smallest precedence value.

T11FcSpiIndexAn SPI (Security Parameter Index) value is carried in the SPI field of a frame protected by the ESP_Header. An SPI is also carried in the SAID field of a Common Transport Information Unit (CT_IU) protected by CT_Authentication. An SPI value identifies the Security Association on which the frame is being transmitted.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 4.7.2 and 4.7.3. · Unsigned32

The SPI of the ingress SA of the SA pair for which this Traffic Selector is in use on the egress SA. This value can be used to find the SA pair's row in the t11FcSpSaPairTable.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically smallest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically largest 24-bit value of a source address (S_ID) of a frame that will match with this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically smallest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (3) · OCTET STRING

The numerically largest 24-bit value of a destination address (D_ID) of a frame that will match with this Traffic Selector.

T11FcRoutingControlA value stored in the R_CTL (Routing Control) 8-bit field of an FC-2 frame containing routing and information bits to categorize the frame function. For FC-2 frames, an R_CTL value typically distinguishes between control versus data frames and/or solicited versus unsolicited frames, and in combination with the TYPE field (see T11FcSpType), identifies a particular link-layer service/protocol using FC-2. For CT_Authentication, the information field in the R_CTL field contains '02'h for Request CT_IUs and '03'h for Response CT_IUs. The comparison of two values having this syntax is done by treating each string as an 8-bit numeric value.Reference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.3. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.5.2.4.2, 4.5.2.4.3 and table 12. SIZE (1) · OCTET STRING · hint 1x

The numerically smallest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector.

T11FcRoutingControlA value stored in the R_CTL (Routing Control) 8-bit field of an FC-2 frame containing routing and information bits to categorize the frame function. For FC-2 frames, an R_CTL value typically distinguishes between control versus data frames and/or solicited versus unsolicited frames, and in combination with the TYPE field (see T11FcSpType), identifies a particular link-layer service/protocol using FC-2. For CT_Authentication, the information field in the R_CTL field contains '02'h for Request CT_IUs and '03'h for Response CT_IUs. The comparison of two values having this syntax is done by treating each string as an 8-bit numeric value.Reference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.3. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.5.2.4.2, 4.5.2.4.3 and table 12. SIZE (1) · OCTET STRING · hint 1x

The numerically largest 8-bit value contained within a Routing Control (R_CTL) field of a frame that will match with this Traffic Selector.

T11FcSpTypeA value, or combination of values, contained in a frame header used in identifying the link layer service/protocol of a frame. The value is always two octets: - for FC-2 frames, the first octet is zero and the second octet contains the Data structure type (TYPE) value defined by FC-FS-2. The TYPE value is used in combination with T11FcRoutingControl to identify a link layer service/protocol. - for Common Transport Information Units (CT_IUs), the first octet contains a GS_Type value and the second octet contains a GS_Subtype value, defined by FC-GS-5. The comparison of two values having this syntax is done by treating each string as the numeric value obtained by numerically combining the individual octet's value as follows: (256 * 1st-octet) + 2nd-octetReference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.6. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.3.2.4 and 4.3.2.5. SIZE (2) · OCTET STRING · hint 2x

The numerically smallest of a range of possible 'type' values of frames that will match with this Traffic Selector.

T11FcSpTypeA value, or combination of values, contained in a frame header used in identifying the link layer service/protocol of a frame. The value is always two octets: - for FC-2 frames, the first octet is zero and the second octet contains the Data structure type (TYPE) value defined by FC-FS-2. The TYPE value is used in combination with T11FcRoutingControl to identify a link layer service/protocol. - for Common Transport Information Units (CT_IUs), the first octet contains a GS_Type value and the second octet contains a GS_Subtype value, defined by FC-GS-5. The comparison of two values having this syntax is done by treating each string as the numeric value obtained by numerically combining the individual octet's value as follows: (256 * 1st-octet) + 2nd-octetReference: - Fibre Channel - Framing and Signaling-2 (FC-FS-2), ANSI INCITS 424-2007, Project T11/1619-D, February 2007, section 9.6. - Fibre Channel - Generic Services-5 (FC-GS-5), ANSI INCITS 427-2006, sections 4.3.2.4 and 4.3.2.5. SIZE (2) · OCTET STRING · hint 2x

The numerically largest of a range of possible 'type' values of frames that will match with this Traffic Selector.

T11FcSpiIndexAn SPI (Security Parameter Index) value is carried in the SPI field of a frame protected by the ESP_Header. An SPI is also carried in the SAID field of a Common Transport Information Unit (CT_IU) protected by CT_Authentication. An SPI value identifies the Security Association on which the frame is being transmitted.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 4.7.2 and 4.7.3. · Unsigned32

An SPI value that identifies the ingress Security Association of a particular SA pair.

Unsigned32 (1..4294967295)

An index value that distinguishes between the (potentially multiple) Traffic Selectors in use on this Security Association pair.

T11FcSaDirection1 = ingress2 = egressThe direction of frame transmission on a Security Association. Note that Security Associations are unidirectional, but they always exist as part of an SA pair of the same type in opposite directions. · Integer32

This object indicates whether this Traffic Selector is being used for ingress or for egress traffic.

Unsigned32

This object contains a pointer into another table that can be used to obtain more information about this Traffic Selector. If the corresponding instance of t11FcSpSaTSelSpiDirection has the value 'egress', then this object contains the value of t11FcSpSaTSelNegOutPrecedence in the row of t11FcSpSaTSelNegOutTable, which contains more information. If the corresponding instance of t11FcSpSaTSelSpiDirection has the value 'ingress', then this object contains the value of t11FcSpSaTSelNegInIndex that identifies the row in t11FcSpSaTSelNegInTable containing more information.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This object specifies whether a t11FcSpSaNotifyAuthFailure notification should be generated for the first occurrence of an Authentication failure within a time window for this Fabric.

T11FcSpiIndexAn SPI (Security Parameter Index) value is carried in the SPI field of a frame protected by the ESP_Header. An SPI is also carried in the SAID field of a Common Transport Information Unit (CT_IU) protected by CT_Authentication. An SPI value identifies the Security Association on which the frame is being transmitted.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 4.7.2 and 4.7.3. · Unsigned32

The SPI value of the ingress Security Association on which was received the last frame for which a t11FcSpSaNotifyAuthFailure was generated. If no t11FcSpSaNotifyAuthFailure notifications have been generated, the value of this object is zero.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (0 | 3) · OCTET STRING

The S_ID contained in the last frame for which a t11FcSpSaNotifyAuthFailure was generated. If no t11FcSpSaNotifyAuthFailure notifications have been generated, the value of this object is the zero-length string.

FcAddressIdOrZeroA Fibre Channel Address ID, a 24-bit value unique within the address space of a Fabric. The zero-length string value is used in circumstances in which the WWN is unassigned/unknown. SIZE (0 | 3) · OCTET STRING

The D_ID contained in the last frame for which a t11FcSpSaNotifyAuthFailure was generated. If no t11FcSpSaNotifyAuthFailure notifications have been generated, the value of this object is the zero-length string.

OCTET STRING SIZE (0..256)

The binary content of the last frame for which a t11FcSpSaNotifyAuthFailure was generated. If more than 256 bytes of the frame are available, then this object contains the first 256 bytes. If less than 256 bytes of the frame are available, then this object contains the first N bytes, where N is greater or equal to zero. If no t11FcSpSaNotifyAuthFailure notifications have been generated, the value of this object is the zero-length string.

TimeTicks

The elapsed time since the last generation of a t11FcSpSaNotifyAuthFailure notification on the same Fabric, or the value of sysUpTime if no t11FcSpSaNotifyAuthFailure notifications have been generated since the last restart.

Gauge32

The number of occurrences of an Authentication failure on a Fabric that were suppressed because they occurred on the same Fabric within the same time window as a previous Authentication failure for which a t11FcSpSaNotifyAuthFailure notification was generated. The value of this object is reset to zero on a restart of the network management subsystem, and whenever a t11FcSpSaNotifyAuthFailure notification is generated. In the event that the value of this object reaches its maximum value, it remains at that value until it is reset on the generation of the next t11FcSpSaNotifyAuthFailure notification.

Unsigned32 (1..4294967295) · seconds

The length of a time window that begins when a t11FcSpSaNotifyAuthFailure notification is generated for any Security Association on a particular Fabric. For the duration of the time window, further Authentication failures occurring for the same Security Association are counted but no t11FcSpSaNotifyAuthFailure notification is generated. When this object is modified before the end of a time window, that time window is immediately terminated, i.e., the next Authentication failure on the relevant Fabric after the modification will cause a new time window to begin with the new length.

Unsigned32

The maximum number of t11FcSpSaNotifyAuthFailure notifications to be generated per Fabric within a t11FcSpSaControlWindow time window. Subsequent Authentication failures occurring on the same Fabric in the same time window are counted, but no t11FcSpSaNotifyAuthFailure notification is generated. When this object is modified before the end of a time window, that time window is immediately terminated, i.e., the next Authentication failure on the relevant Fabric after the modification will cause a new time window to begin with the new length.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This object specifies whether t11FcSpSaNotifyLifeExceeded notifications should be generated for this Fabric.

T11FcSpiIndexAn SPI (Security Parameter Index) value is carried in the SPI field of a frame protected by the ESP_Header. An SPI is also carried in the SAID field of a Common Transport Information Unit (CT_IU) protected by CT_Authentication. An SPI value identifies the Security Association on which the frame is being transmitted.Reference: - ANSI INCITS 426-2007, T11/Project 1570-D, Fibre Channel - Security Protocols (FC-SP), February 2007, section 4.7.2 and 4.7.3. · Unsigned32

The SPI of the SA that was most recently terminated because its lifetime (in seconds or in passed bytes) was exceeded. Such terminations include those due to a failed attempt to renew an SA after its lifetime was exceeded.

T11FcSaDirection1 = ingress2 = egressThe direction of frame transmission on a Security Association. Note that Security Associations are unidirectional, but they always exist as part of an SA pair of the same type in opposite directions. · Integer32

The direction of frame transmission on the SA that was most recently terminated because its lifetime (in seconds or in passed bytes) was exceeded.

TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The time of the most recent termination of an SA due to its lifetime (in seconds or in passed bytes) being exceeded. Such terminations include those due to a failed attempt to renew an SA after its lifetime was exceeded.