OID reference

teldatNsmStatsCaptureTable

1.3.6.1.4.1.2007.4.1.2.4.6.1.3.1

Description

The statistics capture database. The statistics capture table contains summarized information of the results for a conceptual RTT control row. A rolling accumulated history of this information is maintained in a series of hourly 'group(s)'. Each 'group' contains a series of 'path(s)', each 'path' contains a series of …

Full description and source information

Identification

Identifier and names

Parent
1.3.6.1.4.1.2007.4.1.2.4.6.1.3 (teldatNsmStats)
Node code
1
Node name
teldatNsmStatsCaptureTable
Category
SNMP management object
Numeric OID
1.3.6.1.4.1.2007.4.1.2.4.6.1.3.1
URN notation
urn:oid:1.3.6.1.4.1.2007.4.1.2.4.6.1.3.1
ASN.1, OID-IRI and named path variants
ASN.1 notation

{1 3 6 1 4 1 2007 4 1 2 4 6 1 3 1}

  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprises(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) ldap-enterprise(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) identified-organization(3) dod(6) internet(1) private(4) vendor-objects(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) org(3) dod(6) internet(1) private(4) ldap-enterprise(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) org(3) dod(6) internet(1) private(4) vendor-objects(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) enterprise(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) enterprises(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) ldap-enterprise(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) vendor-objects(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) iso-organization(3) dod(6) internet(1) private(4) enterprise(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) iso-organization(3) dod(6) internet(1) private(4) enterprises(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) iso-organization(3) dod(6) internet(1) private(4) ldap-enterprise(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
  • {iso(1) iso-organization(3) dod(6) internet(1) private(4) vendor-objects(1) teldat(2007) telproducts(4) telProductsNucleox(1) telProductsNpMonit(2) telProdNpMonFeatures(4) teldatNsmMonMIB(6) teldatNsmObjects(1) teldatNsmStats(3) teldatNsmStatsCaptureTable(1)}
OID-IRI notation
  • /1/3/6/1/4/1/2007/4/1/2/4/6/1/3/1
  • /ISO/Identified-Organization/6/1/4/1/2007/4/1/2/4/6/1/3/1
  • /ISO/3/6/1/4/1/2007/4/1/2/4/6/1/3/1
Named path variants
  • /iso/identified-organization/dod/internet/private/enterprise/2007/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/identified-organization/dod/internet/private/enterprise/teldat/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/identified-organization/dod/internet/private/enterprises/2007/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/identified-organization/dod/internet/private/enterprises/teldat/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/identified-organization/dod/internet/private/ldap-enterprise/2007/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/identified-organization/dod/internet/private/ldap-enterprise/teldat/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/identified-organization/dod/internet/private/vendor-objects/2007/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/identified-organization/dod/internet/private/vendor-objects/teldat/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/org/dod/internet/private/enterprise/2007/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/org/dod/internet/private/enterprise/teldat/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/org/dod/internet/private/enterprises/2007/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/org/dod/internet/private/enterprises/teldat/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/org/dod/internet/private/ldap-enterprise/2007/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/org/dod/internet/private/ldap-enterprise/teldat/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/org/dod/internet/private/vendor-objects/2007/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • /iso/org/dod/internet/private/vendor-objects/teldat/telproducts/telProductsNucleox/telProductsNpMonit/telProdNpMonFeatures/teldatNsmMonMIB/teldatNsmObjects/teldatNsmStats/teldatNsmStatsCaptureTable
  • Additional combinations skipped.

SNMP properties

Value type
SEQUENCE OF TeldatNsmStatsCaptureEntry
Maximum access defined by MIB
not-accessible
Status in MIB
current

Properties come from available MIB definitions. Actual device support and access can differ. See source records below for original files and qualifications.

The displayed source records contain one distinct definition. Compare its source records.

teldatNsmStatsCaptureTable OBJECT-TYPE
    SYNTAX SEQUENCE OF TeldatNsmStatsCaptureEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The statistics capture database.

        The statistics capture table contains summarized information of the
        results for a conceptual RTT control row.  A rolling accumulated
        history of this information is maintained in a series of hourly
        'group(s)'. Each 'group' contains a series of 'path(s)', each 'path'
        contains a series of 'hop(s)', each 'hop' contains a series of
        'statistics distribution bucket(s)'.

        In current implementation, the rolling accumulated information history
        is maintained only in one hourly 'group'; each 'group' will contained
        only one 'path', each path one 'hop', and each 'hop' one 'statistics
        distribution bucket'.

        Each conceptual statistics row has a current hourly group, into which
        RTT results are accumulated. At the end of each hour a new hourly group
        is created which then becomes current. The counters and accumulators in
        the new group are initialized to zero. The previous group(s) is kept in
        the table until the table contains the maximum number of groups
        established for the conceptual statistics row: in current implementation
        only an hourly 'group' is maintained; at this point, the oldest group
        is discarded and is replaced by the newly created one (as only one group
        is kept, previously groups are deleted). The hourly group is uniquely
        identified by the teldatNsmStatsCaptureStartTimeIndex object.

        If the activity for a conceptual RTT control row ceases because the
        teldatNsmCtrlOperState object transitions to 'inactive', the
        corresponding current hourly group in this table must be 'frozen', and
        a new hourly group created when activity is resumed: in this particular
        case, current hourly group will be deleted and a new one created when
        activity is resumed.

        If the activity for a conceptual RTT control row ceases because the
        teldatNsmCtrlOperState object transitions to 'pending' this whole table
        will be cleared and reset to its initial state.

        Using this teldatNsmStatsCaptureTable, a managing application can
        retrieve summarized data from accurately measured periods, which is
        synchronized across multiple conceptual RTT control rows. With the
        new hourly group creation being performed on a 60 minute period, the
        managing station has plenty of time to collect the data, and need not
        be concerned with the vagaries of network delays and lost PDU's when
        trying to get matching data. Also, the managing station can spread
        the data gathering over a longer period, which removes the need for
        a flood of get requests in a short period which otherwise would occur."
    ::= { teldatNsmStats 1 }

Meaning

Descriptions

1 unique

Identical descriptions are grouped. Different wording and device-specific notes are retained.

The statistics capture database. The statistics capture table contains summarized information of the results for a conceptual RTT control row. A rolling accumulated history of this information is maintained in a series of hourly 'group(s)'. Each 'group' contains a series of 'path(s)', each 'path' contains a series of 'hop(s)', each 'hop' contains a series of 'statistics distribution bucket(s)'. In current implementation, the rolling accumulated information history is maintained only in one hourly 'group'; each 'group' will contained only one 'path', each path one 'hop', and each 'hop' one 'statistics distribution bucket'. Each conceptual statistics row has a current hourly group, into which RTT results are accumulated. At the end of each hour a new hourly group is created which then becomes current. The counters and accumulators in the new group are initialized to zero. The previous group(s) is kept in the table until the table contains the maximum number of groups established for the conceptual statistics row: in current implementation only an hourly 'group' is maintained; at this point, the oldest group is discarded and is replaced by the newly created one (as only one group is kept, previously groups are deleted). The hourly group is uniquely identified by the teldatNsmStatsCaptureStartTimeIndex object. If the activity for a conceptual RTT control row ceases because the teldatNsmCtrlOperState object transitions to 'inactive', the corresponding current hourly group in this table must be 'frozen', and a new hourly group created when activity is resumed: in this particular case, current hourly group will be deleted and a new one created when activity is resumed. If the activity for a conceptual RTT control row ceases because the teldatNsmCtrlOperState object transitions to 'pending' this whole table will be cleared and reset to its initial state. Using this teldatNsmStatsCaptureTable, a managing application can retrieve summarized data from accurately measured periods, which is synchronized across multiple conceptual RTT control rows. With the new hourly group creation being performed on a 60 minute period, the managing station has plenty of time to collect the data, and need not be concerned with the vagaries of network delays and lost PDU's when trying to get matching data. Also, the managing station can spread the data gathering over a longer period, which removes the need for a flood of get requests in a short period which otherwise would occur.

Sources for this description

Teldat MIB copies (MibBrowser.online)

See 1 matching source record

Evidence

Source records

1 records

Matching descriptions are grouped; open a group to compare definitions and supporting files.

Records for description 1Teldat MIB copies (MibBrowser.online)1 record · 1 source

Description 1

teldatNsmStatsCaptureTable · currentTeldat MIB copies (MibBrowser.online)1 source

Status in source: current.

Names: teldatNsmStatsCaptureTable

Technical details
{
  "smi_kind": "OBJECT-TYPE",
  "definition": [
    "teldatNsmStatsCaptureTable",
    "OBJECT-TYPE",
    "SYNTAX",
    "SEQUENCE",
    "OF",
    "TeldatNsmStatsCaptureEntry",
    "MAX-ACCESS",
    "not-accessible",
    "STATUS",
    "current",
    "DESCRIPTION",
    "\"The statistics capture database. The statistics capture table contains summarized information of the results for a conceptual RTT control row. A rolling accumulated history of this information is maintained in a series of hourly 'group(s)'. Each 'group' contains a series of 'path(s)', each 'path' contains a series of 'hop(s)', each 'hop' contains a series of 'statistics distribution bucket(s)'. In current implementation, the rolling accumulated information history is maintained only in one hourly 'group'; each 'group' will contained only one 'path', each path one 'hop', and each 'hop' one 'statistics distribution bucket'. Each conceptual statistics row has a current hourly group, into which RTT results are accumulated. At the end of each hour a new hourly group is created which then becomes current. The counters and accumulators in the new group are initialized to zero. The previous group(s) is kept in the table until the table contains the maximum number of groups established for the conceptual statistics row: in current implementation only an hourly 'group' is maintained; at this point, the oldest group is discarded and is replaced by the newly created one (as only one group is kept, previously groups are deleted). The hourly group is uniquely identified by the teldatNsmStatsCaptureStartTimeIndex object. If the activity for a conceptual RTT control row ceases because the teldatNsmCtrlOperState object transitions to 'inactive', the corresponding current hourly group in this table must be 'frozen', and a new hourly group created when activity is resumed: in this particular case, current hourly group will be deleted and a new one created when activity is resumed. If the activity for a conceptual RTT control row ceases because the teldatNsmCtrlOperState object transitions to 'pending' this whole table will be cleared and reset to its initial state. Using this teldatNsmStatsCaptureTable, a managing application can retrieve summarized data from accurately measured periods, which is synchronized across multiple conceptual RTT control rows. With the new hourly group creation being performed on a 60 minute period, the managing station has plenty of time to collect the data, and need not be concerned with the vagaries of network delays and lost PDU's when trying to get matching data. Also, the managing station can spread the data gathering over a longer period, which removes the need for a flood of get requests in a short period which otherwise would occur.\"",
    "::=",
    "{",
    "teldatNsmStats",
    "1",
    "}"
  ],
  "syntax_tree": [
    [
      "conceptualTable",
      [
        "row",
        "TeldatNsmStatsCaptureEntry"
      ]
    ],
    null,
    [
      "MaxAccessPart",
      "not-accessible"
    ],
    [
      "Status",
      "current"
    ],
    [
      "DESCRIPTION",
      "The statistics capture database. The statistics capture table contains summarized information of the results for a conceptual RTT control row. A rolling accumulated history of this information is maintained in a series of hourly 'group(s)'. Each 'group' contains a series of 'path(s)', each 'path' contains a series of 'hop(s)', each 'hop' contains a series of 'statistics distribution bucket(s)'. In current implementation, the rolling accumulated information history is maintained only in one hourly 'group'; each 'group' will contained only one 'path', each path one 'hop', and each 'hop' one 'statistics distribution bucket'. Each conceptual statistics row has a current hourly group, into which RTT results are accumulated. At the end of each hour a new hourly group is created which then becomes current. The counters and accumulators in the new group are initialized to zero. The previous group(s) is kept in the table until the table contains the maximum number of groups established for the conceptual statistics row: in current implementation only an hourly 'group' is maintained; at this point, the oldest group is discarded and is replaced by the newly created one (as only one group is kept, previously groups are deleted). The hourly group is uniquely identified by the teldatNsmStatsCaptureStartTimeIndex object. If the activity for a conceptual RTT control row ceases because the teldatNsmCtrlOperState object transitions to 'inactive', the corresponding current hourly group in this table must be 'frozen', and a new hourly group created when activity is resumed: in this particular case, current hourly group will be deleted and a new one created when activity is resumed. If the activity for a conceptual RTT control row ceases because the teldatNsmCtrlOperState object transitions to 'pending' this whole table will be cleared and reset to its initial state. Using this teldatNsmStatsCaptureTable, a managing application can retrieve summarized data from accurately measured periods, which is synchronized across multiple conceptual RTT control rows. With the new hourly group creation being performed on a 60 minute period, the managing station has plenty of time to collect the data, and need not be concerned with the vagaries of network delays and lost PDU's when trying to get matching data. Also, the managing station can spread the data gathering over a longer period, which removes the need for a flood of get requests in a short period which otherwise would occur."
    ],
    null,
    null,
    null,
    null
  ]
}

Registration

Registration authorities

First Registration Authority (inferred from ancestor 1.3.6.1.4.1.2007)

Eduardo Robles Esteban

Direct children (1)

OIDNameDirect childrenDescendantsDescription
1.3.6.1.4.1.2007.4.1.2.4.6.1.3.1.1 teldatNsmStatsCaptureEntry1111

Siblings (4)

OIDNameDirect childrenDescendantsDescription
1.3.6.1.4.1.2007.4.1.2.4.6.1.3.2 teldatNsmStatsCollectTable19
1.3.6.1.4.1.2007.4.1.2.4.6.1.3.3 teldatNsmStatsTotalsTable13
1.3.6.1.4.1.2007.4.1.2.4.6.1.3.4 teldatNsmHTTPStatsTable120
1.3.6.1.4.1.2007.4.1.2.4.6.1.3.5 teldatNsmJitterStatsTable152