2006-10-10
Download RAQMON-RDS-MIB.txt Open RAQMON-RDS-MIB.txt in a new tab
This is the RAQMON Data Source notification MIB Module. It provides a mapping of RAQMON PDUs to SNMP notifications. Ds stands for data source. Note that all of the object types defined in this module are accessible-for-notify and would consequently not be available to a browser using simple Get, GetNext, or GetBulk requests. Copyright (c) The Internet Society (2006). This version of this MIB module is part of RFC 4712; See the RFC itself for full legal notices.
| Name | OID |
|---|---|
| raqmonDsNotificationTable | 1.3.6.1.2.1.16.32.1.1 |
| Name | OID |
|---|---|
| raqmonDsStaticNotification | 1.3.6.1.2.1.16.32.0.1 |
| raqmonDsDynamicNotification | 1.3.6.1.2.1.16.32.0.2 |
| raqmonDsByeNotification | 1.3.6.1.2.1.16.32.0.3 |
END OF TOC
1.3.6.1.2.1.16.32.1.1
Index: raqmonDsDSRC · raqmonDsRCN · raqmonDsPeerAddrType · raqmonDsPeerAddr
This conceptual table provides the SNMP mapping of the RAQMON BASIC PDU. It is indexed by the RAQMON Data Source, sub-session, and address of the peer entity. Note that there is no concern about the indexation of this table exceeding the limits defined by RFC 2578 Section 3.5. According to [RFC4710], Section 5.1, only IPv4 and IPv6 addresses can be reported as participant addresses.
1.3.6.1.2.1.16.32.1.1.1.1
Unsigned32
Data Source identifier represents a unique session descriptor that points to a specific session between communicating entities. Identifiers unique for sessions conducted between two entities are generated by the communicating entities. Zero is a valid value, with no special semantics.
1.3.6.1.2.1.16.32.1.1.1.2
Unsigned32 (0..15)
The Record Count Number indicates a sub-session within a communication session. A maximum number of 16 sub-sessions are supported; this limitation is dictated by reasons of compatibility with other transport protocols.
1.3.6.1.2.1.16.32.1.1.1.3
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 type of the Internet address of the peer participant for this session. Reference: Section 5.2 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.4
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 Internet Address of the peer participant for this session. Reference: Section 5.2 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.5
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
This is a text string giving the name and possibly the version of the application associated with that session, e.g., 'XYZ VoIP Agent 1.2'. Reference: Section 5.28 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.6
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 (0..65535) · Unsigned32 · hint d
The port number from which data for this session was sent by the Data Source device. Reference: Section 5.5 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.7
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 (0..65535) · Unsigned32 · hint d
The port number where the data for this session was received. Reference: Section 5.6 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.8
DateAndTimeA date-time specification. field octets contents range ----- ------ -------- ----- 1 1-2 year* 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UTC '+' / '-' 9 10 hours from UTC* 0..13 10 11 minutes from UTC 0..59 * Notes: - the value of year is in network-byte order - daylight saving time in New Zealand is +13 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as: 1992-5-26,13:30:15.0,-4:0 Note that if only local time is known, then timezone information (fields 8-10) is not present. SIZE (8 | 11) · OCTET STRING · hint 2d-1d-1d,1d:1d:1d.1d,1a1d:1d
The time when session was initiated. Reference: Section 5.7 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.9
Unsigned32 (0..65535) · milliseconds
Session setup time. Reference: Section 5.8 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.10
Unsigned32 · seconds
Session duration, including setup time. The SYNTAX of this object allows expression of the duration of sessions that do not exceed 4660 hours and 20 minutes. Reference: Section 5.9 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.11
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
Describes appropriate communication session states, e.g., Call Established successfully, RSVP reservation failed, etc. Reference: Section 5.10 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.12
Unsigned32 · milliseconds
Most recent available information about the round-trip end-to-end network delay. Reference: Section 5.11 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.13
Unsigned32 · milliseconds
Most recent available information about the one-way end-to-end network delay. Reference: Section 5.12 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.14
Unsigned32 (0..65535) · milliseconds
Most recent available information about the application delay. Reference: Section 5.13 of [RFC4710
1.3.6.1.2.1.16.32.1.1.1.15
Unsigned32 (0..65535) · milliseconds
An estimate of the inter-arrival jitter. Reference: Section 5.14 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.16
Unsigned32 (0..65535) · milliseconds
An estimate of the inter-arrival delay variation. Reference: Section 5.15 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.17
Counter32 · packets
The number of packets transmitted within a communication session by the receiver since the start of the session. Reference: Section 5.16 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.18
Counter32 · packets
The number of packets transmitted within a communication session by the sender since the start of the session. Reference: Section 5.17 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.19
Counter32 · octets
The total number of payload octets (i.e., not including header or padding octets) transmitted in packets by the receiver within a communication session since the start of the session. Reference: Section 5.18 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.20
Counter32 · octets
The number of payload octets (i.e., not including headers or padding) transmitted in packets by the sender within a communication sub-session since the start of the session. Reference: Section 5.19 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.21
Counter32 · packets
The number of packets from this session whose loss had been detected since the start of the session. Reference: Section 5.20 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.22
Unsigned32 (0..100) · percentage of packets sent
The percentage of lost packets with respect to the overall packets sent. This is defined to be 100 times the number of packets lost divided by the number of packets expected. Reference: Section 5.21 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.23
Counter32 · packets
The number of packet discards detected since the start of the session. Reference: Section 5.22 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.24
Unsigned32 (0..100) · percentage of packets sent
The percentage of discards with respect to the overall packets sent. This is defined to be 100 times the number of discards divided by the number of packets expected. Reference: Section 5.23 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.25
Unsigned32 (0..127)
The payload type of the packet sent by this RDS. Reference: RFC 1890, Section 5.24 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.26
Unsigned32 (0..127)
The payload type of the packet received by this RDS. Reference: RFC 1890, Section 5.25 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.27
Unsigned32 (0..7)
Source Layer 2 priority used by the data source to send packets to the receiver by this data source during this communication session. Reference: Section 5.26 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.28
DscpA Differentiated Services Code-Point that may be used for marking a traffic stream.Reference: RFC 2474, RFC 2780 (0..63) · Integer32 · hint d
Layer 3 TOS/DSCP values used by the Data Source to prioritize traffic sent. Reference: Section 5.27 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.29
Unsigned32 (0..7)
Destination Layer 2 priority. This is the priority used by the peer communicating entity to send packets to the data source. Reference: Section 5.28 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.30
DscpA Differentiated Services Code-Point that may be used for marking a traffic stream.Reference: RFC 2474, RFC 2780 (0..63) · Integer32 · hint d
Layer 3 TOS/DSCP values used by the peer communicating entity to prioritize traffic sent to the source. Reference: Section 5.29 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.31
Unsigned32 (0..100) · percent
Latest available information about the total CPU utilization. Reference: Section 5.30 of [RFC4710]
1.3.6.1.2.1.16.32.1.1.1.32
Unsigned32 (0..100) · percent
Latest available information about the total memory utilization. Reference: Section 5.31 of [RFC4710]
1.3.6.1.2.1.16.32.0.1
This notification maps the static parameters in the BASIC RAQMON PDU onto an SNMP transport. This notification is expected to be sent once per session, or when a new sub-session is initiated. The following objects MAY be carried by the raqmonDsStaticNotification: raqmonDsDataSourceDevicePort, raqmonDsReceiverDevicePort, raqmonDsSessionSetupDateTime, raqmonDsSessionSetupDelay, raqmonDsSessionDuration, raqmonDsSourcePayloadType, raqmonDsReceiverPayloadType, raqmonDsSourceLayer2Priority, raqmonDsSourceDscp, raqmonDsDestinationLayer2Priority, raqmonDsDestinationDscp It is RECOMMENDED to keep the size of a notification within the MTU size limits in order to avoid fragmentation.
1.3.6.1.2.1.16.32.1.1.1.5
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
This is a text string giving the name and possibly the version of the application associated with that session, e.g., 'XYZ VoIP Agent 1.2'. Reference: Section 5.28 of [RFC4710]
1.3.6.1.2.1.16.32.0.2
This notification maps the dynamic parameters in the BASIC RAQMON PDU onto an SNMP transport. The following objects MAY be carried by the raqmonDsDynamicNotification: raqmonDsRoundTripEndToEndNetDelay, raqmonDsOneWayEndToEndNetDelay, raqmonDsApplicationDelay, raqmonDsInterArrivalJitter, raqmonDsIPPacketDelayVariation, raqmonDsTotalPacketsSent, raqmonDsTotalOctetsReceived, raqmonDsTotalOctetsSent, raqmonDsCumulativePacketLoss, raqmonDsPacketLossFraction, raqmonDsCumulativeDiscards, raqmonDsDiscardsFraction, raqmonDsCpuUtilization, raqmonDsMemoryUtilization It is RECOMMENDED to keep the size of a notification within the MTU size limits in order to avoid fragmentation.
1.3.6.1.2.1.16.32.1.1.1.17
Counter32 · packets
The number of packets transmitted within a communication session by the receiver since the start of the session. Reference: Section 5.16 of [RFC4710]
1.3.6.1.2.1.16.32.0.3
The BYE Notification. This Notification is the equivalent of the RAQMON NULL PDU, which signals the end of a RAQMON session.
1.3.6.1.2.1.16.32.1.1.1.5
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t
This is a text string giving the name and possibly the version of the application associated with that session, e.g., 'XYZ VoIP Agent 1.2'. Reference: Section 5.28 of [RFC4710]