teldatNsmMonMIB

{
  "smi_kind": "MODULE-IDENTITY",
  "definition": [
    "teldatNsmMonMIB",
    "MODULE-IDENTITY",
    "LAST-UPDATED",
    [
      "literal",
      "22303430313330313830305a22"
    ],
    "ORGANIZATION",
    "\"Teldat, S.A.\"",
    "CONTACT-INFO",
    "\"Teldat, S.A. Customer Service Postal: Parque Tecnolgico de Madrid Tres Cantos 28760 Madrid, SPAIN Tel.: +34 918 076 565 http://www.teldat.com\"",
    "DESCRIPTION",
    "\"This module defines a MIB for Round Trip Time (RTT) monitoring of a list of targets, using a variety of protocols: MIB for management of Teldat feature Network Service Monitor. The table structure overview is as follows (t: indicates a table, at: indicates an augmented table, and it: indicates table with the same indices/control as parent table): NSM MIB |--- Application Group | |--- Application version string | |--- Max number of entries in teldatNsmCtrlAdminTable | |--- Overall Control Group | |t-- Master Definitions Table | | |--- Global Configuration Definitions | | |--- Config for a single RTT Life | | |it- Echo Specific Configuration | | |at- Schedule Configuration | | |at- Monitoring Operational State | | |at- Last RTT operation | |--- Statistics Collection Group | |t-- Statistics Capture Table | |--- Captured Statistics | |it- Statistics Collection Table | |it- Statistics Totals Table | |t-- HTTP Stats Table | |t-- Jitter Stats Table | |--- History Collection Group | |--- Latest Operation Group | |t-- Latest HTTP Oper Table | |t-- Latest Jitter Oper Table DEFINITIONS: conceptual RTT control row - This is a row in the 'Overall Control Group'. This row is indexed via the teldatNsmCtrlAdminIndex object. This row is spread across multiple real tables in the 'Overall Control Group'. probe - This is the entity that executes via a conceptual RTT control row and populates a conceptual statistics row. Rtt operation - This is a single operation performed by a probe. This operation can be a single Rtt attempt/completion or a group of Rtt attempts/completions that produce one operation table entry. ARR Protocol Definition: The format of the RTT Asymmetric Request/Responses (ARR) protocol is as follows: The ARR Header (total of 12 octets): 4 octet -> eyecatcher: 'WxYz' 1 octet -> version : 0x01 - protocol version 1 octet -> command : 0x01 - logoff request 0x02 - echo request 0x03 - echo response 0x04 - software version request 0x05 - software version response 2 octet -> sequence number (Network Byte Order) 4 octet -> response data size (Network Byte Order) The ARR Data: n octets -> request/response data: 'AB..ZAB..ZAB..' For software version request/response the protocol version octet will contain the version number of the responder. Thus the sequence number, etc will not be included. The response data should be appended to the origin request data. This allows data verification to check the data that flows in both directions. If the response data size is smaller than the request data size the original request data will be truncated. An example would be: Request: / Response: 'WxYz' / 'WxYz' 0x01 / 0x01 0x02 / 0x03 0x0001 / 0x0001 0x00000008 / 0x00000008 'ABCDEF' / 'ABCDEFGH' NOTE: We requested 8 bytes in the response and the response had 8 bytes. The size of the request data has no correlation to the size of the response data. NOTE: For native RTT request/response (i.e. ipIcmpecho) operations both the 'Header' and 'Data' will be included. Only the 'sequence number' in the Header will be valid. NOTE: For non-connection oriented protocol the initial RTT request/response operation will be preceded with an RTT request/response operation to the target address to force path exploration and to prove connectivity. Statistics capture table will omit these responses to prevent skewed results.\"",
    "REVISION",
    [
      "literal",
      "22303430313330313830305a22"
    ],
    "DESCRIPTION",
    "\"Initial implementation.\"",
    "::=",
    "{",
    "telProdNpMonFeatures",
    "6",
    "}"
  ],
  "syntax_tree": [
    [
      "LAST-UPDATED",
      "0401301800Z"
    ],
    [
      "ORGANIZATION",
      "Teldat, S.A."
    ],
    [
      "CONTACT-INFO",
      "Teldat, S.A. Customer Service Postal: Parque Tecnolgico de Madrid Tres Cantos 28760 Madrid, SPAIN Tel.: +34 918 076 565 http://www.teldat.com"
    ],
    [
      "DESCRIPTION",
      "This module defines a MIB for Round Trip Time (RTT) monitoring of a list of targets, using a variety of protocols: MIB for management of Teldat feature Network Service Monitor. The table structure overview is as follows (t: indicates a table, at: indicates an augmented table, and it: indicates table with the same indices/control as parent table): NSM MIB |--- Application Group | |--- Application version string | |--- Max number of entries in teldatNsmCtrlAdminTable | |--- Overall Control Group | |t-- Master Definitions Table | | |--- Global Configuration Definitions | | |--- Config for a single RTT Life | | |it- Echo Specific Configuration | | |at- Schedule Configuration | | |at- Monitoring Operational State | | |at- Last RTT operation | |--- Statistics Collection Group | |t-- Statistics Capture Table | |--- Captured Statistics | |it- Statistics Collection Table | |it- Statistics Totals Table | |t-- HTTP Stats Table | |t-- Jitter Stats Table | |--- History Collection Group | |--- Latest Operation Group | |t-- Latest HTTP Oper Table | |t-- Latest Jitter Oper Table DEFINITIONS: conceptual RTT control row - This is a row in the 'Overall Control Group'. This row is indexed via the teldatNsmCtrlAdminIndex object. This row is spread across multiple real tables in the 'Overall Control Group'. probe - This is the entity that executes via a conceptual RTT control row and populates a conceptual statistics row. Rtt operation - This is a single operation performed by a probe. This operation can be a single Rtt attempt/completion or a group of Rtt attempts/completions that produce one operation table entry. ARR Protocol Definition: The format of the RTT Asymmetric Request/Responses (ARR) protocol is as follows: The ARR Header (total of 12 octets): 4 octet -> eyecatcher: 'WxYz' 1 octet -> version : 0x01 - protocol version 1 octet -> command : 0x01 - logoff request 0x02 - echo request 0x03 - echo response 0x04 - software version request 0x05 - software version response 2 octet -> sequence number (Network Byte Order) 4 octet -> response data size (Network Byte Order) The ARR Data: n octets -> request/response data: 'AB..ZAB..ZAB..' For software version request/response the protocol version octet will contain the version number of the responder. Thus the sequence number, etc will not be included. The response data should be appended to the origin request data. This allows data verification to check the data that flows in both directions. If the response data size is smaller than the request data size the original request data will be truncated. An example would be: Request: / Response: 'WxYz' / 'WxYz' 0x01 / 0x01 0x02 / 0x03 0x0001 / 0x0001 0x00000008 / 0x00000008 'ABCDEF' / 'ABCDEFGH' NOTE: We requested 8 bytes in the response and the response had 8 bytes. The size of the request data has no correlation to the size of the response data. NOTE: For native RTT request/response (i.e. ipIcmpecho) operations both the 'Header' and 'Data' will be included. Only the 'sequence number' in the Header will be valid. NOTE: For non-connection oriented protocol the initial RTT request/response operation will be preceded with an RTT request/response operation to the target address to force path exploration and to prove connectivity. Statistics capture table will omit these responses to prevent skewed results."
    ],
    [
      "Revisions",
      [
        [
          "0401301800Z",
          [
            "DESCRIPTION",
            "Initial implementation."
          ]
        ]
      ]
    ]
  ]
}