sctpCurrEstab
1.3.6.1.2.1.104.1.1.1
Gauge32
The number of associations for which the current state is either ESTABLISHED, SHUTDOWN-RECEIVED or SHUTDOWN-PENDING. Reference: Section 4 in RFC2960 covers the SCTP Association state diagram.
2004-09-02
Download SCTP-MIB.txt Open SCTP-MIB.txt in a new tab
The MIB module for managing SCTP implementations. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC 3873; see the RFC itself for full legal notices.
END OF TOC
1.3.6.1.2.1.104.1.1.1
Gauge32
The number of associations for which the current state is either ESTABLISHED, SHUTDOWN-RECEIVED or SHUTDOWN-PENDING. Reference: Section 4 in RFC2960 covers the SCTP Association state diagram.
1.3.6.1.2.1.104.1.1.2
Counter32
The number of times that associations have made a direct transition to the ESTABLISHED state from the COOKIE-ECHOED state: COOKIE-ECHOED -> ESTABLISHED. The upper layer initiated the association attempt. Reference: Section 4 in RFC2960 covers the SCTP Association state diagram.
1.3.6.1.2.1.104.1.1.3
Counter32
The number of times that associations have made a direct transition to the ESTABLISHED state from the CLOSED state: CLOSED -> ESTABLISHED. The remote endpoint initiated the association attempt. Reference: Section 4 in RFC2960 covers the SCTP Association state diagram.
1.3.6.1.2.1.104.1.1.4
Counter32
The number of times that associations have made a direct transition to the CLOSED state from any state using the primitive 'ABORT': AnyState --Abort--> CLOSED. Ungraceful termination of the association. Reference: Section 4 in RFC2960 covers the SCTP Association state diagram.
1.3.6.1.2.1.104.1.1.5
Counter32
The number of times that associations have made a direct transition to the CLOSED state from either the SHUTDOWN-SENT state or the SHUTDOWN-ACK-SENT state. Graceful termination of the association. Reference: Section 4 in RFC2960 covers the SCTP Association state diagram.
1.3.6.1.2.1.104.1.1.6
Counter32
The number of out of the blue packets received by the host. An out of the blue packet is an SCTP packet correctly formed, including the proper checksum, but for which the receiver was unable to identify an appropriate association. Reference: Section 8.4 in RFC2960 deals with the Out-Of-The-Blue (OOTB) packet definition and procedures.
1.3.6.1.2.1.104.1.1.7
Counter32
The number of SCTP packets received with an invalid checksum. Reference: The checksum is located at the end of the SCTP packet as per Section 3.1 in RFC2960. RFC3309 updates SCTP to use a 32 bit CRC checksum.
1.3.6.1.2.1.104.1.1.8
Counter64 (0..18446744073709551615)
The number of SCTP control chunks sent (retransmissions are not included). Control chunks are those chunks different from DATA. Reference: Sections 1.3.5 and 1.4 in RFC2960 refer to control chunk as those chunks different from those that contain user information, i.e., DATA chunks.
1.3.6.1.2.1.104.1.1.9
Counter64 (0..18446744073709551615)
The number of SCTP ordered data chunks sent (retransmissions are not included). Reference: Section 3.3.1 in RFC2960 defines the ordered data chunk.
1.3.6.1.2.1.104.1.1.10
Counter64 (0..18446744073709551615)
The number of SCTP unordered chunks (data chunks in which the U bit is set to 1) sent (retransmissions are not included). Reference: Section 3.3.1 in RFC2960 defines the unordered data chunk.
1.3.6.1.2.1.104.1.1.11
Counter64 (0..18446744073709551615)
The number of SCTP control chunks received (no duplicate chunks included). Reference: Sections 1.3.5 and 1.4 in RFC2960 refer to control chunk as those chunks different from those that contain user information, i.e., DATA chunks.
1.3.6.1.2.1.104.1.1.12
Counter64 (0..18446744073709551615)
The number of SCTP ordered data chunks received (no duplicate chunks included). Reference: Section 3.3.1 in RFC2960 defines the ordered data chunk.
1.3.6.1.2.1.104.1.1.13
Counter64 (0..18446744073709551615)
The number of SCTP unordered chunks (data chunks in which the U bit is set to 1) received (no duplicate chunks included). Reference: Section 3.3.1 in RFC2960 defines the unordered data chunk.
1.3.6.1.2.1.104.1.1.14
Counter64 (0..18446744073709551615)
The number of user messages that have to be fragmented because of the MTU.
1.3.6.1.2.1.104.1.1.15
Counter64 (0..18446744073709551615)
The number of user messages reassembled, after conversion into DATA chunks. Reference: Section 6.9 in RFC2960 includes a description of the reassembly process.
1.3.6.1.2.1.104.1.1.16
Counter64 (0..18446744073709551615)
The number of SCTP packets sent. Retransmitted DATA chunks are included.
1.3.6.1.2.1.104.1.1.17
Counter64 (0..18446744073709551615)
The number of SCTP packets received. Duplicates are included.
1.3.6.1.2.1.104.1.1.18
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 value of sysUpTime on the most recent occasion at which any one or more of this general statistics counters suffered a discontinuity. The relevant counters are the specific instances associated with this interface of any Counter32 or Counter64 object contained in the SCTP layer statistics (defined below sctpStats branch). If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value. Reference: The inclusion of this object is recommended by RFC2578.
1.3.6.1.2.1.104.1.2.1
INTEGER1 = other2 = vanj · Integer32
The algorithm used to determine the timeout value (T3-rtx) used for re-transmitting unacknowledged chunks. Reference: Section 6.3.1 and 6.3.2 in RFC2960 cover the RTO calculation and retransmission timer rules.
1.3.6.1.2.1.104.1.2.2
Unsigned32 · milliseconds
The minimum value permitted by a SCTP implementation for the retransmission timeout value, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout value. A retransmission time value of zero means immediate retransmission. The value of this object has to be lower than or equal to stcpRtoMax's value.
1.3.6.1.2.1.104.1.2.3
Unsigned32 · milliseconds
The maximum value permitted by a SCTP implementation for the retransmission timeout value, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout value. A retransmission time value of zero means immediate re- transmission. The value of this object has to be greater than or equal to stcpRtoMin's value.
1.3.6.1.2.1.104.1.2.4
Unsigned32 · milliseconds
The initial value for the retransmission timer. A retransmission time value of zero means immediate re- transmission.
1.3.6.1.2.1.104.1.2.5
Integer32 (-1 | 0..2147483647)
The limit on the total number of associations the entity can support. In entities where the maximum number of associations is dynamic, this object should contain the value -1.
1.3.6.1.2.1.104.1.2.6
Unsigned32 · milliseconds
Valid cookie life in the 4-way start-up handshake procedure. Reference: Section 5.1.3 in RFC2960 explains the cookie generation process. Recommended value is per section 14 in RFC2960.
1.3.6.1.2.1.104.1.2.7
Unsigned32
The maximum number of retransmissions at the start-up phase (INIT and COOKIE ECHO chunks). Reference: Section 5.1.4, 5.1.6 in RFC2960 refers to Max.Init.Retransmit parameter. Recommended value is per section 14 in RFC2960.
1.3.6.1.2.1.104.1.3
Index: sctpAssocId
A table containing SCTP association-specific information.
1.3.6.1.2.1.104.1.3.1.1
Unsigned32 (1..4294967295)
Association Identification. Value identifying the association.
1.3.6.1.2.1.104.1.3.1.2
OCTET STRING SIZE (0..255)
The peer's DNS name. This object needs to have the same format as the encoding in the DNS protocol. This implies that the domain name can be up to 255 octets long, each octet being 0<=x<=255 as value with US-ASCII A-Z having a case insensitive matching. If no DNS domain name was received from the peer at init time (embedded in the INIT or INIT-ACK chunk), this object is meaningless. In such cases the object MUST contain a zero- length string value. Otherwise, it contains the remote host name received at init time.
1.3.6.1.2.1.104.1.3.1.3
InetPortNumberRepresents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from <http://www.iana.org/>. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter.Reference: STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960 (1..65535) · Unsigned32 · hint d
The local SCTP port number used for this association.
1.3.6.1.2.1.104.1.3.1.4
InetPortNumberRepresents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from <http://www.iana.org/>. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter.Reference: STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960 (1..65535) · Unsigned32 · hint d
The remote SCTP port number used for this association.
1.3.6.1.2.1.104.1.3.1.5
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The internet type of primary remote IP address.
1.3.6.1.2.1.104.1.3.1.6
InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The primary remote IP address. The type of this address is determined by the value of sctpAssocRemPrimAddrType. The client side will know this value after INIT_ACK message reception, the server side will know this value when sending INIT_ACK message. However, values will be filled in at established(4) state.
1.3.6.1.2.1.104.1.3.1.7
Unsigned32 · milliseconds
The current heartbeat interval.. Zero value means no HeartBeat, even when the concerned sctpAssocRemAddrHBFlag object is true.
1.3.6.1.2.1.104.1.3.1.8
INTEGER1 = closed2 = cookieWait3 = cookieEchoed4 = established5 = shutdownPending6 = shutdownSent7 = shutdownReceived8 = shutdownAckSent9 = deleteTCB · Integer32
The state of this SCTP association. As in TCP, deleteTCB(9) is the only value that may be set by a management station. If any other value is received, then the agent must return a wrongValue error. If a management station sets this object to the value deleteTCB(9), then this has the effect of deleting the TCB (as defined in SCTP) of the corresponding association on the managed node, resulting in immediate termination of the association. As an implementation-specific option, an ABORT chunk may be sent from the managed node to the other SCTP endpoint as a result of setting the deleteTCB(9) value. The ABORT chunk implies an ungraceful association shutdown. Reference: Section 4 in RFC2960 covers the SCTP Association state diagram.
1.3.6.1.2.1.104.1.3.1.9
Unsigned32 (1..65535)
Inbound Streams according to the negotiation at association start up. Reference: Section 1.3 in RFC2960 includes a definition of stream. Section 5.1.1 in RFC2960 covers the streams negotiation process.
1.3.6.1.2.1.104.1.3.1.10
Unsigned32 (1..65535)
Outbound Streams according to the negotiation at association start up. Reference: Section 1.3 in RFC2960 includes a definition of stream. Section 5.1.1 in RFC2960 covers the streams negotiation process.
1.3.6.1.2.1.104.1.3.1.11
Unsigned32
The maximum number of data retransmissions in the association context. This value is specific for each association and the upper layer can change it by calling the appropriate primitives. This value has to be smaller than the addition of all the maximum number for all the paths (sctpAssocRemAddrMaxPathRtx). A value of zero value means no retransmissions.
1.3.6.1.2.1.104.1.3.1.12
Unsigned32
This object identifies the system level process which holds primary responsibility for the SCTP association. Wherever possible, this should be the system's native unique identification number. The special value 0 can be used to indicate that no primary process is known. Note that the value of this object can be used as a pointer into the swRunTable of the HOST-RESOURCES-MIB(if the value is smaller than 2147483647) or into the sysApplElmtRunTable of the SYSAPPL-MIB.
1.3.6.1.2.1.104.1.3.1.13
Counter32
The T1 timer determines how long to wait for an acknowledgement after sending an INIT or COOKIE-ECHO chunk. This object reflects the number of times the T1 timer expires without having received the acknowledgement. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of sctpAssocDiscontinuityTime. Reference: Section 5 in RFC2960.
1.3.6.1.2.1.104.1.3.1.14
Counter32
The T2 timer determines how long to wait for an acknowledgement after sending a SHUTDOWN or SHUTDOWN-ACK chunk. This object reflects the number of times that T2- timer expired. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of sctpAssocDiscontinuityTime. Reference: Section 9.2 in RFC2960.
1.3.6.1.2.1.104.1.3.1.15
Counter32
When T3-rtx expires, the DATA chunks that triggered the T3 timer will be re-sent according with the retransmissions rules. Every DATA chunk that was included in the SCTP packet that triggered the T3-rtx timer must be added to the value of this counter. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of sctpAssocDiscontinuityTime. Reference: Section 6 in RFC2960 covers the retransmission process and rules.
1.3.6.1.2.1.104.1.3.1.16
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 value of sysUpTime at the time that the association represented by this row enters the ESTABLISHED state, i.e., the sctpAssocState object is set to established(4). The value of this object will be zero: - before the association enters the established(4) state, or - if the established(4) state was entered prior to the last re-initialization of the local network management subsystem.
1.3.6.1.2.1.104.1.3.1.17
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 value of sysUpTime on the most recent occasion at which any one or more of this SCTP association counters suffered a discontinuity. The relevant counters are the specific instances associated with this interface of any Counter32 or Counter64 object contained in the sctpAssocTable or sctpLocalAddrTable or sctpRemAddrTable. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this object contains a zero value. Reference: The inclusion of this object is recommended by RFC2578.
1.3.6.1.2.1.104.1.4
Index: sctpAssocId · sctpAssocLocalAddrType · sctpAssocLocalAddr
Expanded table of sctpAssocTable based on the AssocId index. This table shows data related to each local IP address which is used by this association.
1.3.6.1.2.1.104.1.4.1.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
Internet type of local IP address used for this association.
1.3.6.1.2.1.104.1.4.1.2
InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The value of a local IP address available for this association. The type of this address is determined by the value of sctpAssocLocalAddrType.
1.3.6.1.2.1.104.1.4.1.3
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 value of sysUpTime at the time that this row was created.
1.3.6.1.2.1.104.1.5
Index: sctpAssocId · sctpAssocRemAddrType · sctpAssocRemAddr
Expanded table of sctpAssocTable based on the AssocId index. This table shows data related to each remote peer IP address which is used by this association.
1.3.6.1.2.1.104.1.5.1.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
Internet type of a remote IP address available for this association.
1.3.6.1.2.1.104.1.5.1.2
InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The value of a remote IP address available for this association. The type of this address is determined by the value of sctpAssocLocalAddrType.
1.3.6.1.2.1.104.1.5.1.3
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
This object gives information about the reachability of this specific remote IP address. When the object is set to 'true' (1), the remote IP address is understood as Active. Active means that the threshold of no answers received from this IP address has not been reached. When the object is set to 'false' (2), the remote IP address is understood as Inactive. Inactive means that either no heartbeat or any other message was received from this address, reaching the threshold defined by the protocol. Reference: The remote transport states are defined as Active and Inactive in the SCTP, RFC2960.
1.3.6.1.2.1.104.1.5.1.4
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
This object indicates whether the optional Heartbeat check associated to one destination transport address is activated or not (value equal to true or false, respectively).
1.3.6.1.2.1.104.1.5.1.5
Unsigned32 · milliseconds
The current Retransmission Timeout. T3-rtx timer as defined in the protocol SCTP. Reference: Section 6.3 in RFC2960 deals with the Retransmission Timer Management.
1.3.6.1.2.1.104.1.5.1.6
Unsigned32
Maximum number of DATA chunks retransmissions allowed to a remote IP address before it is considered inactive, as defined in RFC2960. Reference: Section 8.2, 8.3 and 14 in RFC2960.
1.3.6.1.2.1.104.1.5.1.7
Counter32
Number of DATA chunks retransmissions to this specific IP address. When T3-rtx expires, the DATA chunk that triggered the T3 timer will be re-sent according to the retransmissions rules. Every DATA chunk that is included in a SCTP packet and was transmitted to this specific IP address before, will be included in this counter. Discontinuities in the value of this counter can occur at re- initialization of the management system, and at other times as indicated by the value of sctpAssocDiscontinuityTime.
1.3.6.1.2.1.104.1.5.1.8
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 value of sysUpTime at the time that this row was created.
1.3.6.1.2.1.104.1.6
Index: sctpAssocLocalPort · sctpAssocId
With the use of this table, a list of associations which are using the specified local port can be retrieved.
1.3.6.1.2.1.104.1.6.1.1
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 value of sysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table.
1.3.6.1.2.1.104.1.7
Index: sctpAssocRemPort · sctpAssocId
With the use of this table, a list of associations which are using the specified remote port can be got
1.3.6.1.2.1.104.1.7.1.1
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 value of sysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table.
1.3.6.1.2.1.104.1.8
Index: sctpAssocRemHostName · sctpAssocId
With the use of this table, a list of associations with that particular host can be retrieved.
1.3.6.1.2.1.104.1.8.1.1
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 value of sysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table.
1.3.6.1.2.1.104.1.9
Index: sctpAssocRemPrimAddrType · sctpAssocRemPrimAddr · sctpAssocId
With the use of this table, a list of associations that have the specified IP address as primary within the remote set of active addresses can be retrieved.
1.3.6.1.2.1.104.1.9.1.1
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 value of SysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table.
1.3.6.1.2.1.104.1.10
Index: sctpAssocRemAddrType · sctpAssocRemAddr · sctpAssocId
With the use of this table, a list of associations that have the specified IP address as one of the remote ones can be retrieved.
1.3.6.1.2.1.104.1.10.1.1
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 value of SysUpTime at the time that this row was created. As the table will be created after the sctpAssocTable creation, this value could be equal to the sctpAssocStartTime object from the main table.