Network Working Group February 13, 2014
Internet-Draft
Intended status: Informational
Expires: August 17, 2014
List of SMIv2 Textual Conventions
textual-convention-list.txt
Abstract
List of SMIv2 Textual Conventions. This file has been generated by
smidump. Do not edit.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
Expires August 17, 2014 [Page 1]
Internet-Draft SMIv2 Textual Conventions February 2014
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. ACCOUNTING-CONTROL-MIB (revision 1998-09-28 10:00) . . . . . 21
1.1. DataCollectionSubtree . . . . . . . . . . . . . . . . . 21
1.2. DataCollectionList . . . . . . . . . . . . . . . . . . 21
1.3. FileIndex . . . . . . . . . . . . . . . . . . . . . . . 22
2. ADSL2-LINE-TC-MIB (revision 2006-10-04 00:00) . . . . . . . 22
2.1. Adsl2Unit . . . . . . . . . . . . . . . . . . . . . . . 22
2.2. Adsl2Direction . . . . . . . . . . . . . . . . . . . . 22
2.3. Adsl2TransmissionModeType . . . . . . . . . . . . . . . 22
2.4. Adsl2RaMode . . . . . . . . . . . . . . . . . . . . . . 24
2.5. Adsl2InitResult . . . . . . . . . . . . . . . . . . . . 24
2.6. Adsl2OperationModes . . . . . . . . . . . . . . . . . . 24
2.7. Adsl2PowerMngState . . . . . . . . . . . . . . . . . . 26
2.8. Adsl2ConfPmsForce . . . . . . . . . . . . . . . . . . . 26
2.9. Adsl2LConfProfPmMode . . . . . . . . . . . . . . . . . 26
2.10. Adsl2LineLdsf . . . . . . . . . . . . . . . . . . . . . 26
2.11. Adsl2LdsfResult . . . . . . . . . . . . . . . . . . . . 27
2.12. Adsl2SymbolProtection . . . . . . . . . . . . . . . . . 27
2.13. Adsl2MaxBer . . . . . . . . . . . . . . . . . . . . . . 28
2.14. Adsl2ScMaskDs . . . . . . . . . . . . . . . . . . . . . 28
2.15. Adsl2ScMaskUs . . . . . . . . . . . . . . . . . . . . . 28
2.16. Adsl2RfiDs . . . . . . . . . . . . . . . . . . . . . . 28
2.17. Adsl2PsdMaskDs . . . . . . . . . . . . . . . . . . . . 28
2.18. Adsl2PsdMaskUs . . . . . . . . . . . . . . . . . . . . 29
2.19. Adsl2Tssi . . . . . . . . . . . . . . . . . . . . . . . 29
2.20. Adsl2LastTransmittedState . . . . . . . . . . . . . . . 29
2.21. Adsl2LineStatus . . . . . . . . . . . . . . . . . . . . 29
2.22. Adsl2ChAtmStatus . . . . . . . . . . . . . . . . . . . 30
2.23. Adsl2ChPtmStatus . . . . . . . . . . . . . . . . . . . 30
3. ADSL-LINE-EXT-MIB (revision 2002-12-10 00:00) . . . . . . . 31
3.1. AdslTransmissionModeType . . . . . . . . . . . . . . . 31
4. ADSL-TC-MIB (revision 1999-08-19 00:00) . . . . . . . . . . 31
4.1. AdslLineCodingType . . . . . . . . . . . . . . . . . . 31
4.2. AdslPerfCurrDayCount . . . . . . . . . . . . . . . . . 31
4.3. AdslPerfPrevDayCount . . . . . . . . . . . . . . . . . 32
4.4. AdslPerfTimeElapsed . . . . . . . . . . . . . . . . . . 32
Expires August 17, 2014 [Page 2]
Internet-Draft SMIv2 Textual Conventions February 2014
5. AGENTX-MIB (revision 2000-01-10 00:00) . . . . . . . . . . . 33
5.1. AgentxTAddress . . . . . . . . . . . . . . . . . . . . 33
6. AGGREGATE-MIB (revision 2006-04-27 00:00) . . . . . . . . . 33
6.1. AggrMOErrorStatus . . . . . . . . . . . . . . . . . . . 33
6.2. AggrMOValue . . . . . . . . . . . . . . . . . . . . . . 34
6.3. AggrMOCompressedValue . . . . . . . . . . . . . . . . . 35
7. ALARM-MIB (revision 2004-09-09 00:00) . . . . . . . . . . . 35
7.1. ResourceId . . . . . . . . . . . . . . . . . . . . . . 35
7.2. LocalSnmpEngineOrZeroLenStr . . . . . . . . . . . . . . 36
8. APM-MIB (revision 2004-02-19 00:00) . . . . . . . . . . . . 36
8.1. AppLocalIndex . . . . . . . . . . . . . . . . . . . . . 36
8.2. ProtocolDirNetworkAddress . . . . . . . . . . . . . . . 37
8.3. DataSourceOrZero . . . . . . . . . . . . . . . . . . . 38
8.4. RmonClientID . . . . . . . . . . . . . . . . . . . . . 38
8.5. TransactionAggregationType . . . . . . . . . . . . . . 39
9. APPC-MIB (revision 1995-12-15 00:00) . . . . . . . . . . . . 40
9.1. SnaSenseData . . . . . . . . . . . . . . . . . . . . . 41
10. APPLICATION-MIB (revision 1998-11-17 18:15) . . . . . . . . 41
10.1. Unsigned64TC . . . . . . . . . . . . . . . . . . . . . 41
10.2. ApplTAddress . . . . . . . . . . . . . . . . . . . . . 41
11. APPN-MIB (revision 1998-07-15 18:00) . . . . . . . . . . . . 41
11.1. SnaNodeIdentification . . . . . . . . . . . . . . . . . 41
11.2. SnaControlPointName . . . . . . . . . . . . . . . . . . 42
11.3. SnaClassOfServiceName . . . . . . . . . . . . . . . . . 42
11.4. SnaModeName . . . . . . . . . . . . . . . . . . . . . . 43
11.5. SnaSenseData . . . . . . . . . . . . . . . . . . . . . 43
11.6. DisplayableDlcAddress . . . . . . . . . . . . . . . . . 44
11.7. AppnNodeCounter . . . . . . . . . . . . . . . . . . . . 44
11.8. AppnPortCounter . . . . . . . . . . . . . . . . . . . . 44
11.9. AppnLinkStationCounter . . . . . . . . . . . . . . . . 44
11.10. AppnTopologyEntryTimeLeft . . . . . . . . . . . . . . . 44
11.11. AppnTgDlcData . . . . . . . . . . . . . . . . . . . . . 45
11.12. AppnTgEffectiveCapacity . . . . . . . . . . . . . . . . 45
11.13. AppnTgSecurity . . . . . . . . . . . . . . . . . . . . 45
11.14. AppnTgDelay . . . . . . . . . . . . . . . . . . . . . . 46
12. APS-MIB (revision 2003-02-28 00:00) . . . . . . . . . . . . 47
12.1. ApsK1K2 . . . . . . . . . . . . . . . . . . . . . . . . 47
12.2. ApsSwitchCommand . . . . . . . . . . . . . . . . . . . 48
12.3. ApsControlCommand . . . . . . . . . . . . . . . . . . . 49
13. ARC-MIB (revision 2004-09-09 00:00) . . . . . . . . . . . . 50
13.1. IANAItuProbableCauseOrZero . . . . . . . . . . . . . . 50
14. ATM-TC-MIB (revision 1998-10-19 02:00) . . . . . . . . . . . 50
14.1. AtmAddr . . . . . . . . . . . . . . . . . . . . . . . . 51
14.2. AtmConnCastType . . . . . . . . . . . . . . . . . . . . 51
14.3. AtmConnKind . . . . . . . . . . . . . . . . . . . . . . 51
14.4. AtmIlmiNetworkPrefix . . . . . . . . . . . . . . . . . 52
14.5. AtmInterfaceType . . . . . . . . . . . . . . . . . . . 53
14.6. AtmServiceCategory . . . . . . . . . . . . . . . . . . 54
Expires August 17, 2014 [Page 3]
Internet-Draft SMIv2 Textual Conventions February 2014
14.7. AtmSigDescrParamIndex . . . . . . . . . . . . . . . . . 54
14.8. AtmTrafficDescrParamIndex . . . . . . . . . . . . . . . 54
14.9. AtmVcIdentifier . . . . . . . . . . . . . . . . . . . . 54
14.10. AtmVpIdentifier . . . . . . . . . . . . . . . . . . . . 55
14.11. AtmVorXAdminStatus . . . . . . . . . . . . . . . . . . 55
14.12. AtmVorXLastChange . . . . . . . . . . . . . . . . . . . 55
14.13. AtmVorXOperStatus . . . . . . . . . . . . . . . . . . . 55
15. BLDG-HVAC-MIB (revision 2003-03-27 00:00) . . . . . . . . . 55
15.1. BldgHvacOperation . . . . . . . . . . . . . . . . . . . 56
16. BRIDGE-MIB (revision 2005-09-19 00:00) . . . . . . . . . . . 56
16.1. BridgeId . . . . . . . . . . . . . . . . . . . . . . . 56
16.2. Timeout . . . . . . . . . . . . . . . . . . . . . . . . 56
17. CAPWAP-BASE-MIB (revision 2010-04-30 00:00) . . . . . . . . 57
17.1. CapwapBaseWtpProfileIdTC . . . . . . . . . . . . . . . 58
17.2. CapwapBaseWtpIdTC . . . . . . . . . . . . . . . . . . . 58
17.3. CapwapBaseStationIdTC . . . . . . . . . . . . . . . . . 58
17.4. CapwapBaseRadioIdTC . . . . . . . . . . . . . . . . . . 58
17.5. CapwapBaseTunnelModeTC . . . . . . . . . . . . . . . . 58
17.6. CapwapBaseMacTypeTC . . . . . . . . . . . . . . . . . . 58
17.7. CapwapBaseChannelTypeTC . . . . . . . . . . . . . . . . 59
17.8. CapwapBaseAuthenMethodTC . . . . . . . . . . . . . . . 59
18. CAPWAP-DOT11-MIB (revision 2010-04-30 00:00) . . . . . . . . 59
18.1. CapwapDot11WlanIdTC . . . . . . . . . . . . . . . . . . 59
18.2. CapwapDot11WlanIdProfileTC . . . . . . . . . . . . . . 60
19. CHARACTER-MIB (revision 1994-05-26 17:00) . . . . . . . . . 60
19.1. PortIndex . . . . . . . . . . . . . . . . . . . . . . . 60
20. CIRCUIT-IF-MIB (revision 2002-01-03 00:00) . . . . . . . . . 60
20.1. CiFlowDirection . . . . . . . . . . . . . . . . . . . . 60
21. COPS-CLIENT-MIB (revision 2000-09-28 00:00) . . . . . . . . 60
21.1. CopsClientState . . . . . . . . . . . . . . . . . . . . 61
21.2. CopsServerEntryType . . . . . . . . . . . . . . . . . . 61
21.3. CopsErrorCode . . . . . . . . . . . . . . . . . . . . . 61
21.4. CopsTcpPort . . . . . . . . . . . . . . . . . . . . . . 61
21.5. CopsAuthType . . . . . . . . . . . . . . . . . . . . . 61
22. DIAL-CONTROL-MIB (revision 1996-09-23 15:44) . . . . . . . . 61
22.1. AbsoluteCounter32 . . . . . . . . . . . . . . . . . . . 61
23. DIFFSERV-DSCP-TC (revision 2002-05-09 00:00) . . . . . . . . 62
23.1. Dscp . . . . . . . . . . . . . . . . . . . . . . . . . 62
23.2. DscpOrAny . . . . . . . . . . . . . . . . . . . . . . . 62
24. DIFFSERV-MIB (revision 2002-02-07 00:00) . . . . . . . . . . 62
24.1. IndexInteger . . . . . . . . . . . . . . . . . . . . . 62
24.2. IndexIntegerNextFree . . . . . . . . . . . . . . . . . 62
24.3. IfDirection . . . . . . . . . . . . . . . . . . . . . . 63
25. DISMAN-EVENT-MIB (revision 2000-10-16 00:00) . . . . . . . . 63
25.1. FailureReason . . . . . . . . . . . . . . . . . . . . . 63
26. DISMAN-PING-MIB (revision 2006-06-13 00:00) . . . . . . . . 64
26.1. OperationResponseStatus . . . . . . . . . . . . . . . . 64
27. DISMAN-SCHEDULE-MIB (revision 2002-01-07 00:00) . . . . . . 65
Expires August 17, 2014 [Page 4]
Internet-Draft SMIv2 Textual Conventions February 2014
27.1. SnmpPduErrorStatus . . . . . . . . . . . . . . . . . . 65
28. DLSW-MIB (revision 1996-06-04 09:00) . . . . . . . . . . . . 65
28.1. NBName . . . . . . . . . . . . . . . . . . . . . . . . 66
28.2. MacAddressNC . . . . . . . . . . . . . . . . . . . . . 66
28.3. TAddress . . . . . . . . . . . . . . . . . . . . . . . 66
28.4. EndStationLocation . . . . . . . . . . . . . . . . . . 66
28.5. DlcType . . . . . . . . . . . . . . . . . . . . . . . . 66
28.6. LFSize . . . . . . . . . . . . . . . . . . . . . . . . 66
28.7. DlswTCPAddress . . . . . . . . . . . . . . . . . . . . 67
29. DNS-SERVER-MIB (revision 1994-01-28 22:51) . . . . . . . . . 67
29.1. DnsName . . . . . . . . . . . . . . . . . . . . . . . . 67
29.2. DnsNameAsIndex . . . . . . . . . . . . . . . . . . . . 67
29.3. DnsClass . . . . . . . . . . . . . . . . . . . . . . . 68
29.4. DnsType . . . . . . . . . . . . . . . . . . . . . . . . 68
29.5. DnsQClass . . . . . . . . . . . . . . . . . . . . . . . 68
29.6. DnsQType . . . . . . . . . . . . . . . . . . . . . . . 68
29.7. DnsTime . . . . . . . . . . . . . . . . . . . . . . . . 68
29.8. DnsOpCode . . . . . . . . . . . . . . . . . . . . . . . 68
29.9. DnsRespCode . . . . . . . . . . . . . . . . . . . . . . 69
30. DOCS-IETF-BPI2-MIB (revision 2005-07-20 00:00) . . . . . . . 69
30.1. DocsX509ASN1DEREncodedCertificate . . . . . . . . . . . 69
30.2. DocsSAId . . . . . . . . . . . . . . . . . . . . . . . 69
30.3. DocsSAIdOrZero . . . . . . . . . . . . . . . . . . . . 69
30.4. DocsBpkmSAType . . . . . . . . . . . . . . . . . . . . 69
30.5. DocsBpkmDataEncryptAlg . . . . . . . . . . . . . . . . 70
30.6. DocsBpkmDataAuthentAlg . . . . . . . . . . . . . . . . 70
31. DOCS-IETF-QOS-MIB (revision 2006-01-23 00:00) . . . . . . . 70
31.1. DocsIetfQosRfMacIfDirection . . . . . . . . . . . . . . 70
31.2. DocsIetfQosBitRate . . . . . . . . . . . . . . . . . . 71
31.3. DocsIetfQosSchedulingType . . . . . . . . . . . . . . . 71
32. DOCS-IF-MIB (revision 2006-05-24 00:00) . . . . . . . . . . 71
32.1. TenthdBmV . . . . . . . . . . . . . . . . . . . . . . . 71
32.2. TenthdB . . . . . . . . . . . . . . . . . . . . . . . . 71
32.3. DocsisVersion . . . . . . . . . . . . . . . . . . . . . 71
32.4. DocsisQosVersion . . . . . . . . . . . . . . . . . . . 72
32.5. DocsisUpstreamType . . . . . . . . . . . . . . . . . . 72
32.6. DocsEqualizerData . . . . . . . . . . . . . . . . . . . 72
33. DOT3-OAM-MIB (revision 2007-06-14 00:00) . . . . . . . . . . 73
33.1. EightOTwoOui . . . . . . . . . . . . . . . . . . . . . 74
34. DSMON-MIB (revision 2002-05-31 00:00) . . . . . . . . . . . 74
34.1. DsmonCounterAggGroupIndex . . . . . . . . . . . . . . . 75
34.2. DsmonCounterAggProfileIndex . . . . . . . . . . . . . . 75
35. DVB-RCS-MIB (revision 2010-02-16 12:00) . . . . . . . . . . 75
35.1. DvbRcsSatLabsProfileMap . . . . . . . . . . . . . . . . 75
35.2. DvbRcsSatLabsOptionMap . . . . . . . . . . . . . . . . 76
35.3. DvbRcsSatLabsFeatureMap . . . . . . . . . . . . . . . . 77
36. EBN-MIB (revision 1998-04-28 18:00) . . . . . . . . . . . . 77
36.1. SnaNAUWildcardName . . . . . . . . . . . . . . . . . . 77
Expires August 17, 2014 [Page 5]
Internet-Draft SMIv2 Textual Conventions February 2014
37. EFM-CU-MIB (revision 2007-11-14 00:00) . . . . . . . . . . . 77
37.1. EfmProfileIndex . . . . . . . . . . . . . . . . . . . . 78
37.2. EfmProfileIndexOrZero . . . . . . . . . . . . . . . . . 79
37.3. EfmProfileIndexList . . . . . . . . . . . . . . . . . . 79
37.4. EfmTruthValueOrUnknown . . . . . . . . . . . . . . . . 79
38. ENTITY-MIB (revision 2013-04-05 00:00) . . . . . . . . . . . 79
38.1. PhysicalIndex . . . . . . . . . . . . . . . . . . . . . 80
38.2. PhysicalIndexOrZero . . . . . . . . . . . . . . . . . . 80
38.3. SnmpEngineIdOrNone . . . . . . . . . . . . . . . . . . 80
38.4. PhysicalClass (deprecated) . . . . . . . . . . . . . . 81
39. ENTITY-SENSOR-MIB (revision 2002-12-16 00:00) . . . . . . . 82
39.1. EntitySensorDataType . . . . . . . . . . . . . . . . . 82
39.2. EntitySensorDataScale . . . . . . . . . . . . . . . . . 83
39.3. EntitySensorPrecision . . . . . . . . . . . . . . . . . 84
39.4. EntitySensorValue . . . . . . . . . . . . . . . . . . . 84
39.5. EntitySensorStatus . . . . . . . . . . . . . . . . . . 85
40. ENTITY-STATE-TC-MIB (revision 2005-11-22 00:00) . . . . . . 86
40.1. EntityAdminState . . . . . . . . . . . . . . . . . . . 86
40.2. EntityOperState . . . . . . . . . . . . . . . . . . . . 86
40.3. EntityUsageState . . . . . . . . . . . . . . . . . . . 87
40.4. EntityAlarmStatus . . . . . . . . . . . . . . . . . . . 87
40.5. EntityStandbyStatus . . . . . . . . . . . . . . . . . . 88
41. FCIP-MGMT-MIB (revision 2006-02-06 00:00) . . . . . . . . . 89
41.1. FcipDomainIdInOctetForm . . . . . . . . . . . . . . . . 89
41.2. FcipEntityMode . . . . . . . . . . . . . . . . . . . . 89
41.3. FcipEntityId . . . . . . . . . . . . . . . . . . . . . 89
42. FC-MGMT-MIB (revision 2005-04-26 00:00) . . . . . . . . . . 89
42.1. FcNameIdOrZero . . . . . . . . . . . . . . . . . . . . 89
42.2. FcAddressIdOrZero . . . . . . . . . . . . . . . . . . . 89
42.3. FcDomainIdOrZero . . . . . . . . . . . . . . . . . . . 90
42.4. FcPortType . . . . . . . . . . . . . . . . . . . . . . 90
42.5. FcClasses . . . . . . . . . . . . . . . . . . . . . . . 90
42.6. FcBbCredit . . . . . . . . . . . . . . . . . . . . . . 90
42.7. FcBbCreditModel . . . . . . . . . . . . . . . . . . . . 90
42.8. FcDataFieldSize . . . . . . . . . . . . . . . . . . . . 90
42.9. FcUnitFunctions . . . . . . . . . . . . . . . . . . . . 90
43. FIBRE-CHANNEL-FE-MIB (revision 2000-05-18 00:00) . . . . . . 91
43.1. MilliSeconds . . . . . . . . . . . . . . . . . . . . . 92
43.2. MicroSeconds . . . . . . . . . . . . . . . . . . . . . 92
43.3. FcNameId . . . . . . . . . . . . . . . . . . . . . . . 92
43.4. FcAddressId . . . . . . . . . . . . . . . . . . . . . . 92
43.5. FcRxDataFieldSize . . . . . . . . . . . . . . . . . . . 92
43.6. FcBbCredit . . . . . . . . . . . . . . . . . . . . . . 92
43.7. FcphVersion . . . . . . . . . . . . . . . . . . . . . . 92
43.8. FcStackedConnMode . . . . . . . . . . . . . . . . . . . 92
43.9. FcCosCap . . . . . . . . . . . . . . . . . . . . . . . 93
43.10. FcFeModuleCapacity . . . . . . . . . . . . . . . . . . 93
43.11. FcFeFxPortCapacity . . . . . . . . . . . . . . . . . . 93
Expires August 17, 2014 [Page 6]
Internet-Draft SMIv2 Textual Conventions February 2014
43.12. FcFeModuleIndex . . . . . . . . . . . . . . . . . . . . 93
43.13. FcFeFxPortIndex . . . . . . . . . . . . . . . . . . . . 93
43.14. FcFeNxPortIndex . . . . . . . . . . . . . . . . . . . . 93
43.15. FcBbCreditModel . . . . . . . . . . . . . . . . . . . . 93
44. FLOAT-TC-MIB (revision 2011-07-27 00:00) . . . . . . . . . . 93
44.1. Float32TC . . . . . . . . . . . . . . . . . . . . . . . 94
44.2. Float64TC . . . . . . . . . . . . . . . . . . . . . . . 94
44.3. Float128TC . . . . . . . . . . . . . . . . . . . . . . 94
45. FLOW-METER-MIB (revision 1999-10-25 00:00) . . . . . . . . . 94
45.1. UTF8OwnerString . . . . . . . . . . . . . . . . . . . . 94
45.2. PeerType . . . . . . . . . . . . . . . . . . . . . . . 94
45.3. PeerAddress . . . . . . . . . . . . . . . . . . . . . . 95
45.4. AdjacentType . . . . . . . . . . . . . . . . . . . . . 95
45.5. AdjacentAddress . . . . . . . . . . . . . . . . . . . . 95
45.6. TransportType . . . . . . . . . . . . . . . . . . . . . 96
45.7. TransportAddress . . . . . . . . . . . . . . . . . . . 96
45.8. RuleAddress . . . . . . . . . . . . . . . . . . . . . . 96
45.9. FlowAttributeNumber . . . . . . . . . . . . . . . . . . 96
45.10. RuleAttributeNumber . . . . . . . . . . . . . . . . . . 97
45.11. ActionNumber . . . . . . . . . . . . . . . . . . . . . 97
46. FORCES-MIB (revision 2010-03-10 00:00) . . . . . . . . . . . 97
46.1. ForcesID . . . . . . . . . . . . . . . . . . . . . . . 97
46.2. ForcesProtocolVersion . . . . . . . . . . . . . . . . . 97
47. FRAME-RELAY-DTE-MIB (revision 1997-05-01 02:29) . . . . . . 97
47.1. DLCI . . . . . . . . . . . . . . . . . . . . . . . . . 98
48. FR-MFR-MIB (revision 2000-11-30 00:00) . . . . . . . . . . . 98
48.1. MfrBundleLinkState . . . . . . . . . . . . . . . . . . 98
49. FRSLD-MIB (revision 2002-01-03 00:00) . . . . . . . . . . . 98
49.1. FrsldTxRP . . . . . . . . . . . . . . . . . . . . . . . 98
49.2. FrsldRxRP . . . . . . . . . . . . . . . . . . . . . . . 99
50. GMPLS-TC-STD-MIB (revision 2007-02-28 00:00) . . . . . . . . 99
50.1. GmplsFreeformLabelTC . . . . . . . . . . . . . . . . . 99
50.2. GmplsLabelTypeTC . . . . . . . . . . . . . . . . . . . 99
50.3. GmplsSegmentDirectionTC . . . . . . . . . . . . . . . . 100
51. GSMP-MIB (revision 2002-05-31 00:00) . . . . . . . . . . . . 101
51.1. GsmpNameType . . . . . . . . . . . . . . . . . . . . . 101
51.2. GsmpPartitionType . . . . . . . . . . . . . . . . . . . 101
51.3. GsmpPartitionIdType . . . . . . . . . . . . . . . . . . 101
51.4. GsmpVersion . . . . . . . . . . . . . . . . . . . . . . 101
51.5. GsmpLabelType . . . . . . . . . . . . . . . . . . . . . 101
52. HC-ALARM-MIB (revision 2002-12-16 00:00) . . . . . . . . . . 102
52.1. HcValueStatus . . . . . . . . . . . . . . . . . . . . . 102
53. HCNUM-TC (revision 2000-06-08 00:00) . . . . . . . . . . . . 103
53.1. CounterBasedGauge64 . . . . . . . . . . . . . . . . . . 103
53.2. ZeroBasedCounter64 . . . . . . . . . . . . . . . . . . 103
54. HC-PerfHist-TC-MIB (revision 2004-02-03 00:00) . . . . . . . 104
54.1. HCPerfValidIntervals . . . . . . . . . . . . . . . . . 104
54.2. HCPerfInvalidIntervals . . . . . . . . . . . . . . . . 105
Expires August 17, 2014 [Page 7]
Internet-Draft SMIv2 Textual Conventions February 2014
54.3. HCPerfTimeElapsed . . . . . . . . . . . . . . . . . . . 105
54.4. HCPerfIntervalThreshold . . . . . . . . . . . . . . . . 105
54.5. HCPerfCurrentCount . . . . . . . . . . . . . . . . . . 106
54.6. HCPerfIntervalCount . . . . . . . . . . . . . . . . . . 106
54.7. HCPerfTotalCount . . . . . . . . . . . . . . . . . . . 108
55. HDSL2-SHDSL-LINE-MIB (revision 2005-12-07 00:00) . . . . . . 108
55.1. Hdsl2ShdslPerfCurrDayCount . . . . . . . . . . . . . . 108
55.2. Hdsl2Shdsl1DayIntervalCount . . . . . . . . . . . . . . 109
55.3. Hdsl2ShdslPerfTimeElapsed . . . . . . . . . . . . . . . 109
55.4. Hdsl2ShdslPerfIntervalThreshold . . . . . . . . . . . . 110
55.5. Hdsl2ShdslUnitId . . . . . . . . . . . . . . . . . . . 110
55.6. Hdsl2ShdslUnitSide . . . . . . . . . . . . . . . . . . 110
55.7. Hdsl2ShdslWirePair . . . . . . . . . . . . . . . . . . 110
55.8. Hdsl2ShdslTransmissionModeType . . . . . . . . . . . . 110
55.9. Hdsl2ShdslClockReferenceType . . . . . . . . . . . . . 111
56. HOST-RESOURCES-MIB (revision 2000-03-06 00:00) . . . . . . . 111
56.1. KBytes . . . . . . . . . . . . . . . . . . . . . . . . 111
56.2. ProductID . . . . . . . . . . . . . . . . . . . . . . . 111
56.3. InternationalDisplayString . . . . . . . . . . . . . . 112
57. HPR-IP-MIB (revision 1998-09-24 00:00) . . . . . . . . . . . 112
57.1. AppnTrafficType . . . . . . . . . . . . . . . . . . . . 112
57.2. AppnTOSPrecedence . . . . . . . . . . . . . . . . . . . 112
58. HPR-MIB (revision 1997-05-14 00:00) . . . . . . . . . . . . 113
58.1. HprNceTypes . . . . . . . . . . . . . . . . . . . . . . 113
58.2. HprRtpCounter . . . . . . . . . . . . . . . . . . . . . 113
59. IANA-ITU-ALARM-TC-MIB (revision 2004-09-09 00:00) . . . . . 113
59.1. IANAItuProbableCause . . . . . . . . . . . . . . . . . 114
59.2. IANAItuEventType . . . . . . . . . . . . . . . . . . . 114
60. IFCP-MGMT-MIB (revision 2011-03-09 00:00) . . . . . . . . . 115
60.1. IfcpIpTOVorZero . . . . . . . . . . . . . . . . . . . . 115
60.2. IfcpLTIorZero . . . . . . . . . . . . . . . . . . . . . 115
60.3. IfcpSessionStates . . . . . . . . . . . . . . . . . . . 115
60.4. IfcpAddressMode . . . . . . . . . . . . . . . . . . . . 116
61. IF-MIB (revision 2000-06-14 00:00) . . . . . . . . . . . . . 116
61.1. OwnerString (deprecated) . . . . . . . . . . . . . . . 116
61.2. InterfaceIndex . . . . . . . . . . . . . . . . . . . . 116
61.3. InterfaceIndexOrZero . . . . . . . . . . . . . . . . . 116
62. INET-ADDRESS-MIB (revision 2005-02-04 00:00) . . . . . . . . 117
62.1. InetAddressType . . . . . . . . . . . . . . . . . . . . 117
62.2. InetAddress . . . . . . . . . . . . . . . . . . . . . . 119
62.3. InetAddressIPv4 . . . . . . . . . . . . . . . . . . . . 119
62.4. InetAddressIPv6 . . . . . . . . . . . . . . . . . . . . 120
62.5. InetAddressIPv4z . . . . . . . . . . . . . . . . . . . 120
62.6. InetAddressIPv6z . . . . . . . . . . . . . . . . . . . 120
62.7. InetAddressDNS . . . . . . . . . . . . . . . . . . . . 121
62.8. InetAddressPrefixLength . . . . . . . . . . . . . . . . 122
62.9. InetPortNumber . . . . . . . . . . . . . . . . . . . . 122
62.10. InetAutonomousSystemNumber . . . . . . . . . . . . . . 123
Expires August 17, 2014 [Page 8]
Internet-Draft SMIv2 Textual Conventions February 2014
62.11. InetScopeType . . . . . . . . . . . . . . . . . . . . . 123
62.12. InetZoneIndex . . . . . . . . . . . . . . . . . . . . . 124
62.13. InetVersion . . . . . . . . . . . . . . . . . . . . . . 124
63. INTEGRATED-SERVICES-MIB (revision 1995-11-03 05:00) . . . . 124
63.1. SessionNumber . . . . . . . . . . . . . . . . . . . . . 124
63.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . 125
63.3. SessionType . . . . . . . . . . . . . . . . . . . . . . 125
63.4. Port . . . . . . . . . . . . . . . . . . . . . . . . . 125
63.5. MessageSize . . . . . . . . . . . . . . . . . . . . . . 126
63.6. BitRate . . . . . . . . . . . . . . . . . . . . . . . . 126
63.7. BurstSize . . . . . . . . . . . . . . . . . . . . . . . 126
63.8. QosService . . . . . . . . . . . . . . . . . . . . . . 126
64. IP-MIB (revision 2006-02-02 00:00) . . . . . . . . . . . . . 126
64.1. IpAddressOriginTC . . . . . . . . . . . . . . . . . . . 126
64.2. IpAddressStatusTC . . . . . . . . . . . . . . . . . . . 127
64.3. IpAddressPrefixOriginTC . . . . . . . . . . . . . . . . 128
64.4. Ipv6AddressIfIdentifierTC . . . . . . . . . . . . . . . 129
65. IPMROUTE-STD-MIB (revision 2000-09-22 00:00) . . . . . . . . 129
65.1. LanguageTag . . . . . . . . . . . . . . . . . . . . . . 129
66. IPOA-MIB (revision 1998-02-09 00:00) . . . . . . . . . . . . 130
66.1. IpoaEncapsType . . . . . . . . . . . . . . . . . . . . 130
66.2. IpoaVpiInteger . . . . . . . . . . . . . . . . . . . . 130
66.3. IpoaVciInteger . . . . . . . . . . . . . . . . . . . . 130
66.4. IpoaAtmAddr . . . . . . . . . . . . . . . . . . . . . . 130
66.5. IpoaAtmConnKind . . . . . . . . . . . . . . . . . . . . 130
67. IPS-AUTH-MIB (revision 2006-05-22 00:00) . . . . . . . . . . 131
67.1. IpsAuthAddress . . . . . . . . . . . . . . . . . . . . 131
68. IPSEC-SPD-MIB (revision 2007-02-07 00:00) . . . . . . . . . 132
68.1. SpdBooleanOperator . . . . . . . . . . . . . . . . . . 133
68.2. SpdAdminStatus . . . . . . . . . . . . . . . . . . . . 133
68.3. SpdIPPacketLogging . . . . . . . . . . . . . . . . . . 133
68.4. SpdTimePeriod . . . . . . . . . . . . . . . . . . . . . 133
69. IPV6-FLOW-LABEL-MIB (revision 2003-08-28 00:00) . . . . . . 135
69.1. IPv6FlowLabel . . . . . . . . . . . . . . . . . . . . . 135
69.2. IPv6FlowLabelOrAny . . . . . . . . . . . . . . . . . . 135
70. IPV6-TC . . . . . . . . . . . . . . . . . . . . . . . . . . 135
70.1. Ipv6Address . . . . . . . . . . . . . . . . . . . . . . 135
70.2. Ipv6AddressPrefix . . . . . . . . . . . . . . . . . . . 135
70.3. Ipv6AddressIfIdentifier . . . . . . . . . . . . . . . . 135
70.4. Ipv6IfIndex . . . . . . . . . . . . . . . . . . . . . . 136
70.5. Ipv6IfIndexOrZero . . . . . . . . . . . . . . . . . . . 136
71. ISCSI-MIB (revision 2006-05-22 00:00) . . . . . . . . . . . 136
71.1. IscsiTransportProtocol . . . . . . . . . . . . . . . . 136
71.2. IscsiDigestMethod . . . . . . . . . . . . . . . . . . . 136
71.3. IscsiName . . . . . . . . . . . . . . . . . . . . . . . 137
72. ISDN-MIB (revision 1996-09-23 16:42) . . . . . . . . . . . . 137
72.1. IsdnSignalingProtocol . . . . . . . . . . . . . . . . . 137
73. ISIS-MIB (revision 2006-04-04 00:00) . . . . . . . . . . . . 137
Expires August 17, 2014 [Page 9]
Internet-Draft SMIv2 Textual Conventions February 2014
73.1. IsisOSINSAddress . . . . . . . . . . . . . . . . . . . 138
73.2. IsisSystemID . . . . . . . . . . . . . . . . . . . . . 138
73.3. IsisLinkStatePDUID . . . . . . . . . . . . . . . . . . 138
73.4. IsisAdminState . . . . . . . . . . . . . . . . . . . . 138
73.5. IsisLSPBuffSize . . . . . . . . . . . . . . . . . . . . 138
73.6. IsisLevelState . . . . . . . . . . . . . . . . . . . . 139
73.7. IsisSupportedProtocol . . . . . . . . . . . . . . . . . 139
73.8. IsisDefaultMetric . . . . . . . . . . . . . . . . . . . 139
73.9. IsisWideMetric . . . . . . . . . . . . . . . . . . . . 139
73.10. IsisFullMetric . . . . . . . . . . . . . . . . . . . . 139
73.11. IsisMetricType . . . . . . . . . . . . . . . . . . . . 139
73.12. IsisMetricStyle . . . . . . . . . . . . . . . . . . . . 139
73.13. IsisISLevel . . . . . . . . . . . . . . . . . . . . . . 139
73.14. IsisLevel . . . . . . . . . . . . . . . . . . . . . . . 140
73.15. IsisPDUHeader . . . . . . . . . . . . . . . . . . . . . 140
73.16. IsisCircuitID . . . . . . . . . . . . . . . . . . . . . 140
73.17. IsisISPriority . . . . . . . . . . . . . . . . . . . . 140
73.18. IsisUnsigned16TC . . . . . . . . . . . . . . . . . . . 140
73.19. IsisUnsigned8TC . . . . . . . . . . . . . . . . . . . . 140
74. ISNS-MIB (revision 2007-07-11 00:00) . . . . . . . . . . . . 140
74.1. IsnsDiscoveryDomainSetId . . . . . . . . . . . . . . . 140
74.2. IsnsDdsStatusType . . . . . . . . . . . . . . . . . . . 141
74.3. IsnsDiscoveryDomainId . . . . . . . . . . . . . . . . . 141
74.4. IsnsDdFeatureType . . . . . . . . . . . . . . . . . . . 141
74.5. IsnsDdDdsModificationType . . . . . . . . . . . . . . . 141
74.6. IsnsEntityIndexIdOrZero . . . . . . . . . . . . . . . . 142
74.7. IsnsPortalGroupIndexId . . . . . . . . . . . . . . . . 142
74.8. IsnsPortalIndexId . . . . . . . . . . . . . . . . . . . 142
74.9. IsnsPortalPortTypeId . . . . . . . . . . . . . . . . . 143
74.10. IsnsPortalGroupTagIdOrNull . . . . . . . . . . . . . . 143
74.11. IsnsPortalSecurityType . . . . . . . . . . . . . . . . 143
74.12. IsnsNodeIndexId . . . . . . . . . . . . . . . . . . . . 144
74.13. IsnsIscsiNodeType . . . . . . . . . . . . . . . . . . . 144
74.14. IsnsFcClassOfServiceType . . . . . . . . . . . . . . . 145
74.15. IsnsIscsiScnType . . . . . . . . . . . . . . . . . . . 145
74.16. IsnsIfcpScnType . . . . . . . . . . . . . . . . . . . . 146
74.17. IsnsFcPortRoleType . . . . . . . . . . . . . . . . . . 146
74.18. IsnsSrvrDiscoveryMethodsType . . . . . . . . . . . . . 147
75. ITU-ALARM-TC-MIB (revision 2004-09-09 00:00) . . . . . . . . 147
75.1. ItuPerceivedSeverity . . . . . . . . . . . . . . . . . 147
75.2. ItuTrendIndication . . . . . . . . . . . . . . . . . . 147
76. Job-Monitoring-MIB (revision 1999-02-19 00:00) . . . . . . . 148
76.1. JmUTF8StringTC . . . . . . . . . . . . . . . . . . . . 148
76.2. JmJobStringTC . . . . . . . . . . . . . . . . . . . . . 148
76.3. JmNaturalLanguageTagTC . . . . . . . . . . . . . . . . 148
76.4. JmTimeStampTC . . . . . . . . . . . . . . . . . . . . . 148
76.5. JmJobSourcePlatformTypeTC . . . . . . . . . . . . . . . 149
76.6. JmFinishingTC . . . . . . . . . . . . . . . . . . . . . 149
Expires August 17, 2014 [Page 10]
Internet-Draft SMIv2 Textual Conventions February 2014
76.7. JmPrintQualityTC . . . . . . . . . . . . . . . . . . . 150
76.8. JmPrinterResolutionTC . . . . . . . . . . . . . . . . . 151
76.9. JmTonerEconomyTC . . . . . . . . . . . . . . . . . . . 151
76.10. JmBooleanTC . . . . . . . . . . . . . . . . . . . . . . 151
76.11. JmMediumTypeTC . . . . . . . . . . . . . . . . . . . . 151
76.12. JmJobCollationTypeTC . . . . . . . . . . . . . . . . . 152
76.13. JmJobSubmissionIDTypeTC . . . . . . . . . . . . . . . . 153
76.14. JmJobStateTC . . . . . . . . . . . . . . . . . . . . . 153
76.15. JmAttributeTypeTC . . . . . . . . . . . . . . . . . . . 156
76.16. JmJobServiceTypesTC . . . . . . . . . . . . . . . . . . 156
76.17. JmJobStateReasons1TC . . . . . . . . . . . . . . . . . 158
76.18. JmJobStateReasons2TC . . . . . . . . . . . . . . . . . 158
76.19. JmJobStateReasons3TC . . . . . . . . . . . . . . . . . 158
76.20. JmJobStateReasons4TC . . . . . . . . . . . . . . . . . 159
77. L2TP-MIB (revision 2002-08-23 00:00) . . . . . . . . . . . . 159
77.1. L2tpMilliSeconds . . . . . . . . . . . . . . . . . . . 159
78. LANGTAG-TC-MIB (revision 2007-11-09 00:00) . . . . . . . . . 159
78.1. LangTag . . . . . . . . . . . . . . . . . . . . . . . . 159
79. LISP-MIB (revision 2013-10-21 00:00) . . . . . . . . . . . . 160
79.1. LispAddressType . . . . . . . . . . . . . . . . . . . . 160
80. LMP-MIB (revision 2006-08-14 00:00) . . . . . . . . . . . . 163
80.1. LmpInterval . . . . . . . . . . . . . . . . . . . . . . 163
80.2. LmpRetransmitInterval . . . . . . . . . . . . . . . . . 163
80.3. LmpNodeId . . . . . . . . . . . . . . . . . . . . . . . 163
81. MAU-MIB (revision 2007-04-21 00:00) . . . . . . . . . . . . 163
81.1. JackType (deprecated) . . . . . . . . . . . . . . . . . 164
82. MIDCOM-MIB (revision 2007-08-09 10:11) . . . . . . . . . . . 164
82.1. MidcomNatBindMode . . . . . . . . . . . . . . . . . . . 164
82.2. MidcomNatSessionIdOrZero . . . . . . . . . . . . . . . 165
83. MIP-MIB (revision 1996-06-04 00:00) . . . . . . . . . . . . 165
83.1. RegistrationFlags . . . . . . . . . . . . . . . . . . . 165
84. MOBILEIPV6-MIB (revision 2006-02-01 00:00) . . . . . . . . . 165
84.1. Mip6BURequestRejectionCode . . . . . . . . . . . . . . 165
85. MPLS-FTN-STD-MIB (revision 2004-06-03 00:00) . . . . . . . . 166
85.1. MplsFTNEntryIndex . . . . . . . . . . . . . . . . . . . 166
85.2. MplsFTNEntryIndexOrZero . . . . . . . . . . . . . . . . 166
86. MPLS-L3VPN-STD-MIB (revision 2006-01-23 00:00) . . . . . . . 166
86.1. MplsL3VpnName . . . . . . . . . . . . . . . . . . . . . 166
86.2. MplsL3VpnRouteDistinguisher . . . . . . . . . . . . . . 167
86.3. MplsL3VpnRtType . . . . . . . . . . . . . . . . . . . . 167
87. MPLS-LSR-STD-MIB (revision 2004-06-03 00:00) . . . . . . . . 167
87.1. MplsIndexType . . . . . . . . . . . . . . . . . . . . . 167
87.2. MplsIndexNextType . . . . . . . . . . . . . . . . . . . 168
88. MPLS-TC-STD-MIB (revision 2004-06-03 00:00) . . . . . . . . 169
88.1. MplsAtmVcIdentifier . . . . . . . . . . . . . . . . . . 169
88.2. MplsBitRate . . . . . . . . . . . . . . . . . . . . . . 170
88.3. MplsBurstSize . . . . . . . . . . . . . . . . . . . . . 170
88.4. MplsExtendedTunnelId . . . . . . . . . . . . . . . . . 171
Expires August 17, 2014 [Page 11]
Internet-Draft SMIv2 Textual Conventions February 2014
88.5. MplsLabel . . . . . . . . . . . . . . . . . . . . . . . 171
88.6. MplsLabelDistributionMethod . . . . . . . . . . . . . . 173
88.7. MplsLdpIdentifier . . . . . . . . . . . . . . . . . . . 173
88.8. MplsLsrIdentifier . . . . . . . . . . . . . . . . . . . 173
88.9. MplsLdpLabelType . . . . . . . . . . . . . . . . . . . 173
88.10. MplsLSPID . . . . . . . . . . . . . . . . . . . . . . . 173
88.11. MplsLspType . . . . . . . . . . . . . . . . . . . . . . 174
88.12. MplsOwner . . . . . . . . . . . . . . . . . . . . . . . 175
88.13. MplsPathIndexOrZero . . . . . . . . . . . . . . . . . . 176
88.14. MplsPathIndex . . . . . . . . . . . . . . . . . . . . . 176
88.15. MplsRetentionMode . . . . . . . . . . . . . . . . . . . 177
88.16. MplsTunnelAffinity . . . . . . . . . . . . . . . . . . 177
88.17. MplsTunnelIndex . . . . . . . . . . . . . . . . . . . . 177
88.18. MplsTunnelInstanceIndex . . . . . . . . . . . . . . . . 177
88.19. TeHopAddressType . . . . . . . . . . . . . . . . . . . 178
88.20. TeHopAddress . . . . . . . . . . . . . . . . . . . . . 179
88.21. TeHopAddressAS . . . . . . . . . . . . . . . . . . . . 180
88.22. TeHopAddressUnnum . . . . . . . . . . . . . . . . . . . 181
89. NAT-MIB (revision 2005-03-21 00:00) . . . . . . . . . . . . 181
89.1. NatProtocolType . . . . . . . . . . . . . . . . . . . . 181
89.2. NatProtocolMap . . . . . . . . . . . . . . . . . . . . 181
89.3. NatAddrMapId . . . . . . . . . . . . . . . . . . . . . 181
89.4. NatBindIdOrZero . . . . . . . . . . . . . . . . . . . . 182
89.5. NatBindId . . . . . . . . . . . . . . . . . . . . . . . 182
89.6. NatSessionId . . . . . . . . . . . . . . . . . . . . . 182
89.7. NatBindMode . . . . . . . . . . . . . . . . . . . . . . 182
89.8. NatAssociationType . . . . . . . . . . . . . . . . . . 182
89.9. NatTranslationEntity . . . . . . . . . . . . . . . . . 182
90. NETWORK-SERVICES-MIB (revision 2000-03-03 00:00) . . . . . . 182
90.1. DistinguishedName . . . . . . . . . . . . . . . . . . . 183
90.2. URLString . . . . . . . . . . . . . . . . . . . . . . . 183
91. NHDP-MIB (revision 2012-10-22 10:00) . . . . . . . . . . . . 183
91.1. NeighborIfIndex . . . . . . . . . . . . . . . . . . . . 183
91.2. NeighborRouterIndex . . . . . . . . . . . . . . . . . . 184
92. NHRP-MIB (revision 1999-08-26 00:00) . . . . . . . . . . . . 185
92.1. NhrpGenAddr . . . . . . . . . . . . . . . . . . . . . . 185
93. NTPv4-MIB (revision 2010-05-17 00:00) . . . . . . . . . . . 185
93.1. NtpStratum . . . . . . . . . . . . . . . . . . . . . . 186
93.2. NtpDateTime . . . . . . . . . . . . . . . . . . . . . . 186
94. OPT-IF-MIB (revision 2003-08-13 00:00) . . . . . . . . . . . 186
94.1. OptIfAcTI . . . . . . . . . . . . . . . . . . . . . . . 186
94.2. OptIfBitRateK . . . . . . . . . . . . . . . . . . . . . 186
94.3. OptIfDEGM . . . . . . . . . . . . . . . . . . . . . . . 187
94.4. OptIfDEGThr . . . . . . . . . . . . . . . . . . . . . . 187
94.5. OptIfDirectionality . . . . . . . . . . . . . . . . . . 187
94.6. OptIfSinkOrSource . . . . . . . . . . . . . . . . . . . 187
94.7. OptIfExDAPI . . . . . . . . . . . . . . . . . . . . . . 187
94.8. OptIfExSAPI . . . . . . . . . . . . . . . . . . . . . . 187
Expires August 17, 2014 [Page 12]
Internet-Draft SMIv2 Textual Conventions February 2014
94.9. OptIfIntervalNumber . . . . . . . . . . . . . . . . . . 187
94.10. OptIfTIMDetMode . . . . . . . . . . . . . . . . . . . . 188
94.11. OptIfTxTI . . . . . . . . . . . . . . . . . . . . . . . 188
95. OSPF-MIB (revision 2006-11-10 00:00) . . . . . . . . . . . . 188
95.1. AreaID . . . . . . . . . . . . . . . . . . . . . . . . 188
95.2. RouterID . . . . . . . . . . . . . . . . . . . . . . . 188
95.3. Metric . . . . . . . . . . . . . . . . . . . . . . . . 188
95.4. BigMetric . . . . . . . . . . . . . . . . . . . . . . . 189
95.5. Status . . . . . . . . . . . . . . . . . . . . . . . . 189
95.6. PositiveInteger . . . . . . . . . . . . . . . . . . . . 189
95.7. HelloRange . . . . . . . . . . . . . . . . . . . . . . 189
95.8. UpToMaxAge . . . . . . . . . . . . . . . . . . . . . . 189
95.9. DesignatedRouterPriority . . . . . . . . . . . . . . . 189
95.10. TOSType . . . . . . . . . . . . . . . . . . . . . . . . 189
95.11. OspfAuthenticationType . . . . . . . . . . . . . . . . 190
96. OSPFV3-MIB (revision 2009-08-13 00:00) . . . . . . . . . . . 190
96.1. Ospfv3UpToRefreshIntervalTC . . . . . . . . . . . . . . 191
96.2. Ospfv3DeadIntervalRangeTC . . . . . . . . . . . . . . . 191
96.3. Ospfv3RouterIdTC . . . . . . . . . . . . . . . . . . . 191
96.4. Ospfv3LsIdTC . . . . . . . . . . . . . . . . . . . . . 191
96.5. Ospfv3AreaIdTC . . . . . . . . . . . . . . . . . . . . 191
96.6. Ospfv3IfInstIdTC . . . . . . . . . . . . . . . . . . . 192
96.7. Ospfv3LsaSequenceTC . . . . . . . . . . . . . . . . . . 192
96.8. Ospfv3LsaAgeTC . . . . . . . . . . . . . . . . . . . . 192
97. P-BRIDGE-MIB (revision 2006-01-09 00:00) . . . . . . . . . . 192
97.1. EnabledStatus . . . . . . . . . . . . . . . . . . . . . 192
98. PerfHist-TC-MIB (revision 2003-08-13 00:00) . . . . . . . . 192
98.1. PerfCurrentCount . . . . . . . . . . . . . . . . . . . 193
98.2. PerfIntervalCount . . . . . . . . . . . . . . . . . . . 193
98.3. PerfTotalCount . . . . . . . . . . . . . . . . . . . . 194
99. PIM-STD-MIB (revision 2007-11-02 00:00) . . . . . . . . . . 194
99.1. PimMode . . . . . . . . . . . . . . . . . . . . . . . . 194
99.2. PimGroupMappingOriginType . . . . . . . . . . . . . . . 195
100. PINT-MIB (revision 2001-02-01 00:00) . . . . . . . . . . . . 195
100.1. PintServiceType . . . . . . . . . . . . . . . . . . . . 195
100.2. PintPerfStatPeriod . . . . . . . . . . . . . . . . . . 196
101. PKTC-IETF-MTA-MIB (revision 2006-09-18 00:00) . . . . . . . 196
101.1. PktcMtaDevProvEncryptAlg . . . . . . . . . . . . . . . 196
102. PKTC-IETF-SIG-MIB (revision 2007-12-18 00:00) . . . . . . . 196
102.1. TenthdBm . . . . . . . . . . . . . . . . . . . . . . . 197
102.2. PktcCodecType . . . . . . . . . . . . . . . . . . . . . 197
102.3. PktcRingCadence . . . . . . . . . . . . . . . . . . . . 198
102.4. PktcSigType . . . . . . . . . . . . . . . . . . . . . . 199
102.5. DtmfCode . . . . . . . . . . . . . . . . . . . . . . . 199
102.6. PktcSubscriberSideSigProtocol . . . . . . . . . . . . . 200
103. PMIPV6-TC-MIB (revision 2012-05-07 00:00) . . . . . . . . . 200
103.1. Pmip6TimeStamp64 . . . . . . . . . . . . . . . . . . . 200
103.2. Pmip6MnIdentifier . . . . . . . . . . . . . . . . . . . 200
Expires August 17, 2014 [Page 13]
Internet-Draft SMIv2 Textual Conventions February 2014
103.3. Pmip6MnLLIdentifier . . . . . . . . . . . . . . . . . . 201
103.4. Pmip6MnIndex . . . . . . . . . . . . . . . . . . . . . 201
103.5. Pmip6MnLLIndex . . . . . . . . . . . . . . . . . . . . 201
103.6. Pmip6MnInterfaceATT . . . . . . . . . . . . . . . . . . 201
104. POLICY-BASED-MANAGEMENT-MIB (revision 2005-02-07 00:00) . . 202
104.1. PmUTF8String . . . . . . . . . . . . . . . . . . . . . 202
105. Printer-MIB (revision 2004-06-02 00:00) . . . . . . . . . . 203
105.1. PrtMediaUnitTC . . . . . . . . . . . . . . . . . . . . 203
105.2. MediaUnit (deprecated) . . . . . . . . . . . . . . . . 204
105.3. PrtCapacityUnitTC . . . . . . . . . . . . . . . . . . . 204
105.4. CapacityUnit (deprecated) . . . . . . . . . . . . . . . 204
105.5. PrtPrintOrientationTC . . . . . . . . . . . . . . . . . 204
105.6. PrtSubUnitStatusTC . . . . . . . . . . . . . . . . . . 204
105.7. SubUnitStatus (deprecated) . . . . . . . . . . . . . . 205
105.8. PresentOnOff . . . . . . . . . . . . . . . . . . . . . 206
105.9. PrtLocalizedDescriptionStringTC . . . . . . . . . . . . 206
105.10. PrtConsoleDescriptionStringTC . . . . . . . . . . . . . 207
105.11. CodedCharSet (deprecated) . . . . . . . . . . . . . . . 207
105.12. PrtChannelStateTC . . . . . . . . . . . . . . . . . . . 207
105.13. PrtOutputStackingOrderTC . . . . . . . . . . . . . . . 207
105.14. PrtOutputPageDeliveryOrientationTC . . . . . . . . . . 207
105.15. PrtMarkerCounterUnitTC . . . . . . . . . . . . . . . . 207
105.16. PrtMarkerSuppliesSupplyUnitTC . . . . . . . . . . . . . 208
105.17. PrtMarkerSuppliesClassTC . . . . . . . . . . . . . . . 208
105.18. PrtMarkerColorantRoleTC . . . . . . . . . . . . . . . . 208
105.19. PrtMarkerAddressabilityUnitTC . . . . . . . . . . . . . 208
105.20. PrtMediaPathMaxSpeedPrintUnitTC . . . . . . . . . . . . 208
105.21. PrtInterpreterTwoWayTC . . . . . . . . . . . . . . . . 208
105.22. PrtAlertSeverityLevelTC . . . . . . . . . . . . . . . . 208
106. PTOPO-MIB (revision 2000-09-21 00:00) . . . . . . . . . . . 208
106.1. PtopoGenAddr . . . . . . . . . . . . . . . . . . . . . 209
106.2. PtopoChassisIdType . . . . . . . . . . . . . . . . . . 209
106.3. PtopoChassisId . . . . . . . . . . . . . . . . . . . . 209
106.4. PtopoPortIdType . . . . . . . . . . . . . . . . . . . . 210
106.5. PtopoPortId . . . . . . . . . . . . . . . . . . . . . . 211
106.6. PtopoAddrSeenState . . . . . . . . . . . . . . . . . . 212
107. PW-CEP-STD-MIB (revision 2011-05-16 00:00) . . . . . . . . . 213
107.1. PwCepSonetEbm . . . . . . . . . . . . . . . . . . . . . 213
107.2. PwCepSdhVc4Ebm . . . . . . . . . . . . . . . . . . . . 214
107.3. PwCepSonetVtgMap . . . . . . . . . . . . . . . . . . . 214
107.4. PwCepFracAsyncMap . . . . . . . . . . . . . . . . . . . 214
108. PW-TC-STD-MIB (revision 2009-04-21 00:00) . . . . . . . . . 214
108.1. PwGroupID . . . . . . . . . . . . . . . . . . . . . . . 215
108.2. PwIDType . . . . . . . . . . . . . . . . . . . . . . . 215
108.3. PwIndexType . . . . . . . . . . . . . . . . . . . . . . 215
108.4. PwIndexOrZeroType . . . . . . . . . . . . . . . . . . . 215
108.5. PwOperStatusTC . . . . . . . . . . . . . . . . . . . . 216
108.6. PwAttachmentIdentifierType . . . . . . . . . . . . . . 216
Expires August 17, 2014 [Page 14]
Internet-Draft SMIv2 Textual Conventions February 2014
108.7. PwGenIdType . . . . . . . . . . . . . . . . . . . . . . 216
108.8. PwCwStatusTC . . . . . . . . . . . . . . . . . . . . . 216
108.9. PwStatus . . . . . . . . . . . . . . . . . . . . . . . 217
108.10. PwFragSize . . . . . . . . . . . . . . . . . . . . . . 217
108.11. PwFragStatus . . . . . . . . . . . . . . . . . . . . . 218
108.12. PwCfgIndexOrzero . . . . . . . . . . . . . . . . . . . 218
109. PW-TDM-MIB (revision 2009-06-15 00:00) . . . . . . . . . . . 218
109.1. PwTDMCfgIndex . . . . . . . . . . . . . . . . . . . . . 219
110. Q-BRIDGE-MIB (revision 2006-01-09 00:00) . . . . . . . . . . 219
110.1. PortList . . . . . . . . . . . . . . . . . . . . . . . 219
110.2. VlanIndex . . . . . . . . . . . . . . . . . . . . . . . 220
110.3. VlanId . . . . . . . . . . . . . . . . . . . . . . . . 220
110.4. VlanIdOrAny . . . . . . . . . . . . . . . . . . . . . . 220
110.5. VlanIdOrNone . . . . . . . . . . . . . . . . . . . . . 221
110.6. VlanIdOrAnyOrNone . . . . . . . . . . . . . . . . . . . 221
111. RBRIDGE-MIB (revision 2013-01-07 00:00) . . . . . . . . . . 221
111.1. RbridgeAddress . . . . . . . . . . . . . . . . . . . . 221
111.2. RbridgeNickname . . . . . . . . . . . . . . . . . . . . 221
112. RIPv2-MIB (revision 1994-07-27 22:53) . . . . . . . . . . . 222
112.1. RouteTag . . . . . . . . . . . . . . . . . . . . . . . 222
113. RMON2-MIB (revision 2006-05-02 00:00) . . . . . . . . . . . 222
113.1. ZeroBasedCounter32 . . . . . . . . . . . . . . . . . . 222
113.2. LastCreateTime . . . . . . . . . . . . . . . . . . . . 222
113.3. TimeFilter . . . . . . . . . . . . . . . . . . . . . . 223
113.4. DataSource . . . . . . . . . . . . . . . . . . . . . . 227
113.5. ControlString . . . . . . . . . . . . . . . . . . . . . 228
114. RMON-MIB (revision 2000-05-11 00:00) . . . . . . . . . . . . 229
114.1. OwnerString . . . . . . . . . . . . . . . . . . . . . . 229
114.2. EntryStatus . . . . . . . . . . . . . . . . . . . . . . 230
115. ROHC-MIB (revision 2004-06-03 00:00) . . . . . . . . . . . . 232
115.1. RohcChannelIdentifier . . . . . . . . . . . . . . . . . 232
115.2. RohcChannelIdentifierOrZero . . . . . . . . . . . . . . 232
115.3. RohcCompressionRatio . . . . . . . . . . . . . . . . . 232
116. RPKI-ROUTER-MIB (revision 2013-05-01 00:00) . . . . . . . . 233
116.1. RpkiRtrConnectionType . . . . . . . . . . . . . . . . . 233
117. RSERPOOL-MIB (revision 2009-04-07 00:00) . . . . . . . . . . 233
117.1. RSerPoolENRPServerIdentifierTC . . . . . . . . . . . . 234
117.2. RSerPoolOperationScopeTC . . . . . . . . . . . . . . . 234
117.3. RSerPoolPoolHandleTC . . . . . . . . . . . . . . . . . 234
117.4. RserpoolPoolElementIdentifierTC . . . . . . . . . . . . 234
117.5. RSerPoolPolicyIdentifierTC . . . . . . . . . . . . . . 234
117.6. RSerPoolPolicyLoadTC . . . . . . . . . . . . . . . . . 234
117.7. RSerPoolPolicyWeightTC . . . . . . . . . . . . . . . . 234
117.8. RSerPoolTransportUseTypeTC . . . . . . . . . . . . . . 235
117.9. RSerPoolOpaqueAddressTC . . . . . . . . . . . . . . . . 235
118. RSVP-MIB (revision 1995-11-03 05:00) . . . . . . . . . . . . 235
118.1. RsvpEncapsulation . . . . . . . . . . . . . . . . . . . 235
118.2. RefreshInterval . . . . . . . . . . . . . . . . . . . . 235
Expires August 17, 2014 [Page 15]
Internet-Draft SMIv2 Textual Conventions February 2014
119. SCSI-MIB (revision 2006-03-30 00:00) . . . . . . . . . . . . 235
119.1. ScsiLUN . . . . . . . . . . . . . . . . . . . . . . . . 235
119.2. ScsiIndexValue . . . . . . . . . . . . . . . . . . . . 235
119.3. ScsiPortIndexValueOrZero . . . . . . . . . . . . . . . 236
119.4. ScsiIndexValueOrZero . . . . . . . . . . . . . . . . . 236
119.5. ScsiIdentifier . . . . . . . . . . . . . . . . . . . . 236
119.6. ScsiName . . . . . . . . . . . . . . . . . . . . . . . 236
119.7. ScsiLuNameOrZero . . . . . . . . . . . . . . . . . . . 237
119.8. ScsiDeviceOrPort . . . . . . . . . . . . . . . . . . . 237
119.9. ScsiIdCodeSet . . . . . . . . . . . . . . . . . . . . . 237
119.10. ScsiIdAssociation . . . . . . . . . . . . . . . . . . . 237
119.11. ScsiIdType . . . . . . . . . . . . . . . . . . . . . . 237
119.12. ScsiIdValue . . . . . . . . . . . . . . . . . . . . . . 238
119.13. ScsiHrSWInstalledIndexOrZero . . . . . . . . . . . . . 238
120. SIP-MIB (revision 1994-03-31 18:18) . . . . . . . . . . . . 238
120.1. SMDSAddress . . . . . . . . . . . . . . . . . . . . . . 238
120.2. IfIndex . . . . . . . . . . . . . . . . . . . . . . . . 238
121. SIP-TC-MIB (revision 2007-04-20 00:00) . . . . . . . . . . . 239
121.1. SipTCTransportProtocol . . . . . . . . . . . . . . . . 239
121.2. SipTCEntityRole . . . . . . . . . . . . . . . . . . . . 239
121.3. SipTCOptionTagHeaders . . . . . . . . . . . . . . . . . 241
121.4. SipTCMethodName . . . . . . . . . . . . . . . . . . . . 241
122. SLAPM-MIB (revision 2000-01-24 00:00) . . . . . . . . . . . 241
122.1. SlapmNameType (deprecated) . . . . . . . . . . . . . . 241
122.2. SlapmStatus . . . . . . . . . . . . . . . . . . . . . . 242
122.3. SlapmPolicyRuleName . . . . . . . . . . . . . . . . . . 242
123. SMON-MIB (revision 1998-12-16 00:00) . . . . . . . . . . . . 242
123.1. SmonDataSource . . . . . . . . . . . . . . . . . . . . 242
124. SNMP-FRAMEWORK-MIB (revision 2002-10-14 00:00) . . . . . . . 243
124.1. SnmpEngineID . . . . . . . . . . . . . . . . . . . . . 243
124.2. SnmpSecurityModel . . . . . . . . . . . . . . . . . . . 245
124.3. SnmpMessageProcessingModel . . . . . . . . . . . . . . 247
124.4. SnmpSecurityLevel . . . . . . . . . . . . . . . . . . . 248
124.5. SnmpAdminString . . . . . . . . . . . . . . . . . . . . 249
125. SNMP-REPEATER-MIB (revision 1996-09-14 00:00) . . . . . . . 250
125.1. OptMacAddr . . . . . . . . . . . . . . . . . . . . . . 251
126. SNMP-SSH-TM-MIB (revision 2009-06-09 00:00) . . . . . . . . 251
126.1. SnmpSSHAddress . . . . . . . . . . . . . . . . . . . . 252
127. SNMP-TARGET-MIB (revision 2002-10-14 00:00) . . . . . . . . 253
127.1. SnmpTagValue . . . . . . . . . . . . . . . . . . . . . 253
127.2. SnmpTagList . . . . . . . . . . . . . . . . . . . . . . 255
128. SNMP-TLS-TM-MIB (revision 2010-05-07 00:00) . . . . . . . . 256
128.1. SnmpTLSAddress . . . . . . . . . . . . . . . . . . . . 256
128.2. SnmpTLSFingerprint . . . . . . . . . . . . . . . . . . 258
129. SNMP-USER-BASED-SM-MIB (revision 2002-10-16 00:00) . . . . . 258
129.1. KeyChange . . . . . . . . . . . . . . . . . . . . . . . 258
130. SNMP-USM-DH-OBJECTS-MIB (revision 2000-03-06 00:00) . . . . 261
130.1. DHKeyChange . . . . . . . . . . . . . . . . . . . . . . 261
Expires August 17, 2014 [Page 16]
Internet-Draft SMIv2 Textual Conventions February 2014
131. SNMPv2-TC . . . . . . . . . . . . . . . . . . . . . . . . . 262
131.1. DisplayString . . . . . . . . . . . . . . . . . . . . . 263
131.2. PhysAddress . . . . . . . . . . . . . . . . . . . . . . 263
131.3. MacAddress . . . . . . . . . . . . . . . . . . . . . . 263
131.4. TruthValue . . . . . . . . . . . . . . . . . . . . . . 264
131.5. TestAndIncr . . . . . . . . . . . . . . . . . . . . . . 264
131.6. AutonomousType . . . . . . . . . . . . . . . . . . . . 264
131.7. InstancePointer (obsolete) . . . . . . . . . . . . . . 264
131.8. VariablePointer . . . . . . . . . . . . . . . . . . . . 265
131.9. RowPointer . . . . . . . . . . . . . . . . . . . . . . 265
131.10. RowStatus . . . . . . . . . . . . . . . . . . . . . . . 265
131.11. TimeStamp . . . . . . . . . . . . . . . . . . . . . . . 275
131.12. TimeInterval . . . . . . . . . . . . . . . . . . . . . 275
131.13. DateAndTime . . . . . . . . . . . . . . . . . . . . . . 275
131.14. StorageType . . . . . . . . . . . . . . . . . . . . . . 276
131.15. TDomain . . . . . . . . . . . . . . . . . . . . . . . . 277
131.16. TAddress . . . . . . . . . . . . . . . . . . . . . . . 277
132. SNMPv2-TM (revision 2002-10-16 00:00) . . . . . . . . . . . 277
132.1. SnmpUDPAddress . . . . . . . . . . . . . . . . . . . . 277
132.2. SnmpOSIAddress . . . . . . . . . . . . . . . . . . . . 277
132.3. SnmpNBPAddress . . . . . . . . . . . . . . . . . . . . 278
132.4. SnmpIPXAddress . . . . . . . . . . . . . . . . . . . . 278
133. SNMPv2-USEC-MIB (revision 1996-01-12 00:00) . . . . . . . . 278
133.1. AgentID . . . . . . . . . . . . . . . . . . . . . . . . 278
134. SSPM-MIB (revision 2005-07-28 00:00) . . . . . . . . . . . . 279
134.1. SspmMicroSeconds . . . . . . . . . . . . . . . . . . . 279
134.2. SspmClockSource . . . . . . . . . . . . . . . . . . . . 279
134.3. SspmClockMaxSkew . . . . . . . . . . . . . . . . . . . 280
135. SYSAPPL-MIB (revision 1997-10-20 00:00) . . . . . . . . . . 280
135.1. RunState . . . . . . . . . . . . . . . . . . . . . . . 280
135.2. LongUtf8String . . . . . . . . . . . . . . . . . . . . 280
135.3. Utf8String . . . . . . . . . . . . . . . . . . . . . . 281
136. T11-FC-FABRIC-ADDR-MGR-MIB (revision 2006-03-02 00:00) . . . 281
136.1. T11FamDomainPriority . . . . . . . . . . . . . . . . . 281
136.2. T11FamDomainInterfaceRole . . . . . . . . . . . . . . . 282
136.3. T11FamState . . . . . . . . . . . . . . . . . . . . . . 282
137. T11-FC-FABRIC-CONFIG-SERVER-MIB (revision 2007-06-27
00:00) . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
137.1. T11FcListIndex . . . . . . . . . . . . . . . . . . . . 284
137.2. T11FcListIndexPointerOrZero . . . . . . . . . . . . . . 284
137.3. T11FcIeType . . . . . . . . . . . . . . . . . . . . . . 284
137.4. T11FcPortState . . . . . . . . . . . . . . . . . . . . 285
137.5. T11FcPortTxType . . . . . . . . . . . . . . . . . . . . 285
137.6. T11FcsRejectReasonExplanation . . . . . . . . . . . . . 285
138. T11-FC-FSPF-MIB (revision 2006-08-14 00:00) . . . . . . . . 287
138.1. T11FspfLsrType . . . . . . . . . . . . . . . . . . . . 287
138.2. T11FspfLinkType . . . . . . . . . . . . . . . . . . . . 287
138.3. T11FspfInterfaceState . . . . . . . . . . . . . . . . . 287
Expires August 17, 2014 [Page 17]
Internet-Draft SMIv2 Textual Conventions February 2014
138.4. T11FspfLastCreationTime . . . . . . . . . . . . . . . . 287
139. T11-FC-NAME-SERVER-MIB (revision 2006-03-02 00:00) . . . . . 288
139.1. T11NsGs4RejectReasonCode . . . . . . . . . . . . . . . 288
139.2. T11NsRejReasonCodeExpl . . . . . . . . . . . . . . . . 289
140. T11-FC-ZONE-SERVER-MIB (revision 2007-06-27 00:00) . . . . . 290
140.1. T11ZsZoneMemberType . . . . . . . . . . . . . . . . . . 291
140.2. T11ZsRejectReasonExplanation . . . . . . . . . . . . . 291
140.3. T11ZoningName . . . . . . . . . . . . . . . . . . . . . 293
141. T11-TC-MIB (revision 2006-03-02 00:00) . . . . . . . . . . . 293
141.1. T11FabricIndex . . . . . . . . . . . . . . . . . . . . 293
142. TCP-ESTATS-MIB (revision 2007-05-18 00:00) . . . . . . . . . 294
142.1. TcpEStatsNegotiated . . . . . . . . . . . . . . . . . . 294
143. TED-MIB (revision 2012-12-21 00:00) . . . . . . . . . . . . 295
143.1. TedAreaIdTC . . . . . . . . . . . . . . . . . . . . . . 295
143.2. TedRouterIdTC . . . . . . . . . . . . . . . . . . . . . 295
143.3. TedLinkIndexTC . . . . . . . . . . . . . . . . . . . . 295
144. TE-LINK-STD-MIB (revision 2005-10-11 00:00) . . . . . . . . 296
144.1. TeLinkBandwidth . . . . . . . . . . . . . . . . . . . . 296
144.2. TeLinkPriority . . . . . . . . . . . . . . . . . . . . 296
144.3. TeLinkProtection . . . . . . . . . . . . . . . . . . . 296
144.4. TeLinkSwitchingCapability . . . . . . . . . . . . . . . 296
144.5. TeLinkEncodingType . . . . . . . . . . . . . . . . . . 296
144.6. TeLinkSonetSdhIndication . . . . . . . . . . . . . . . 297
145. TIME-AGGREGATE-MIB (revision 2006-04-27 00:00) . . . . . . . 297
145.1. TAggrMOErrorStatus . . . . . . . . . . . . . . . . . . 297
145.2. TimeAggrMOValue . . . . . . . . . . . . . . . . . . . . 298
145.3. CompressedTimeAggrMOValue . . . . . . . . . . . . . . . 298
146. TN3270E-MIB (revision 1998-07-27 00:00) . . . . . . . . . . 298
146.1. SnaResourceName . . . . . . . . . . . . . . . . . . . . 298
146.2. Tn3270eTraceData . . . . . . . . . . . . . . . . . . . 299
147. TOKENRING-STATION-SR-MIB (revision 1994-12-16 10:00) . . . . 300
147.1. SourceRoute . . . . . . . . . . . . . . . . . . . . . . 300
148. TRANSPORT-ADDRESS-MIB (revision 2002-11-01 00:00) . . . . . 301
148.1. TransportDomain . . . . . . . . . . . . . . . . . . . . 301
148.2. TransportAddressType . . . . . . . . . . . . . . . . . 301
148.3. TransportAddress . . . . . . . . . . . . . . . . . . . 302
148.4. TransportAddressIPv4 . . . . . . . . . . . . . . . . . 303
148.5. TransportAddressIPv6 . . . . . . . . . . . . . . . . . 304
148.6. TransportAddressIPv4z . . . . . . . . . . . . . . . . . 304
148.7. TransportAddressIPv6z . . . . . . . . . . . . . . . . . 304
148.8. TransportAddressLocal . . . . . . . . . . . . . . . . . 305
148.9. TransportAddressDns . . . . . . . . . . . . . . . . . . 305
149. TRIP-TC-MIB (revision 2004-09-02 00:00) . . . . . . . . . . 306
149.1. TripItad . . . . . . . . . . . . . . . . . . . . . . . 306
149.2. TripId . . . . . . . . . . . . . . . . . . . . . . . . 307
149.3. TripAddressFamily . . . . . . . . . . . . . . . . . . . 307
149.4. TripAppProtocol . . . . . . . . . . . . . . . . . . . . 307
149.5. TripCommunityId . . . . . . . . . . . . . . . . . . . . 307
Expires August 17, 2014 [Page 18]
Internet-Draft SMIv2 Textual Conventions February 2014
149.6. TripProtocolVersion . . . . . . . . . . . . . . . . . . 307
149.7. TripSendReceiveMode . . . . . . . . . . . . . . . . . . 308
150. UPS-MIB (revision 1994-02-23 00:00) . . . . . . . . . . . . 308
150.1. PositiveInteger . . . . . . . . . . . . . . . . . . . . 308
150.2. NonNegativeInteger . . . . . . . . . . . . . . . . . . 308
151. URI-TC-MIB (revision 2007-09-10 00:00) . . . . . . . . . . . 308
151.1. Uri . . . . . . . . . . . . . . . . . . . . . . . . . . 308
151.2. Uri255 . . . . . . . . . . . . . . . . . . . . . . . . 309
151.3. Uri1024 . . . . . . . . . . . . . . . . . . . . . . . . 310
152. UUID-TC-MIB (revision 2013-04-05 00:00) . . . . . . . . . . 311
152.1. UUID . . . . . . . . . . . . . . . . . . . . . . . . . 311
152.2. UUIDorZero . . . . . . . . . . . . . . . . . . . . . . 312
153. VDSL2-LINE-TC-MIB (revision 2009-09-30 00:00) . . . . . . . 312
153.1. Xdsl2Unit . . . . . . . . . . . . . . . . . . . . . . . 312
153.2. Xdsl2Direction . . . . . . . . . . . . . . . . . . . . 313
153.3. Xdsl2Band . . . . . . . . . . . . . . . . . . . . . . . 313
153.4. Xdsl2TransmissionModeType . . . . . . . . . . . . . . . 314
153.5. Xdsl2RaMode . . . . . . . . . . . . . . . . . . . . . . 315
153.6. Xdsl2InitResult . . . . . . . . . . . . . . . . . . . . 315
153.7. Xdsl2OperationModes . . . . . . . . . . . . . . . . . . 315
153.8. Xdsl2PowerMngState . . . . . . . . . . . . . . . . . . 317
153.9. Xdsl2ConfPmsForce . . . . . . . . . . . . . . . . . . . 317
153.10. Xdsl2LinePmMode . . . . . . . . . . . . . . . . . . . . 318
153.11. Xdsl2LineLdsf . . . . . . . . . . . . . . . . . . . . . 318
153.12. Xdsl2LdsfResult . . . . . . . . . . . . . . . . . . . . 318
153.13. Xdsl2LineBpsc . . . . . . . . . . . . . . . . . . . . . 319
153.14. Xdsl2BpscResult . . . . . . . . . . . . . . . . . . . . 319
153.15. Xdsl2LineReset . . . . . . . . . . . . . . . . . . . . 320
153.16. Xdsl2LineProfiles . . . . . . . . . . . . . . . . . . . 320
153.17. Xdsl2LineClassMask . . . . . . . . . . . . . . . . . . 320
153.18. Xdsl2LineLimitMask . . . . . . . . . . . . . . . . . . 321
153.19. Xdsl2LineUs0Disable . . . . . . . . . . . . . . . . . . 321
153.20. Xdsl2LineUs0Mask . . . . . . . . . . . . . . . . . . . 322
153.21. Xdsl2SymbolProtection . . . . . . . . . . . . . . . . . 322
153.22. Xdsl2SymbolProtection8 . . . . . . . . . . . . . . . . 322
153.23. Xdsl2MaxBer . . . . . . . . . . . . . . . . . . . . . . 322
153.24. Xdsl2ChInitPolicy . . . . . . . . . . . . . . . . . . . 322
153.25. Xdsl2ScMaskDs . . . . . . . . . . . . . . . . . . . . . 323
153.26. Xdsl2ScMaskUs . . . . . . . . . . . . . . . . . . . . . 323
153.27. Xdsl2CarMask . . . . . . . . . . . . . . . . . . . . . 323
153.28. Xdsl2RfiBands . . . . . . . . . . . . . . . . . . . . . 323
153.29. Xdsl2PsdMaskDs . . . . . . . . . . . . . . . . . . . . 324
153.30. Xdsl2PsdMaskUs . . . . . . . . . . . . . . . . . . . . 324
153.31. Xdsl2Tssi . . . . . . . . . . . . . . . . . . . . . . . 324
153.32. Xdsl2LastTransmittedState . . . . . . . . . . . . . . . 325
153.33. Xdsl2LineStatus . . . . . . . . . . . . . . . . . . . . 325
153.34. Xdsl2ChInpReport . . . . . . . . . . . . . . . . . . . 325
153.35. Xdsl2ChAtmStatus . . . . . . . . . . . . . . . . . . . 325
Expires August 17, 2014 [Page 19]
Internet-Draft SMIv2 Textual Conventions February 2014
153.36. Xdsl2ChPtmStatus . . . . . . . . . . . . . . . . . . . 326
153.37. Xdsl2UpboKLF . . . . . . . . . . . . . . . . . . . . . 326
153.38. Xdsl2BandUs . . . . . . . . . . . . . . . . . . . . . . 327
153.39. Xdsl2LinePsdMaskSelectUs . . . . . . . . . . . . . . . 327
153.40. Xdsl2LineCeFlag . . . . . . . . . . . . . . . . . . . . 327
153.41. Xdsl2LineSnrMode . . . . . . . . . . . . . . . . . . . 327
153.42. Xdsl2LineTxRefVnDs . . . . . . . . . . . . . . . . . . 328
153.43. Xdsl2LineTxRefVnUs . . . . . . . . . . . . . . . . . . 328
153.44. Xdsl2BitsAlloc . . . . . . . . . . . . . . . . . . . . 328
153.45. Xdsl2MrefPsdDs . . . . . . . . . . . . . . . . . . . . 328
153.46. Xdsl2MrefPsdUs . . . . . . . . . . . . . . . . . . . . 329
154. VDSL-LINE-EXT-SCM-MIB (revision 2005-04-28 00:00) . . . . . 329
154.1. VdslSCMBandId . . . . . . . . . . . . . . . . . . . . . 330
155. VDSL-LINE-MIB (revision 2004-02-19 00:00) . . . . . . . . . 330
155.1. VdslLineCodingType . . . . . . . . . . . . . . . . . . 331
155.2. VdslLineEntity . . . . . . . . . . . . . . . . . . . . 331
156. VPN-TC-STD-MIB (revision 2005-11-15 00:00) . . . . . . . . . 331
156.1. VPNId . . . . . . . . . . . . . . . . . . . . . . . . . 332
156.2. VPNIdOrZero . . . . . . . . . . . . . . . . . . . . . . 332
157. VRRP-MIB (revision 2000-03-03 00:00) . . . . . . . . . . . . 332
157.1. VrId . . . . . . . . . . . . . . . . . . . . . . . . . 332
158. VRRPV3-MIB (revision 2012-02-13 00:00) . . . . . . . . . . . 332
158.1. Vrrpv3VrIdTC . . . . . . . . . . . . . . . . . . . . . 333
159. WWW-MIB (revision 1999-02-25 14:00) . . . . . . . . . . . . 333
159.1. WwwRequestType . . . . . . . . . . . . . . . . . . . . 333
159.2. WwwResponseType . . . . . . . . . . . . . . . . . . . . 333
159.3. WwwOperStatus . . . . . . . . . . . . . . . . . . . . . 333
159.4. WwwDocName . . . . . . . . . . . . . . . . . . . . . . 334
160. Security Considerations . . . . . . . . . . . . . . . . . . 334
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 334
Expires August 17, 2014 [Page 20]
Internet-Draft SMIv2 Textual Conventions February 2014
1. ACCOUNTING-CONTROL-MIB (revision 1998-09-28 10:00)
The MIB module for managing the collection and storage of accounting
information for connections in a connection- oriented network such as
ATM.
1.1. DataCollectionSubtree
The subtree component of a (subtree, list) tuple. Such a
(subtree, list) tuple defines a set of objects and their
values to be collected as accounting data for a connection.
The subtree specifies a single OBJECT IDENTIFIER value such
that each object in the set is named by the subtree value
appended with a single additional sub-identifier.
1.2. DataCollectionList
The list component of a (subtree, list) tuple. Such a
(subtree, list) tuple defines a set of objects and their
values to be collected as accounting data for a connection.
The subtree specifies a single OBJECT IDENTIFIER value such
that each object in the set is named by the subtree value
appended with a single additional sub-identifier. The list
specifies a set of data items, where the presence of an item
in the list indicates that the item is (to be) present in
the data collected for a connection; the absence of an item
from the list indicates that the item is not (to be) present
in the data collected for a connection. Each data item is
represented by an integer which when appended (as as
additional sub-identifier) to the OBJECT IDENTIFIER value of
the subtree identified by the tuple, is the name of an
object defining that data item (its description and its
syntax).
The list is specified as an OCTET STRING in which each data
item is represented by a single bit, where data items 1
through 8 are represented by the bits in the first octet,
data items 9 through 16 by the bits in the second octet,
etc. In each octet, the lowest numbered data item is
represented by the most significant bit, and the highest
numbered data item by the least significant bit. A data
item is present in the list when its bit is set, and absent
when its bit is reset. If the length of an OCTET STRING
value is too short to represent one or more data items
defined in a subtree, then those data items are absent from
the set identified by the tuple of that subtree and that
Expires August 17, 2014 [Page 21]
Internet-Draft SMIv2 Textual Conventions February 2014
OCTET STRING value.
1.3. FileIndex
An arbitrary integer value identifying a file into which
accounting data is being collected.
2. ADSL2-LINE-TC-MIB (revision 2006-10-04 00:00)
This MIB Module provides Textual Conventions to be used by the ADSL2-
LINE-MIB module for the purpose of managing ADSL, ADSL2, and ADSL2+
lines. Copyright (C) The Internet Society (2006). This version of
this MIB module is part of RFC 4706: see the RFC itself for full
legal notices.
2.1. Adsl2Unit
Identifies a transceiver as being either an ATU-C or
an ATU-R. An ADSL line consists of two transceivers, an ATU-C
and an ATU-R. Attributes with this syntax reference the two
sides of a line. Specified as an INTEGER, the two values
are:
atuc(1) -- Central office ADSL terminal unit (ATU-C).
atur(2) -- Remote ADSL terminal unit (ATU-R).
2.2. Adsl2Direction
Identifies the direction of a band as being
either upstream or downstream. Specified as an INTEGER,
the two values are:
upstream(1), and
downstream(2).
2.3. Adsl2TransmissionModeType
A set of ADSL2 line transmission modes, with one bit
per mode. The notes (F) and (L) denote Full-Rate
and Lite/splitterless, respectively:
Bit 00 : Regional Std. (ANSI T1.413) (F)
Expires August 17, 2014 [Page 22]
Internet-Draft SMIv2 Textual Conventions February 2014
Bit 01 : Regional Std. (ETSI DTS/TM06006) (F)
Bit 02 : G.992.1 POTS non-overlapped (F)
Bit 03 : G.992.1 POTS overlapped (F)
Bit 04 : G.992.1 ISDN non-overlapped (F)
Bit 05 : G.992.1 ISDN overlapped (F)
Bit 06 : G.992.1 TCM-ISDN non-overlapped (F)
Bit 07 : G.992.1 TCM-ISDN overlapped (F)
Bit 08 : G.992.2 POTS non-overlapped (L)
Bit 09 : G.992.2 POTS overlapped (L)
Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L)
Bit 11 : G.992.2 with TCM-ISDN overlapped (L)
Bit 12 : G.992.1 TCM-ISDN symmetric (F) -- not in G.997.1
Bit 13-17: Reserved
Bit 18 : G.992.3 POTS non-overlapped (F)
Bit 19 : G.992.3 POTS overlapped (F)
Bit 20 : G.992.3 ISDN non-overlapped (F)
Bit 21 : G.992.3 ISDN overlapped (F)
Bit 22-23: Reserved
Bit 24 : G.992.4 POTS non-overlapped (L)
Bit 25 : G.992.4 POTS overlapped (L)
Bit 26-27: Reserved
Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F)
Bit 29 : G.992.3 Annex I All-Digital overlapped (F)
Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F)
Bit 31 : G.992.3 Annex J All-Digital overlapped (F)
Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L)
Bit 33 : G.992.4 Annex I All-Digital overlapped (L)
Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1,
wide U/S (F)
Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2,
narrow U/S(F)
Bit 36 : G.992.3 Annex L POTS overlapped, mode 3,
wide U/S (F)
Bit 37 : G.992.3 Annex L POTS overlapped, mode 4,
narrow U/S (F)
Bit 38 : G.992.3 Annex M POTS non-overlapped (F)
Bit 39 : G.992.3 Annex M POTS overlapped (F)
Bit 40 : G.992.5 POTS non-overlapped (F)
Bit 41 : G.992.5 POTS overlapped (F)
Bit 42 : G.992.5 ISDN non-overlapped (F)
Bit 43 : G.992.5 ISDN overlapped (F)
Bit 44-45: Reserved
Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F)
Bit 47 : G.992.5 Annex I All-Digital overlapped (F)
Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F)
Expires August 17, 2014 [Page 23]
Internet-Draft SMIv2 Textual Conventions February 2014
Bit 49 : G.992.5 Annex J All-Digital overlapped (F)
Bit 50 : G.992.5 Annex M POTS non-overlapped (F)
Bit 51 : G.992.5 Annex M POTS overlapped (F)
Bit 52-55: Reserved
2.4. Adsl2RaMode
Specifies the rate adaptation behavior for the line.
The three possible behaviors are:
manual(1) - No Rate-Adaptation. The initialization
process attempts to synchronize to a
specified rate.
raInit(2) - Rate-Adaptation during initialization process
only, which attempts to synchronize to a rate
between minimum and maximum specified values.
dynamicRa(3) - Dynamic Rate-Adaptation during initialization
process as well as during SHOWTIME.
2.5. Adsl2InitResult
Specifies the result of a full initialization attempt; the
six possible result values are:
noFail(0) - Successful initialization.
configError(1) - Configuration failure.
configNotFeasible(2) - Configuration details not supported.
commFail(3) - Communication failure.
noPeerAtu(4) - Peer ATU not detected.
otherCause(5) - Other initialization failure reason.
The values used are as defined in ITU-T G.997.1,
paragraph 7.5.1.3
2.6. Adsl2OperationModes
The ADSL2 management model specified includes an ADSL Mode
attribute that identifies an instance of ADSL Mode-Specific
PSD Configuration object in the ADSL Line Profile. The
following classes of ADSL operating mode are defined.
The notes (F) and (L) denote Full-Rate and Lite/splitterless
respectively:
Expires August 17, 2014 [Page 24]
Internet-Draft SMIv2 Textual Conventions February 2014
+-------+--------------------------------------------------+
| Value | ADSL operation mode description |
+-------+--------------------------------------------------+
1 - The default/generic PSD configuration. Default
configuration will be used when no other matching
mode-specific configuration can be found.
2 - ADSL family. The attributes included in the Mode-
Specific PSD Configuration are irrelevant for
ITU-T G.992.1 and G.992.2 ADSL modes. Hence, it
is possible to map those modes to this generic
class.
3-7 - Unused. Reserved for future ITU-T specification.
8 - G.992.3 POTS non-overlapped (F)
9 - G.992.3 POTS overlapped (F)
10 - G.992.3 ISDN non-overlapped (F)
11 - G.992.3 ISDN overlapped (F)
12-13 - Unused. Reserved for future ITU-T specification.
14 - G.992.4 POTS non-overlapped (L)
15 - G.992.4 POTS overlapped (L)
16-17 - Unused. Reserved for future ITU-T specification.
18 - G.992.3 Annex I All-Digital non-overlapped (F)
19 - G.992.3 Annex I All-Digital overlapped (F)
20 - G.992.3 Annex J All-Digital non-overlapped (F)
21 - G.992.3 Annex J All-Digital overlapped (F)
22 - G.992.4 Annex I All-Digital non-overlapped (L)
23 - G.992.4 Annex I All-Digital overlapped (L)
24 - G.992.3 Annex L POTS non-overlapped, mode 1,
wide U/S (F)
25 - G.992.3 Annex L POTS non-overlapped, mode 2,
narrow U/S(F)
26 - G.992.3 Annex L POTS overlapped, mode 3,
wide U/S (F)
27 - G.992.3 Annex L POTS overlapped, mode 4,
narrow U/S (F)
28 - G.992.3 Annex M POTS non-overlapped (F)
29 - G.992.3 Annex M POTS overlapped (F)
30 - G.992.5 POTS non-overlapped (F)
31 - G.992.5 POTS overlapped (F)
32 - G.992.5 ISDN non-overlapped (F)
33 - G.992.5 ISDN overlapped (F)
34-35 - Unused. Reserved for future ITU-T specification.
36 - G.992.5 Annex I All-Digital non-overlapped (F)
37 - G.992.5 Annex I All-Digital overlapped (F)
38 - G.992.5 Annex J All-Digital non-overlapped (F)
39 - G.992.5 Annex J All-Digital overlapped (F)
40 - G.992.5 Annex M POTS non-overlapped (F)
41 - G.992.5 Annex M POTS overlapped (F)
Expires August 17, 2014 [Page 25]
Internet-Draft SMIv2 Textual Conventions February 2014
2.7. Adsl2PowerMngState
Attributes with this syntax uniquely identify each power
management state defined for the ADSL/ADSL2 or ADSL2+ link.
The possible values are:
l0(1) - L0 - Full power management state.
l1(2) - L1 - Low power management state (for G.992.2).
l2(3) - L2 - Low power management state (for G.992.3,
G.992.4, and G.992.5).
l3(4) - L3 - Idle power management state.
2.8. Adsl2ConfPmsForce
Attributes with this syntax are configuration parameters
that reference the desired power management state for the
ADSL/ADSL2 or ADSL2+ link:
l3toL0(0) - Perform a transition from L3 to L0
(Full power management state).
l0toL2(2) - Perform a transition from L0 to L2
(Low power management state).
l0orL2toL3(3) - Perform a transition into L3 (Idle
power management state).
The values used are as defined in ITU-T G.997.1,
paragraph 7.3.1.1.3
2.9. Adsl2LConfProfPmMode
Attributes with this syntax are configuration parameters
that reference the power modes/states into which the ATU-C or
ATU-R may autonomously transit.
It is a BITS structure that allows control of the following
transit options:
allowTransitionsToIdle(0) - XTU may autonomously transit
to idle (L3) state.
allowTransitionsToLowPower(1) - XTU may autonomously transit
to low-power (L2) state.
2.10. Adsl2LineLdsf
Expires August 17, 2014 [Page 26]
Internet-Draft SMIv2 Textual Conventions February 2014
Attributes with this syntax are configuration parameters
that control the Loop Diagnostic mode for the ADSL/ADSL2 or
ADSL2+ link. The possible values are:
inhibit(0) - Inhibit Loop Diagnostic mode.
force(1) - Force/Initiate Loop Diagnostic mode.
The values used are as defined in ITU-T G.997.1,
paragraph 7.3.1.1.8
2.11. Adsl2LdsfResult
Possible failure reasons associated with performing
a Dual Ended Loop Test (DELT) on a DSL line.
Possible values are:
none(1) - The default value in case LDSF was never
requested for the associated line.
success(2) - The recent command completed
successfully.
inProgress(3) - The Loop Diagnostics process is in
progress.
unsupported(4) - The NE or the line card doesn't support
LDSF.
cannotRun(5) - The NE cannot initiate the command, due
to a nonspecific reason.
aborted(6) - The Loop Diagnostics process aborted.
failed(7) - The Loop Diagnostics process failed.
illegalMode(8) - The NE cannot initiate the command, due
to the specific mode of the relevant
line.
adminUp(9) - The NE cannot initiate the command, as
the relevant line is administratively
'Up'.
tableFull(10) - The NE cannot initiate the command, due
to reaching the maximum number of rows
in the results table.
noResources(11) - The NE cannot initiate the command, due
to lack of internal memory resources.
2.12. Adsl2SymbolProtection
Attributes with this syntax are configuration parameters
that reference the minimum-length impulse noise protection
(INP) in terms of number of symbols. The possible values are:
noProtection (i.e., INP not required), halfSymbol (i.e., INP
length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol.
Expires August 17, 2014 [Page 27]
Internet-Draft SMIv2 Textual Conventions February 2014
2.13. Adsl2MaxBer
Attributes with this syntax are configuration parameters
that reference the maximum Bit Error Rate (BER).
The possible values are:
eminus3(1) - Maximum BER=E^-3
eminus5(2) - Maximum BER=E^-5
eminus7(3) - Maximum BER=E^-7
2.14. Adsl2ScMaskDs
Each one of the 512 bits in this OCTET
STRING array represents the corresponding bin
in the downstream direction. A value of one
indicates that the bin is not in use.
2.15. Adsl2ScMaskUs
Each one of the 64 bits in this OCTET
STRING array represents the corresponding bin
in the upstream direction. A value of one
indicates that the bin is not in use.
2.16. Adsl2RfiDs
Each one of the 512 bits in this OCTET
STRING array represents the corresponding bin
in the downstream direction. A value of one
indicates that the bin is part of a notch
filter.
2.17. Adsl2PsdMaskDs
Expires August 17, 2014 [Page 28]
Internet-Draft SMIv2 Textual Conventions February 2014
This is a structure that represents up to
32 PSD Mask breakpoints.
Each breakpoint occupies 3 octets: The first
two octets hold the index of the sub-carrier
associated with the breakpoint. The third octet
holds the PSD reduction at the breakpoint from 0
(0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of
0.5 dBm/Hz.
2.18. Adsl2PsdMaskUs
This is a structure that represents up to
4 PSD Mask breakpoints.
Each breakpoint occupies 3 octets: The first
two octets hold the index of the sub-carrier
associated with the breakpoint. The third octet
holds the PSD reduction at the breakpoint from 0
(0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of
0.5 dBm/Hz.
2.19. Adsl2Tssi
This is a structure that represents up to
32 transmit spectrum shaping (TSSi) breakpoints.
Each breakpoint occupies 3 octets: The first
two octets hold the index of the sub-carrier
associated with the breakpoint. The third octet
holds the shaping parameter at the breakpoint. It
is a value from 0 to 127 (units of -0.5 dB). The
special value 127 indicates that the sub-carrier
is not transmitted.
2.20. Adsl2LastTransmittedState
This parameter represents the last successfully
transmitted initialization state in the last full
initialization performed on the line. States are
per the specific xDSL technology and are numbered
from 0 (if G.994.1 is used) or 1 (if G.994.1 is
not used) up to Showtime.
2.21. Adsl2LineStatus
Expires August 17, 2014 [Page 29]
Internet-Draft SMIv2 Textual Conventions February 2014
Attributes with this syntax are status parameters
that reflect the failure status for a given endpoint of
ADSL/ADSL2 or ADSL2+ link.
This BITS structure can report the following failures:
noDefect(0) - This bit position positively reports
that no defect or failure exists.
lossOfFrame(1) - Loss of frame synchronization.
lossOfSignal(2) - Loss of signal.
lossOfPower(3) - Loss of power. Usually this failure may
be reported for ATU-Rs only.
initFailure(4) - Recent initialization process failed.
Never active on ATU-R.
2.22. Adsl2ChAtmStatus
Attributes with this syntax are status parameters that
reflect the failure status for Transmission Convergence (TC)
layer of a given ATM interface (data path over an ADSL/ADSL2
or ADSL2+ link).
This BITS structure can report the following failures:
noDefect(0) - This bit position positively
reports that no defect or failure
exists.
noCellDelineation(1) - The link was successfully
initialized, but cell delineation
was never acquired on the
associated ATM data path.
lossOfCellDelineation(2) - Loss of cell delineation on the
associated ATM data path.
2.23. Adsl2ChPtmStatus
Attributes with this syntax are status parameters that
reflect the failure status for a given PTM interface (packet
data path over an ADSL/ADSL2 or ADSL2+ link).
This BITS structure can report the following failures:
noDefect(0) - This bit position positively
reports that no defect or failure exists.
outOfSync(1) - Out of synchronization.
Expires August 17, 2014 [Page 30]
Internet-Draft SMIv2 Textual Conventions February 2014
3. ADSL-LINE-EXT-MIB (revision 2002-12-10 00:00)
Copyright (C) The Internet Society (2002). This version of this MIB
module is part of RFC 3440; see the RFC itself for full legal
notices. This MIB Module is a supplement to the ADSL-LINE-MIB
[RFC2662].
3.1. AdslTransmissionModeType
A set of ADSL line transmission modes, with one bit
per mode. The notes (F) and (L) denote Full-Rate
and G.Lite respectively:
Bit 00 : Regional Std. (ANSI T1.413) (F)
Bit 01 : Regional Std. (ETSI DTS/TM06006) (F)
Bit 02 : G.992.1 POTS non-overlapped (F)
Bit 03 : G.992.1 POTS overlapped (F)
Bit 04 : G.992.1 ISDN non-overlapped (F)
Bit 05 : G.992.1 ISDN overlapped (F)
Bit 06 : G.992.1 TCM-ISDN non-overlapped (F)
Bit 07 : G.992.1 TCM-ISDN overlapped (F)
Bit 08 : G.992.2 POTS non-overlapped (L)
Bit 09 : G.992.2 POTS overlapped (L)
Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L)
Bit 11 : G.992.2 with TCM-ISDN overlapped (L)
Bit 12 : G.992.1 TCM-ISDN symmetric (F)
4. ADSL-TC-MIB (revision 1999-08-19 00:00)
The MIB module which provides a ADSL Line Coding Textual Convention
to be used by ADSL Lines.
4.1. AdslLineCodingType
This data type is used as the syntax for the ADSL
Line Code.
4.2. AdslPerfCurrDayCount
Expires August 17, 2014 [Page 31]
Internet-Draft SMIv2 Textual Conventions February 2014
A counter associated with interface performance
measurements in a current 1-day (24 hour) measurement
interval.
The value of this counter starts at zero at the
beginning of an interval and is increased when
associated events occur, until the end of the
1-day interval. At that time the value of the
counter is stored in the previous 1-day history
interval, if available, and the current interval
counter is restarted at zero.
In the case where the agent has no valid data available
for this interval the corresponding object
instance is not available and upon a retrieval
request a corresponding error message shall be
returned to indicate that this instance does
not exist (for example, a noSuchName error for
SNMPv1 and a noSuchInstance for SNMPv2 GET
operation).
4.3. AdslPerfPrevDayCount
A counter associated with interface performance
measurements during the most previous 1-day (24 hour)
measurement interval. The value of this counter is
equal to the value of the current day counter at
the end of its most recent interval.
In the case where the agent has no valid data available
for this interval the corresponding object
instance is not available and upon a retrieval
request a corresponding error message shall be
returned to indicate that this instance does
not exist (for example, a noSuchName error for
SNMPv1 and a noSuchInstance for SNMPv2 GET
operation).
4.4. AdslPerfTimeElapsed
The number of seconds that have elapsed since
the beginning of the current measurement period.
If, for some reason, such as an adjustment in the
system's time-of-day clock, the current interval
exceeds the maximum value, the agent will return
the maximum value.
Expires August 17, 2014 [Page 32]
Internet-Draft SMIv2 Textual Conventions February 2014
5. AGENTX-MIB (revision 2000-01-10 00:00)
This is the MIB module for the SNMP Agent Extensibility Protocol
(AgentX). This MIB module will be implemented by the master agent.
5.1. AgentxTAddress
Denotes a transport service address. This is identical to
the TAddress textual convention (SNMPv2-SMI) except that
zero-length values are permitted.
6. AGGREGATE-MIB (revision 2006-04-27 00:00)
The MIB for servicing aggregate objects. Copyright (C) The Internet
Society (2006). This version of this MIB module is part of RFC 4498;
see the RFC itself for full legal notices.
6.1. AggrMOErrorStatus
Expires August 17, 2014 [Page 33]
Internet-Draft SMIv2 Textual Conventions February 2014
This data type is used to model the error status of the
constituent MO instances. The error status for a
constituent MO instance is given in terms of two elements:
o The moIndex, which indicates the position of the MO
instance (starting at 1) in the value of the aggregated
MO instance.
o The moError, which indicates the error that was
encountered in fetching that MO instance.
The syntax in ASN.1 Notation will be
ErrorStatus :: = SEQUENCE {
moIndex Integer32,
moError SnmpPduErrorStatus
}
AggrMOErrorStatus ::= SEQUENCE OF {
ErrorStatus
}
Note1: The command responder will supply values for all
constituent MO instances, in the same order in
which the MO instances are specified for the AgMO.
If an error is encountered for an MO instance, then
the corresponding value will have an ASN.1 value NULL,
and an error will be flagged in the corresponding
AggrMOErrorStatus object.
Only MOs for which errors have been encountered will
have their corresponding moIndex and moError values
set.
Note2: The error code for the component MO instances will be
in accordance with the SnmpPduErrorStatus TC defined
in the DISMAN-SCHEDULE-MIB [RFC3231].
Note3: The command generator will need to know
constituent MO instances and their order to correctly
interpret AggrMOErrorStatus.
6.2. AggrMOValue
Expires August 17, 2014 [Page 34]
Internet-Draft SMIv2 Textual Conventions February 2014
This data type is used to model the aggregate
MOs. It will have a format dependent on the constituent
MOs, a sequence of values. The syntax in ASN.1 Notation will
be
MOValue :: = SEQUENCE {
value ObjectSyntax
}
where 'value' is the value of a constituent MO instance.
AggrMOValue :: = SEQUENCE OF {
MOValue
}
Note: The command generator will need to know the
constituent MO instances and their order to
correctly interpret AggrMOValue.
6.3. AggrMOCompressedValue
This data type is used to model the compressed
aggregate MOs.
7. ALARM-MIB (revision 2004-09-09 00:00)
The MIB module describes a generic solution to model alarms and to
store the current list of active alarms. Copyright (C) The Internet
Society (2004). The initial version of this MIB module was published
in RFC 3877. For full legal notices see the RFC itself.
Supplementary information may be available on:
http://www.ietf.org/copyrights/ianamib.html
7.1. ResourceId
Expires August 17, 2014 [Page 35]
Internet-Draft SMIv2 Textual Conventions February 2014
A unique identifier for this resource.
The type of the resource can be determined by looking
at the OID that describes the resource.
Resources must be identified in a consistent manner.
For example, if this resource is an interface, this
object MUST point to an ifIndex and if this resource
is a physical entity [RFC2737], then this MUST point
to an entPhysicalDescr, given that entPhysicalIndex
is not accessible. In general, the value is the
name of the instance of the first accessible columnar
object in the conceptual row of a table that is
meaningful for this resource type, which SHOULD
be defined in an IETF standard MIB.
7.2. LocalSnmpEngineOrZeroLenStr
An SNMP Engine ID or a zero-length string. The
instantiation of this textual convention will provide
guidance on when this will be an SNMP Engine ID and
when it will be a zero lengths string
8. APM-MIB (revision 2004-02-19 00:00)
The MIB module for measuring application performance as experienced
by end-users. Copyright (C) The Internet Society (2004). This
version of this MIB module is part of RFC 3729; see the RFC itself
for full legal notices.
8.1. AppLocalIndex
Expires August 17, 2014 [Page 36]
Internet-Draft SMIv2 Textual Conventions February 2014
A locally arbitrary unique identifier associated with an
application or application verb.
All objects of type AppLocalIndex are assigned by the agent
out of a common number space. In other words, AppLocalIndex
values assigned to entries in one table must not overlap with
AppLocalIndex values assigned to entries in another
table. Further, every protocolDirLocalIndex value registered
by the agent automatically assigns the same value out of the
AppLocalIndex number space.
For example, if the protocolDirLocalIndex values { 1, 3, 5, 7 }
have been assigned, and the apmHttpFilterAppLocalIndex values
{ 6, 8, 9 } have been assigned:
- Assignment of new AppLocalIndex values must not use the
values { 1, 3, 5, 6, 7, 8, 9 }.
- AppLocalIndex values { 1, 3, 5, 7 } are automatically
assigned and are associated with the identical value of
protocolDirLocalIndex. In particular, an entry in the
apmAppDirTable indexed by a value provides further
information about a protocol indexed by the same value
in the protocolDirTable of RMON2.
The value for each supported application must remain constant
at least from one re-initialization of the entity's network
management system to the next re-initialization, except that
if an application is deleted and re-created, it must be
re-created with a new value that has not been used since the
last re-initialization.
The specific value is meaningful only within a given SNMP
entity. An AppLocalIndex value must not be re-used until the
next agent restart.
8.2. ProtocolDirNetworkAddress
Expires August 17, 2014 [Page 37]
Internet-Draft SMIv2 Textual Conventions February 2014
A network level address whose semantics and encoding are
specified by an associated protocolDirLocalIndex
value. Objects of this type must specify which
protocolDirLocalIndex value is used. This value is encoded
according to the encoding rules for the identified
protocolDirectory entry.
For example, if the associated protocolDirLocalIndex indicates
an encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order.
Objects of this type may allow this value to be the zero
length string. If so, they must identify they meaning of this
value.
8.3. DataSourceOrZero
Identifies the source of the data that the associated
function is configured to analyze. This source can be any
interface on this device.
In order to identify a particular interface, this
object shall identify the instance of the ifIndex
object, defined in [4], for the desired interface.
For example, if an entry were to receive data from
interface #1, this object would be set to ifIndex.1.
If the source of the data isn't an interface or cannot be
localized to an interface, this object would be set to 0.0
8.4. RmonClientID
Expires August 17, 2014 [Page 38]
Internet-Draft SMIv2 Textual Conventions February 2014
A long-lived unique ID assigned to an end-system. This ID is
assigned by the agent using an implementation-specific
algorithm.
Because a client machine may be assigned multiple addresses
over any time period it can be difficult to attribute
behavior to a particular client based solely on its
address. A ClientID may be assigned to provide a more
stable handle for referencing that client. The entity that
assigns the ClientID may use various implementation
techniques to keep track of a client but if the assigning
entity is unable to track client address mappings, it may map
client identifiers to client addresses rather than to
distinct client machines.
This is named ClientID because it helps to solve a problem
seen in network clients (servers usually have well-known,
long-lived addresses). However, ClientID's may be assigned to
any end-system regardless of its role on the network.
8.5. TransactionAggregationType
Expires August 17, 2014 [Page 39]
Internet-Draft SMIv2 Textual Conventions February 2014
Specifies one of 4 different techniques for aggregating
transactions.
The metrics for a single transaction are the responsiveness of
the transaction and whether the transaction succeeded (a
boolean). When such metrics are aggregated in this MIB Module,
these metrics are replaced by averages and distributions of
responsiveness and availability. The metrics describing
aggregates are constant no matter which type of aggregation is
being performed. These metrics may be found in the
apmReportTable.
The flows(1) aggregation is the simplest. All transactions
that share common application/server/client 3-tuples are
aggregated together, resulting in a set of metrics for all
such unique 3-tuples.
The clients(2) aggregation results in somewhat more
aggregation (i.e., fewer resulting records). All transactions
that share common application/client tuples are aggregated
together, resulting in a set of metrics for all such unique
tuples.
The servers(3) aggregation usually results in still more
aggregation (i.e., fewer resulting records). All transactions
that share common application/server tuples are aggregated
together, resulting in a set of metrics for all such unique
tuples.
The applications(4) aggregation results in the most
aggregation (i.e., the fewest resulting records). All
transactions that share a common application are aggregated
together, resulting in a set of metrics for all such unique
applications.
Note that it is not meaningful to aggregate applications, as
different applications have widely varying characteristics. As a
result, this set of aggregations is complete.
9. APPC-MIB (revision 1995-12-15 00:00)
This is the MIB module for objects used to manage network devices
with APPC capabilities.
Expires August 17, 2014 [Page 40]
Internet-Draft SMIv2 Textual Conventions February 2014
9.1. SnaSenseData
To facilitate their display by a Management Station, sense
data objects in the MIB are represented as DisplayStrings of
size 8. Eight '0' characters indicates that no sense data
identifying an SNA error condition is available.
10. APPLICATION-MIB (revision 1998-11-17 18:15)
This MIB defines objects representing generic aspects of applications
that are of interest to management but typically require
instrumentation within managed application elements.
10.1. Unsigned64TC
A non-negative 64-bit bit integer, without counter
semantics.
10.2. ApplTAddress
Denotes a transport service address.
For snmpUDPDomain, an ApplTAddress is 6 octets long,
the initial 4 octets containing the IP-address in
network-byte order and the last 2 containing the UDP
port in network-byte order. Consult 'Transport Mappings
for Version 2 of the Simple Network Management Protocol
(SNMPv2)' for further information on snmpUDPDomain.
11. APPN-MIB (revision 1998-07-15 18:00)
This is the MIB module for objects used to manage network devices
with APPN capabilities.
11.1. SnaNodeIdentification
Expires August 17, 2014 [Page 41]
Internet-Draft SMIv2 Textual Conventions February 2014
An SNA Node Identification consists of two parts, which
together comprise four bytes of hexadecimal data. In SNA the
Node Identification is transported in bytes 2-5 of the XID.
The block number is the first three digits of the Node
Identification. These 3 hexadecimal digits identify the
product.
The ID number is the last 5 digits of the Node Identification.
These 5 hexadecimal digits are administratively defined and
combined with the 3-digit block number form the 8-digit Node
Identification. A unique value is required for connections to
SNA subarea. In some implementations, the value 'bbb00000'
(where 'bbb' represents a 3-digit block number) is returned to
mean that the ID number is not unique on this node.
An SNA Node Identification is represented as eight
ASCII-encoded hexadecimal digits, using the characters '0' -
'9' and 'A' - 'F'.
11.2. SnaControlPointName
A fully qualified SNA control point name, consisting of a 1 to
8 character network identifier (NetId), a period ('.'), and a 1
to 8 character control point name (CpName).
The NetId and CpName are constructed from the uppercase letters
'A' - 'Z' and the numerics '0' - '9', all encoded in ASCII,
with the restriction that the first character of each must be
a letter. Trailing blanks are not allowed.
Earlier versions of SNA permitted three additional characters
in NetIds and CpNames: '#', '@', and '$'. While this use of
these characters has been retired, a Management Station should
still accept them for backward compatibility.
11.3. SnaClassOfServiceName
Expires August 17, 2014 [Page 42]
Internet-Draft SMIv2 Textual Conventions February 2014
An SNA class-of-service (COS) name, ranging from 1 to 8
ASCII characters. COS names take one of two forms:
- a user-defined COS name is constructed from the uppercase
letters 'A' - 'Z' and the numerics '0' - '9', with the
restriction that the first character of the name must be
a letter.
- an SNA-defined user-session COS name begins with the
character '#', which is followed by up to seven
additional characters from the set of uppercase letters
and numerics.
Trailing blanks are not allowed in either form of COS name.
A zero-length string indicates that a COS name is not
available.
11.4. SnaModeName
An SNA mode name, ranging from 1 to 8 ASCII characters.
Mode names take one of two forms:
- a user-defined mode name is constructed from the
uppercase letters 'A' - 'Z' and the numerics '0' - '9',
with the restriction that the first character of the name
must be a letter.
- an SNA-defined user-session mode name begins with the
character '#', which is followed by up to seven
additional characters from the set of uppercase letters
and numerics.
Trailing blanks are not allowed in either form of mode name,
with the single exception of the all-blank mode name, where
a string consisting of 8 blanks is returned.
A zero-length string indicates that a mode name is not
available.
11.5. SnaSenseData
Expires August 17, 2014 [Page 43]
Internet-Draft SMIv2 Textual Conventions February 2014
To facilitate their display by a Management Station, sense
data objects in the MIB are represented as OCTET STRINGS
containing eight ASCII characters. Eight '0' characters
indicates that no sense data identifying an SNA error
condition is available.
An SNA sense data is represented as eight hexadecimal digits,
using the characters '0' - '9' and 'A' - 'F'.
11.6. DisplayableDlcAddress
DLC address of a port or link station, represented as an
OCTET STRING containing 0 to 64 ASCII characters.
A Management Station should use a value of this type only
for display. The 'real' DLC address, i.e., the sequence of
bytes that flow in the DLC header, is often available in a
DLC-specific MIB.
The zero-length string indicates that the DLC address in
question is not known to the agent.
11.7. AppnNodeCounter
An object providing global statistics for the entire APPN
node. A Management Station can detect discontinuities in this
counter by monitoring the appnNodeCounterDisconTime object.
11.8. AppnPortCounter
An object providing statistics for an APPN port. A
Management Station can detect discontinuities in this counter
by monitoring the appnPortCounterDisconTime object.
11.9. AppnLinkStationCounter
An object providing statistics for an APPN link station. A
Management Station can detect discontinuities in this counter
by monitoring the appnLsCounterDisconTime object.
11.10. AppnTopologyEntryTimeLeft
Expires August 17, 2014 [Page 44]
Internet-Draft SMIv2 Textual Conventions February 2014
Number of days before deletion of this entry from the topology
database. Range is 0-15. A value of 0 indicates that the
entry is either in the process of being deleted, or is being
marked for deletion at the next garbage collection cycle.
11.11. AppnTgDlcData
DLC-specific data related to a connection network transmission
group. For other TGs, a zero-length string is returned.
Examples of the type of data returned by an object with this
syntax include the following:
Token-Ring - MAC/SAP
X.25 Switched - dial digits
X.21 Switched - dial digits
Circuit Switch - dial digits
This MIB does not specify formats for these or any other types
of DLC-specific data. Formats may, however, be specified in
documents related to a particular DLC.
The contents of an object with this syntax correspond to the
contents of the DLC-specific subfields of cv46, documented in
(6).
11.12. AppnTgEffectiveCapacity
A value representing the effective capacity of a transmission
group. This is an administratively assigned value derived from
the link bandwidth and maximum load factor. It is encoded in
the same way as byte 7 of cv47, and represents a floating-point
number in units of 300 bits per second.
11.13. AppnTgSecurity
Expires August 17, 2014 [Page 45]
Internet-Draft SMIv2 Textual Conventions February 2014
A value representing the level of security on a transmission
group. A class of service definition includes an indication of
the acceptable TG security value(s) for that class of service.
The following seven values are defined:
nonsecure(1) -
(X'01'): none of the values listed below;
for example, satellite-connected or
located in a nonsecure country
publicSwitchedNetwork(32) -
(X'20'): public switched network; secure
in the sense that there is no
predetermined route that traffic will take
undergroundCable(64) -
(X'40'): underground cable; located in a
secure country (as determined by the
network administrator)
secureConduit(96) -
(X'60'): secure conduit, not guarded; for
example, pressurized pipe
guardedConduit(128) -
(X'80'): guarded conduit; protected
against physical tapping
encrypted(160) -
(X'A0'): link-level encryption is provided
guardedRadiation(192) -
(X'C0'): guarded conduit containing the
transmission medium; protected against
physical and radiation tapping
11.14. AppnTgDelay
Relative amount of time that it takes for a signal to travel
the length of a logical link. This time is represented in
microseconds, using the same encoding scheme used in cv47 in a
topology update. Some of the more common values, along with
their encoded hex values, are:
minimum(0), X'00'
negligible(384), X'4C'
terrestrial(9216), X'71'
packet(147456), X'91'
long(294912), X'99'
maximum(2013265920) X'FF'
Expires August 17, 2014 [Page 46]
Internet-Draft SMIv2 Textual Conventions February 2014
12. APS-MIB (revision 2003-02-28 00:00)
This management information module supports the configuration and
management of SONET linear APS groups. The definitions and
descriptions used in this MIB have been derived from Synchronous
Optical Network (SONET) Transport Systems: Common Generic Criteria,
GR-253-CORE Issue 3, September 2000, section 5.3. The MIB is also
consistent with the Multiplex Section Protection (MSP) protocol as
specified in ITU-T Recommendation G.783, Characteristics of
synchronous digital hierarchy (SDH) equipment function blocks, Annex
A and B. Copyright (C) The Internet Society (2003). This version of
this MIB module is part of RFC 3498; see the RFC itself for full
legal notices.
12.1. ApsK1K2
This Textual Convention describes an object that stores
a SONET K1 and K2 byte APS protocol field.
K1 is located in the first octet, K2 is located in
the second octet. Bits are numbered from left to right.
Bits 1-4 of the K1 byte indicate a request.
1111 Lockout of Protection
1110 Forced Switch
1101 SF - High Priority
1100 SF - Low Priority
1011 SD - High Priority
1010 SD - Low Priority
1001 not used
1000 Manual Switch
0111 not used
0110 Wait-to-Restore
0101 not used
0100 Exercise
0011 not used
0010 Reverse Request
0001 Do Not Revert
0000 No Request
Bits 5-8 of the K1 byte indicate the channel associated with
the request defined in bits 1-4.
0000 is the Null channel.
Expires August 17, 2014 [Page 47]
Internet-Draft SMIv2 Textual Conventions February 2014
1-14 are working channels.
15 is the extra traffic channel
Bits 1-4 of the K2 byte indicate a channel. The channel is
defined with the same syntax as K1 Bits 5-8.
Bit 5 of the K2 byte indicates the
architecture.
0 if the architecture is 1+1
1 if the architecture is 1:n
Bits 6-8 of the K2 byte indicates the mode.
000 - 011 are reserved for future use
100 indicates the mode is unidirectional
101 indicates the mode is bidirectional
110 RDI-L
111 AIS-L
12.2. ApsSwitchCommand
An APS switch command allows a user to perform protection
switch actions.
If the APS switch command cannot be executed because an
equal or higher priority request is in effect, an
inconsistentValue error is returned.
The Switch command values are:
noCmd
This value should be returned by a read request when no switch
command has been written to the object in question since
initialization. This value may not be used in a write
operation. If noCmd is used in a write operation a wrongValue
error is returned.
clear
Expires August 17, 2014 [Page 48]
Internet-Draft SMIv2 Textual Conventions February 2014
Clears all of the switch commands listed below for the
specified channel.
lockoutOfProtection
Prevents any of the working channels from switching to the
protection line. The specified channel should be the protection
channel, otherwise an inconsistentValue error is returned.
forcedSwitchWorkToProtect
Switches the specified working channel to the protection line.
If the protection channel is specified an inconsistentValue
error is returned.
forcedSwitchProtectToWork
Switches the working channel back from the protection
line to the working line. The specified channel should be
the protection channel, otherwise an inconsistentValue
error is returned.
manualSwitchWorkToProtect
Switches the specified working channel to the protection line.
If the protection channel is specified an inconsistentValue
error is returned.
manualSwitchProtectToWork
Switches the working channel back from the protection
line to the working line. The specified channel should be
the protection channel, otherwise an inconsistentValue
error is returned.
exercise
Exercises the protocol for a protection switch of the specified
channel by issuing an Exercise request for that channel and
checking the response on the APS channel.
12.3. ApsControlCommand
Expires August 17, 2014 [Page 49]
Internet-Draft SMIv2 Textual Conventions February 2014
An APS control command applies only to LTE that support the
1:n architecture and performs the following actions.
The Control command values are:
noCmd
This value should be returned by a read request when no control
command has been written to the object in question since
initialization. This value may not be used in a write
operation. If noCmd is used in a write operation a wrongValue
error is returned.
lockoutWorkingChannel
Prevents the specified working channel from switching to the
protection line. If the protection line is specified an
inconsistentValue error is returned.
clearLockoutWorkingChannel
Clears the lockout a working channel command for the channel
specified. If the protection line is specified an
inconsistentValue error is returned.
13. ARC-MIB (revision 2004-09-09 00:00)
The MIB module describes the objects for controlling a resource in
reporting alarm conditions that it detects. Copyright (C) The
Internet Society (2004). This version of this MIB module is part of
RFC 3878; see the RFC itself for full legal notices.
13.1. IANAItuProbableCauseOrZero
This TC can take any value of IANAItuProbableCause or 0.
IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC
module, which is maintained at the IANA web site and
published in the Alarm MIB document (see RFC 3877).
14. ATM-TC-MIB (revision 1998-10-19 02:00)
This MIB Module provides Textual Conventions and OBJECT-IDENTITY
Objects to be used by ATM systems.
Expires August 17, 2014 [Page 50]
Internet-Draft SMIv2 Textual Conventions February 2014
14.1. AtmAddr
An ATM address. The semantics are implied by
the length. The address types are: - no
address (0 octets) - E.164 (8 octets) - NSAP
(20 octets) In addition, when subaddresses
are used the AtmAddr may represent the
concatenation of address and subaddress. The
associated address types are: - E.164, E.164
(16 octets) - E.164, NSAP (28 octets) - NSAP,
NSAP (40 octets) Address lengths other than
defined in this definition imply address
types defined elsewhere. Note: The E.164
address is encoded in BCD format.
14.2. AtmConnCastType
The type of topology of a connection (point-
to-point, point-to-multipoint). In the case
of point-to-multipoint, the orientation of
this VPL or VCL in the connection.
On a host:
- p2mpRoot indicates that the host
is the root of the p2mp connection.
- p2mpLeaf indicates that the host
is a leaf of the p2mp connection.
On a switch interface:
- p2mpRoot indicates that cells received
by the switching fabric from the interface
are from the root of the p2mp connection.
- p2mpLeaf indicates that cells transmitted
to the interface from the switching fabric
are to the leaf of the p2mp connection.
14.3. AtmConnKind
Expires August 17, 2014 [Page 51]
Internet-Draft SMIv2 Textual Conventions February 2014
The type of call control used for an ATM
connection at a particular interface. The use
is as follows:
pvc(1)
Virtual link of a PVC. Should not be
used for an PVC/SVC (i.e., Soft PVC)
crossconnect.
svcIncoming(2)
Virtual link established after a
received signaling request to setup
an SVC.
svcOutgoing(3)
Virtual link established after a
transmitted or forwarded signaling
request to setup an SVC.
spvcInitiator(4)
Virtual link at the PVC side of an
SVC/PVC crossconnect, where the
switch is the initiator of the Soft PVC
setup.
spvcTarget(5)
Virtual link at the PVC side of an
SVC/PVC crossconnect, where the
switch is the target of the Soft PVC
setup.
For PVCs, a pvc virtual link is always cross-
connected to a pvc virtual link.
For SVCs, an svcIncoming virtual link is always cross-
connected to an svcOutgoing virtual link.
For Soft PVCs, an spvcInitiator is either cross-connected to
an svcOutgoing or an spvcTarget, and an spvcTarget is either
cross-connected to an svcIncoming or an spvcInitiator.
14.4. AtmIlmiNetworkPrefix
A network prefix used for ILMI address
registration. In the case of ATM endsystem
addresses (AESAs), the network prefix is the first
13 octets of the address which includes the AFI,
IDI, and HO-DSP fields. In the case of native
E.164 addresses, the network prefix is the entire
E.164 address encoded in 8 octets, as if it were
an E.164 IDP in an ATM endsystem address
structure.
Expires August 17, 2014 [Page 52]
Internet-Draft SMIv2 Textual Conventions February 2014
14.5. AtmInterfaceType
The connection setup procedures used for the
identified interface.
Other: Connection setup procedures other than
those listed below.
Auto-configuration:
Indicates that the connection setup
procedures are to be determined dynamically,
or that determination has not yet been
completed. One such mechanism is via ATM
Forum ILMI auto-configuration procedures.
ITU-T DSS2:
- ITU-T Recommendation Q.2931, Broadband
Integrated Service Digital Network (B-ISDN)
Digital Subscriber Signalling System No.2
(DSS2) User-Network Interface (UNI) Layer 3
Specification for Basic Call/Connection
Control (September 1994)
- ITU-T Draft Recommendation Q.2961,
B-ISDN DSS 2 Support of Additional Traffic
Parameters (May 1995)
- ITU-T Draft Recommendation Q.2971,
B-ISDN DSS 2 User Network Interface Layer 3
Specification for Point-to-multipoint
Call/connection Control (May 1995)
ATM Forum UNI 3.0:
ATM Forum, ATM User-Network Interface,
Version 3.0 (UNI 3.0) Specification,
(1994).
ATM Forum UNI 3.1:
ATM Forum, ATM User-Network Interface,
Version 3.1 (UNI 3.1) Specification,
(November 1994).
ATM Forum UNI Signalling 4.0:
ATM Forum, ATM User-Network Interface (UNI)
Signalling Specification Version 4.0,
af-sig-0061.000 (June 1996).
ATM Forum IISP (based on UNI 3.0 or UNI 3.1) :
Interim Inter-switch Signaling Protocol
Expires August 17, 2014 [Page 53]
Internet-Draft SMIv2 Textual Conventions February 2014
(IISP) Specification, Version 1.0,
af-pnni-0026.000, (December 1994).
ATM Forum PNNI 1.0 :
ATM Forum, Private Network-Network Interface
Specification, Version 1.0, af-pnni-0055.000,
(March 1996).
ATM Forum B-ICI:
ATM Forum, B-ICI Specification, Version 2.0,
af-bici-0013.002, (November 1995).
ATM Forum UNI PVC Only:
An ATM Forum compliant UNI with the
signalling disabled.
ATM Forum NNI PVC Only:
An ATM Forum compliant NNI with the
signalling disabled.
14.6. AtmServiceCategory
The service category for a connection.
14.7. AtmSigDescrParamIndex
The value of this object identifies a row in the
atmSigDescrParamTable. The value 0 signifies that
none of the signalling parameters defined in the
atmSigDescrParamTable are applicable.
14.8. AtmTrafficDescrParamIndex
The value of this object identifies a row in the
atmTrafficDescrParamTable. The value 0 signifies
that no row has been identified.
14.9. AtmVcIdentifier
The VCI value for a VCL. The maximum VCI value
cannot exceed the value allowable by
atmInterfaceMaxVciBits defined in ATM-MIB.
Expires August 17, 2014 [Page 54]
Internet-Draft SMIv2 Textual Conventions February 2014
14.10. AtmVpIdentifier
The VPI value for a VPL or VCL. The value VPI=0
is only allowed for a VCL. For ATM UNIs supporting
VPCs the VPI value ranges from 0 to 255. The VPI
value 0 is supported for ATM UNIs conforming to
the ATM Forum UNI 4.0 Annex 8 (Virtual UNIs)
specification. For ATM UNIs supporting VCCs the
VPI value ranges from 0 to 255. For ATM NNIs the
VPI value ranges from 0 to 4095. The maximum VPI
value cannot exceed the value allowable by
atmInterfaceMaxVpiBits defined in ATM-MIB.
14.11. AtmVorXAdminStatus
The value determines the desired administrative
status of a virtual link or cross-connect. The up
and down states indicate that the traffic flow is
enabled or disabled respectively on the virtual
link or cross-connect.
14.12. AtmVorXLastChange
The value of MIB II's sysUpTime at the time a
virtual link or cross-connect entered its current
operational state. If the current state was
entered prior to the last re-initialization of the
agent then this object contains a zero value.
14.13. AtmVorXOperStatus
The value determines the operational status of a
virtual link or cross-connect. The up and down
states indicate that the traffic flow is enabled
or disabled respectively on the virtual link or
cross-connect. The unknown state indicates that
the state of it cannot be determined. The state
will be down or unknown if the supporting ATM
interface(s) is down or unknown respectively.
15. BLDG-HVAC-MIB (revision 2003-03-27 00:00)
This example MIB module defines a set of management objects for
Expires August 17, 2014 [Page 55]
Internet-Draft SMIv2 Textual Conventions February 2014
heating ventilation and air conditioning systems. It also includes
objects that can be used to create policies that are applied to
rooms. This eliminates the need to send per-instance configuration
commands to the system. Copyright (C) The Internet Society (2003).
This version of this MIB module is part of RFC 3512; see the RFC
itself for full legal notices.
15.1. BldgHvacOperation
Operations supported by a heating and cooling system.
A reference to underlying general systems would go here.
16. BRIDGE-MIB (revision 2005-09-19 00:00)
The Bridge MIB module for managing devices that support IEEE 802.1D.
Copyright (C) The Internet Society (2005). This version of this MIB
module is part of RFC 4188; see the RFC itself for full legal
notices.
16.1. BridgeId
The Bridge-Identifier, as used in the Spanning Tree
Protocol, to uniquely identify a bridge. Its first two
octets (in network byte order) contain a priority value,
and its last 6 octets contain the MAC address used to
refer to a bridge in a unique fashion (typically, the
numerically smallest MAC address of all ports on the
bridge).
16.2. Timeout
Expires August 17, 2014 [Page 56]
Internet-Draft SMIv2 Textual Conventions February 2014
A Spanning Tree Protocol (STP) timer in units of 1/100
seconds. Several objects in this MIB module represent
values of timers used by the Spanning Tree Protocol.
In this MIB, these timers have values in units of
hundredths of a second (i.e., 1/100 secs).
These timers, when stored in a Spanning Tree Protocol's
BPDU, are in units of 1/256 seconds. Note, however, that
802.1D-1998 specifies a settable granularity of no more
than one second for these timers. To avoid ambiguity,
a conversion algorithm is defined below for converting
between the different units, which ensures a timer's
value is not distorted by multiple conversions.
To convert a Timeout value into a value in units of
1/256 seconds, the following algorithm should be used:
b = floor( (n * 256) / 100)
where:
floor = quotient [ignore remainder]
n is the value in 1/100 second units
b is the value in 1/256 second units
To convert the value from 1/256 second units back to
1/100 seconds, the following algorithm should be used:
n = ceiling( (b * 100) / 256)
where:
ceiling = quotient [if remainder is 0], or
quotient + 1 [if remainder is nonzero]
n is the value in 1/100 second units
b is the value in 1/256 second units
Note: it is important that the arithmetic operations are
done in the order specified (i.e., multiply first,
divide second).
17. CAPWAP-BASE-MIB (revision 2010-04-30 00:00)
Copyright (c) 2010 IETF Trust and the persons identified as authors
of the code. All rights reserved. Redistribution and use in source
and binary forms, with or without modification, is permitted pursuant
Expires August 17, 2014 [Page 57]
Internet-Draft SMIv2 Textual Conventions February 2014
to, and subject to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC 5833; see the RFC
itself for full legal notices. This MIB module contains managed
object definitions for the CAPWAP Protocol.
17.1. CapwapBaseWtpProfileIdTC
Represents the unique identifier of a WTP profile.
17.2. CapwapBaseWtpIdTC
Represents the unique identifier of a WTP instance.
As usual, the Base MAC address of the WTP is used.
17.3. CapwapBaseStationIdTC
Represents the unique identifier of a station instance.
As usual, the MAC address of the station is used.
17.4. CapwapBaseRadioIdTC
Represents the unique identifier of a radio on a WTP.
17.5. CapwapBaseTunnelModeTC
Represents the tunneling modes of operation that are
supported by a WTP.
The WTP MAY support more than one option, represented by
the bit field below:
localBridging(0) - Local bridging mode
dot3Tunnel(1) - 802.3 frame tunnel mode
nativeTunnel(2) - Native frame tunnel mode
17.6. CapwapBaseMacTypeTC
Expires August 17, 2014 [Page 58]
Internet-Draft SMIv2 Textual Conventions February 2014
Represents the MAC mode of operation supported by a WTP.
The following enumerated values are supported:
localMAC(0) - Local-MAC mode
splitMAC(1) - Split-MAC mode
both(2) - Both Local-MAC and Split-MAC
Note that the CAPWAP field [RFC5415] modeled by this
object takes zero as starting value; this MIB object
follows that rule.
17.7. CapwapBaseChannelTypeTC
Represents the channel type for CAPWAP protocol.
The following enumerated values are supported:
data(1) - Data channel
control(2) - Control channel
17.8. CapwapBaseAuthenMethodTC
Represents the authentication credential type for a WTP.
The following enumerated values are supported:
other(1) - Other method, for example, vendor specific
clear(2) - Clear text and no authentication
x509(3) - X.509 certificate authentication
psk(4) - Pre-Shared secret authentication
As a mandatory requirement, CAPWAP control channel
authentication SHOULD use DTLS, either by certificate or
PSK. For data channel authentication, DTLS is optional.
18. CAPWAP-DOT11-MIB (revision 2010-04-30 00:00)
Copyright (c) 2010 IETF Trust and the persons identified as authors
of the code. All rights reserved. Redistribution and use in source
and binary forms, with or without modification, is permitted pursuant
to, and subject to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC 5834; see the RFC
itself for full legal notices. This MIB module contains managed
object definitions for CAPWAP Protocol binding for IEEE 802.11.
18.1. CapwapDot11WlanIdTC
Represents the unique identifier of a Wireless Local Area
Network (WLAN).
Expires August 17, 2014 [Page 59]
Internet-Draft SMIv2 Textual Conventions February 2014
18.2. CapwapDot11WlanIdProfileTC
Represents the unique identifier of a WLAN profile.
19. CHARACTER-MIB (revision 1994-05-26 17:00)
The MIB module for character stream devices.
19.1. PortIndex
A unique value, greater than zero, for each
character port 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.
In a system where the character ports are attached
to hardware represented by an ifIndex, it is
conventional, but not required, to make the
character port index equal to the corresponding
ifIndex.
20. CIRCUIT-IF-MIB (revision 2002-01-03 00:00)
The MIB module to allow insertion of selected circuit into the
ifTable.
20.1. CiFlowDirection
The direction of data flow thru a circuit.
transmit(1) - Only transmitted data
receive(2) - Only received data
both(3) - Both transmitted and received data.
21. COPS-CLIENT-MIB (revision 2000-09-28 00:00)
The COPS Client MIB module
Expires August 17, 2014 [Page 60]
Internet-Draft SMIv2 Textual Conventions February 2014
21.1. CopsClientState
A value indicating the state of a COPS client.
21.2. CopsServerEntryType
A value indicating how a COPS server entry came into existence.
21.3. CopsErrorCode
A value describing a COPS protocol error. Codes are identical
to those used by the COPS protocol itself.
21.4. CopsTcpPort
A value indicating a TCP protocol port number.
21.5. CopsAuthType
A value indicating a type of security authentication mechanism.
22. DIAL-CONTROL-MIB (revision 1996-09-23 15:44)
The MIB module to describe peer information for demand access and
possibly other kinds of interfaces.
22.1. AbsoluteCounter32
Represents a Counter32-like value that starts at zero,
does not decrease, and does not wrap. This may be used
only in situations where wrapping is not possible or
extremely unlikely. Should such a counter overflow,
it locks at the maxium value of 4,294,967,295.
The primary use of this type of counter is situations
where a counter value is to be recorded as history
and is thus no longer subject to reading for changing
values.
Expires August 17, 2014 [Page 61]
Internet-Draft SMIv2 Textual Conventions February 2014
23. DIFFSERV-DSCP-TC (revision 2002-05-09 00:00)
The Textual Conventions defined in this module should be used
whenever a Differentiated Services Code Point is used in a MIB.
23.1. Dscp
A Differentiated Services Code-Point that may be used for
marking a traffic stream.
23.2. DscpOrAny
The IP header Differentiated Services Code-Point that may be
used for discriminating among traffic streams. The value -1 is
used to indicate a wild card i.e. any value.
24. DIFFSERV-MIB (revision 2002-02-07 00:00)
This MIB defines the objects necessary to manage a device that uses
the Differentiated Services Architecture described in RFC 2475. The
Conceptual Model of a Differentiated Services Router provides
supporting information on how such a router is modeled.
24.1. IndexInteger
An integer which may be used as a table index.
24.2. IndexIntegerNextFree
Expires August 17, 2014 [Page 62]
Internet-Draft SMIv2 Textual Conventions February 2014
An integer which may be used as a new Index in a table.
The special value of 0 indicates that no more new entries can be
created in the relevant table.
When a MIB is used for configuration, an object with this SYNTAX
always contains a legal value (if non-zero) for an index that is
not currently used in the relevant table. The Command Generator
(Network Management Application) reads this variable and uses the
(non-zero) value read when creating a new row with an SNMP SET.
When the SET is performed, the Command Responder (agent) must
determine whether the value is indeed still unused; Two Network
Management Applications may attempt to create a row
(configuration entry) simultaneously and use the same value. If
it is currently unused, the SET succeeds and the Command
Responder (agent) changes the value of this object, according to
an implementation-specific algorithm. If the value is in use,
however, the SET fails. The Network Management Application must
then re-read this variable to obtain a new usable value.
An OBJECT-TYPE definition using this SYNTAX MUST specify the
relevant table for which the object is providing this
functionality.
24.3. IfDirection
IfDirection specifies a direction of data travel on an
interface. 'inbound' traffic is operated on during reception from
the interface, while 'outbound' traffic is operated on prior to
transmission on the interface.
25. DISMAN-EVENT-MIB (revision 2000-10-16 00:00)
The MIB module for defining event triggers and actions for network
management purposes.
25.1. FailureReason
Expires August 17, 2014 [Page 63]
Internet-Draft SMIv2 Textual Conventions February 2014
Reasons for failures in an attempt to perform a management
request.
The first group of errors, numbered less than 0, are related
to problems in sending the request. The existence of a
particular error code here does not imply that all
implementations are capable of sensing that error and
returning that code.
The second group, numbered greater than 0, are copied
directly from SNMP protocol operations and are intended to
carry exactly the meanings defined for the protocol as returned
in an SNMP response.
localResourceLack some local resource such as memory
lacking or
mteResourceSampleInstanceMaximum
exceeded
badDestination unrecognized domain name or otherwise
invalid destination address
destinationUnreachable can't get to destination address
noResponse no response to SNMP request
badType the data syntax of a retrieved object
as not as expected
sampleOverrun another sample attempt occurred before
the previous one completed
26. DISMAN-PING-MIB (revision 2006-06-13 00:00)
The Ping MIB (DISMAN-PING-MIB) provides the capability of controlling
the use of the ping function at a remote host. Copyright (C) The
Internet Society (2006). This version of this MIB module is part of
RFC 4560; see the RFC itself for full legal notices.
26.1. OperationResponseStatus
Expires August 17, 2014 [Page 64]
Internet-Draft SMIv2 Textual Conventions February 2014
Used to report the result of an operation:
responseReceived(1) - Operation is completed successfully.
unknown(2) - Operation failed due to unknown error.
internalError(3) - An implementation detected an error
in its own processing that caused an operation
to fail.
requestTimedOut(4) - Operation failed to receive a
valid reply within the time limit imposed on it.
unknownDestinationAddress(5) - Invalid destination
address.
noRouteToTarget(6) - Could not find a route to target.
interfaceInactiveToTarget(7) - The interface to be
used in sending a probe is inactive, and an
alternate route does not exist.
arpFailure(8) - Unable to resolve a target address to a
media-specific address.
maxConcurrentLimitReached(9) - The maximum number of
concurrent active operations would have been exceeded
if the corresponding operation was allowed.
unableToResolveDnsName(10) - The DNS name specified was
unable to be mapped to an IP address.
invalidHostAddress(11) - The IP address for a host
has been determined to be invalid. Examples of this
are broadcast or multicast addresses.
27. DISMAN-SCHEDULE-MIB (revision 2002-01-07 00:00)
This MIB module defines a MIB which provides mechanisms to schedule
SNMP set operations periodically or at specific points in time.
27.1. SnmpPduErrorStatus
This TC enumerates the SNMPv1 and SNMPv2 PDU error status
codes as defined in RFC 1157 and RFC 1905. It also adds a
pseudo error status code `noResponse' which indicates a
timeout condition.
28. DLSW-MIB (revision 1996-06-04 09:00)
This MIB module contains objects to manage Data Link Switches.
Expires August 17, 2014 [Page 65]
Internet-Draft SMIv2 Textual Conventions February 2014
28.1. NBName
Represents a single qualified NetBIOS name, which can include
`don't care' and `wildcard' characters to represent a number
of real NetBIOS names. If an individual character position in
the qualified name contains a `?', the corresponding character
position in a real NetBIOS name is a `don't care'. If the
qualified name ends in `*', the remainder of a real NetBIOS
name is a `don't care'. `*' is only considered a wildcard if it
appears at the end of a name.
28.2. MacAddressNC
Represents an 802 MAC address represented in
non-canonical format. That is, the most significant
bit will be transmitted first. If this information
is not available, the value is a zero length string.
28.3. TAddress
Denotes a transport service address.
For dlswTCPDomain, a TAddress is 4 octets long,
containing the IP-address in network-byte order.
28.4. EndStationLocation
Representing the location of an end station related
to the managed DLSw node.
28.5. DlcType
Representing the type of DLC of an end station, if
applicable.
28.6. LFSize
The largest size of the INFO field (including DLC header,
not including any MAC-level or framing octets).
64 valid values as defined by the IEEE 802.1D
Addendum are acceptable.
Expires August 17, 2014 [Page 66]
Internet-Draft SMIv2 Textual Conventions February 2014
28.7. DlswTCPAddress
Represents the IP address of a DLSw which uses
TCP as a transport protocol.
29. DNS-SERVER-MIB (revision 1994-01-28 22:51)
The MIB module for entities implementing the server side of the
Domain Name System (DNS) protocol.
29.1. DnsName
A DNS name is a sequence of labels. When DNS names are
displayed, the boundaries between labels are typically
indicated by dots (e.g. `Acme' and `COM' are labels in
the name `Acme.COM'). In the DNS protocol, however, no
such separators are needed because each label is encoded
as a length octet followed by the indicated number of
octets of label. For example, `Acme.COM' is encoded as
the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
'M', 0 } (the final 0 is the length of the name of the
root domain, which appears implicitly at the end of any
DNS name). This MIB uses the same encoding as the DNS
protocol.
A DnsName must always be a fully qualified name. It is
an error to encode a relative domain name as a DnsName
without first making it a fully qualified name.
29.2. DnsNameAsIndex
This textual convention is like a DnsName, but is used
as an index componant in tables. Alphabetic characters
in names of this type are restricted to uppercase: the
characters 'a' through 'z' are mapped to the characters
'A' through 'Z'. This restriction is intended to make
the lexical ordering imposed by SNMP useful when applied
to DNS names.
Note that it is theoretically possible for a valid DNS
name to exceed the allowed length of an SNMP object
identifer, and thus be impossible to represent in tables
in this MIB that are indexed by DNS name. Sampling of
DNS names in current use on the Internet suggests that
Expires August 17, 2014 [Page 67]
Internet-Draft SMIv2 Textual Conventions February 2014
this limit does not pose a serious problem in practice.
29.3. DnsClass
This data type is used to represent the class values
which appear in Resource Records in the DNS. A 16-bit
unsigned integer is used to allow room for new classes
of records to be defined. Existing standard classes are
listed in the DNS specifications.
29.4. DnsType
This data type is used to represent the type values
which appear in Resource Records in the DNS. A 16-bit
unsigned integer is used to allow room for new record
types to be defined. Existing standard types are listed
in the DNS specifications.
29.5. DnsQClass
This data type is used to represent the QClass values
which appear in Resource Records in the DNS. A 16-bit
unsigned integer is used to allow room for new QClass
records to be defined. Existing standard QClasses are
listed in the DNS specification.
29.6. DnsQType
This data type is used to represent the QType values
which appear in Resource Records in the DNS. A 16-bit
unsigned integer is used to allow room for new QType
records to be defined. Existing standard QTypes are
listed in the DNS specification.
29.7. DnsTime
DnsTime values are 32-bit unsigned integers which
measure time in seconds.
29.8. DnsOpCode
Expires August 17, 2014 [Page 68]
Internet-Draft SMIv2 Textual Conventions February 2014
This textual convention is used to represent the DNS
OPCODE values used in the header section of DNS
messages. Existing standard OPCODE values are listed in
the DNS specifications.
29.9. DnsRespCode
This data type is used to represent the DNS RCODE value
in DNS response messages. Existing standard RCODE
values are listed in the DNS specifications.
30. DOCS-IETF-BPI2-MIB (revision 2005-07-20 00:00)
This is the MIB module for the DOCSIS Baseline Privacy Plus Interface
(BPI+) at cable modems (CMs) and cable modem termination systems
(CMTSs). Copyright (C) The Internet Society (2005). This version of
this MIB module is part of RFC 4131; see the RFC itself for full
legal notices.
30.1. DocsX509ASN1DEREncodedCertificate
An X509 digital certificate encoded as an ASN.1 DER
object.
30.2. DocsSAId
Security Association identifier (SAID).
30.3. DocsSAIdOrZero
Security Association identifier (SAID). The value
zero indicates that the SAID is yet to be determined.
30.4. DocsBpkmSAType
Expires August 17, 2014 [Page 69]
Internet-Draft SMIv2 Textual Conventions February 2014
The type of security association (SA).
The values of the named-numbers are associated
with the BPKM SA-Type attributes:
'primary' corresponds to code '1', 'static' to code '2',
and 'dynamic' to code '3'.
The 'none' value must only be used if the SA type has yet
to be determined.
30.5. DocsBpkmDataEncryptAlg
The list of data encryption algorithms defined for
the DOCSIS interface in the BPKM cryptographic-suite
parameter. The value 'none' indicates that the SAID
being referenced has no data encryption.
30.6. DocsBpkmDataAuthentAlg
The list of data integrity algorithms defined for the
DOCSIS interface in the BPKM cryptographic-suite parameter.
The value 'none' indicates that no data integrity is used for
the SAID being referenced.
31. DOCS-IETF-QOS-MIB (revision 2006-01-23 00:00)
This is the management information for Quality Of Service (QOS) for
DOCSIS 1.1 and 2.0. Copyright (C) The Internet Society (2006). This
version of this MIB module is part of RFC 4323; see the RFC itself
for full legal notices.
31.1. DocsIetfQosRfMacIfDirection
Indicates a direction on an RF MAC interface.
The value downstream(1) is from Cable Modem
Termination System to Cable Modem.
The value upstream(2) is from Cable Modem to
Cable Modem Termination System.
Expires August 17, 2014 [Page 70]
Internet-Draft SMIv2 Textual Conventions February 2014
31.2. DocsIetfQosBitRate
The rate of traffic in unit of bits per second.
Used to specify traffic rate for QOS.
31.3. DocsIetfQosSchedulingType
The scheduling service provided by a CMTS for an
upstream Service Flow. If the parameter is omitted
from an upstream QOS Parameter Set, this object
takes the value of bestEffort (2). This parameter
must be reported as undefined (1) for downstream
QOS Parameter Sets.
32. DOCS-IF-MIB (revision 2006-05-24 00:00)
This is the MIB Module for DOCSIS 2.0-compliant Radio Frequency (RF)
interfaces in Cable Modems and Cable Modem Termination Systems.
Copyright (C) The Internet Society (2006). This version of this MIB
module is part of RFC 4546; see the RFC itself for full legal
notices.
32.1. TenthdBmV
This data type represents power levels that are normally
expressed in dBmV. Units are in tenths of a dBmV;
for example, 5.1 dBmV will be represented as 51.
32.2. TenthdB
This data type represents power levels that are normally
expressed in dB. Units are in tenths of a dB;
for example, 5.1 dB will be represented as 51.
32.3. DocsisVersion
Indicates the DOCSIS Radio Frequency specification being
referenced.
'docsis10' indicates DOCSIS 1.0.
'docsis11' indicates DOCSIS 1.1.
'docsis20' indicates DOCSIS 2.0.
Expires August 17, 2014 [Page 71]
Internet-Draft SMIv2 Textual Conventions February 2014
32.4. DocsisQosVersion
Indicates the referenced quality-of-service
level.
'docsis10 refers to DOCSIS 1.0 Class of
Service queuing services, and 'docsis11' refers
to DOCSIS 1.1 Quality of Service.
32.5. DocsisUpstreamType
Indicates the DOCSIS Upstream Channel Type.
'unknown' means information not available.
'tdma' is related to TDMA, Time Division
Multiple Access; 'atdma' is related to A-TDMA,
Advanced Time Division Multiple Access,
'scdma' is related to S-CDMA, Synchronous
Code Division Multiple Access.
'tdmaAndAtdma is related to simultaneous support of
TDMA and A-TDMA modes.
32.6. DocsEqualizerData
Expires August 17, 2014 [Page 72]
Internet-Draft SMIv2 Textual Conventions February 2014
This data type represents the equalizer data
as measured at the receiver interface.
The format of the equalizer follows the structure of the
Transmit Equalization Adjust RNG-RSP TLV of DOCSIS RFI
v2.0 :
1 byte Main tap location 1..(n + m)
1 byte Number of forward taps per symbol
1 byte Number of forward taps: n
1 byte Number of reverse taps: m
Following are the equalizer coefficients:
First, forward taps coefficients:
2 bytes F1 (real), 2 bytes F1 (imag)
...
2 bytes Fn (real), 2 bytes Fn (imag)
Then, reverse taps coefficients:
2 bytes D1 (real), 2 bytes D1 (imag)
...
2 bytes Dm (real), 2 bytes Dm (imag)
The equalizer coefficients are considered signed 16-bit
integers in the range from -32768 (0x8000) to 32767
(0x7FFF).
DOCSIS specifications require up to a maximum of
64 equalizer taps (n + m); therefore, this object size
can get up 260 bytes (4 + 4x64).
The minimum object size (other than zero) for a t-spaced
tap with a minimum of 8 symbols will be 36 (4 + 4x8).
33. DOT3-OAM-MIB (revision 2007-06-14 00:00)
The MIB module for managing the new Ethernet OAM features introduced
by the Ethernet in the First Mile taskforce (IEEE 802.3ah). The
functionality presented here is based on IEEE 802.3ah [802.3ah],
released in October, 2004. [802.3ah] was prepared as an addendum to
the standing version of IEEE 802.3 [802.3-2002]. Since then,
[802.3ah] has been merged into the base IEEE 802.3 specification in
[802.3-2005]. In particular, this MIB focuses on the new OAM
functions introduced in Clause 57 of [802.3ah]. The OAM
functionality of Clause 57 is controlled by new management attributes
introduced in Clause 30 of [802.3ah]. The OAM functions are not
Expires August 17, 2014 [Page 73]
Internet-Draft SMIv2 Textual Conventions February 2014
specific to any particular Ethernet physical layer, and can be
generically applied to any Ethernet interface of [802.3-2002]. An
Ethernet OAM protocol data unit is a valid Ethernet frame with a
destination MAC address equal to the reserved MAC address for Slow
Protocols (See 43B of [802.3ah]), a lengthOrType field equal to the
reserved type for Slow Protocols, and a Slow Protocols subtype equal
to that of the subtype reserved for Ethernet OAM. OAMPDU is used
throughout this document as an abbreviation for Ethernet OAM protocol
data unit. The following reference is used throughout this MIB
module: [802.3ah] refers to: IEEE Std 802.3ah-2004: 'Draft amendment
to - Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks -
Specific requirements - Part 3: Carrier sense multiple access with
collision detection (CSMA/CD) access method and physical layer
specifications - Media Access Control Parameters, Physical Layers and
Management Parameters for subscriber access networks', October 2004.
[802.3-2002] refers to: IEEE Std 802.3-2002: 'Information technology
- Telecommunications and information exchange between systems - Local
and metropolitan area networks - Specific requirements - Part 3:
Carrier sense multiple access with collision detection (CSMA/CD)
access method and physical layer specifications - Media Access
Control Parameters, Physical Layers and Management Parameters for
subscriber access networks', March 2002. [802.3-2005] refers to: IEEE
Std 802.3-2005: 'Information technology - Telecommunications and
information exchange between systems - Local and metropolitan area
networks - Specific requirements - Part 3: Carrier sense multiple
access with collision detection (CSMA/CD) access method and physical
layer specifications - Media Access Control Parameters, Physical
Layers and Management Parameters for subscriber access networks',
December 2005. [802-2001] refers to: 'IEEE Standard for LAN/MAN
(Local Area Network/Metropolitan Area Network): Overview and
Architecture', IEEE 802, June 2001. Copyright (c) The IETF Trust
(2007). This version of this MIB module is part of RFC 4878; See the
RFC itself for full legal notices.
33.1. EightOTwoOui
24-bit Organizationally Unique Identifier. Information on
OUIs can be found in IEEE 802-2001 [802-2001], Clause 9.
34. DSMON-MIB (revision 2002-05-31 00:00)
This module defines Remote Monitoring MIB extensions for
Differentiated Services enabled networks. RMON DIFFSERV DSCP
statistics * Per Counter Aggregation Group * Per Protocol Per Counter
Aggregation Group * Per Counter Aggregation Group Per Host * Per
Expires August 17, 2014 [Page 74]
Internet-Draft SMIv2 Textual Conventions February 2014
Counter Aggregation Group Per Host-Pair In order to maintain the RMON
'look-and-feel' and semantic consistency, some of the text from the
RMON-2 and HC-RMON MIBs by Steve Waldbusser has been adapted for use
in this MIB.
34.1. DsmonCounterAggGroupIndex
This TC describes a data type which identifies a DSMON
counter aggregation group, which is an arbitrary grouping of
conceptual counters, for monitoring purposes only. The
range for this data type begins with zero (instead of
one), to allow for a direct mapping between counter
indexing schemes that start at zero (e.g. DSCP values in
packets) and counter aggregation group values.
34.2. DsmonCounterAggProfileIndex
This TC describes a data type which identifies a DSMON
counter aggregation profile, which is a set of counter
aggregation group assignments for each of the 64 DSCP
values, for a particular statistical collection.
35. DVB-RCS-MIB (revision 2010-02-16 12:00)
DVB-RCS MIB subtree. This MIB module applies to equipment that is a
Return Channel Satellite Terminal (RCST), defined in the Digital
Video Broadcasting Return Channel via Satellite system (DVB-RCS)
standard (ETSI EN 301 790 Digital Video Broadcasting (DVB);
Interaction Channel for Satellite Distribution Systems, European
Telecommunications Standards Institute (ETSI)). It defines a set of
MIB objects to characterize the behavior and performance of network-
layer entities implementing DVB-RCS. This MIB module is intended to
be used by DVB-RCS equipment following the SatLabs System
Recommendations, defined by the SatLabs Group and available at
www.satlabs.org. Note that, if not stated otherwise in the object
DESCRIPTION clause, all writable objects are persistent. Copyright
(C) The IETF Trust (2010). This version of this MIB module is part
of RFC 5728; see the RFC itself for full legal notices.
35.1. DvbRcsSatLabsProfileMap
Expires August 17, 2014 [Page 75]
Internet-Draft SMIv2 Textual Conventions February 2014
This textual convention enumerates the declaration of
the SatLabs-defined terminal profiles. The mapping to
the profiles is to be understood as described here. (0)
refers to the most significant bit.
dvbs(0) -> DVBS profile (DVB-S support)
dvbs2ccm(1) -> DVB-S2 CCM profile (CCM support)
dvbs2acm(2) -> DVB-S2 ACM profile (CCM, VCM and ACM
support)
35.2. DvbRcsSatLabsOptionMap
This textual convention enumerates the declaration of
the SatLabs-defined options. A value of 1 indicates
that the respective option is supported. The mapping
to the options is to be understood as described here.
(0) refers to the most significant bit.
mpegTrf(0) -> MPEG_TRF
coarseSync(1) -> COARSE_SYNC
wideHop(2) -> WIDE_HOPP
fastHop(3) -> FAST_HOPP
dynamicMfTdma(4) -> Dynamic_MF_TDMA
contentionSync(5) -> CONTENTION_SYNC
qpskLow(6) -> QPSKLOW
mod16Apsk(7) -> 16APSK
mod32Apsk(8) -> 32APSK
normalFec(9) -> NORMALFEC
multiTs(10) -> MULTITS
gsTs(11) -> GSTS
enhQoS(12) -> ENHQOS
pep(13) -> PEP
http(14) -> HTTP
ftp(15) -> FTP
dns(16) -> DNS
chIdStrict(17) -> CHID_STRICT
nlid(18) -> NLID
snmpMisc(19) -> SNMPMISC
The support of specific options mandates the support of
specific objects and access levels.
Expires August 17, 2014 [Page 76]
Internet-Draft SMIv2 Textual Conventions February 2014
35.3. DvbRcsSatLabsFeatureMap
This textual convention enumerates the declaration
of the SatLabs-specified compatibility and
configuration features. A value of 1 indicates that
the respective feature is supported. The mapping to
the features is to be understood as described here.
(0) refers to the most significant bit.
rcstPara(0) -> RCST_PARA feature
installLog(1) -> INSTALL_LOG feature
enhClassifier(2) -> ENHCLASSIFIER feature
routeId(3) -> ROUTE_ID feature
oduList(4) -> ODULIST feature
extNetwork(5) -> EXTNETWORK feature
extControl(6) -> EXTCONTROL feature
extConfig(7) -> EXTCONFIG feature
extStatus(8) -> EXTSTATUS feature
mpaf(9) -> MPAF feature
The support of specific features mandates the support of
specific objects and access levels.
36. EBN-MIB (revision 1998-04-28 18:00)
The MIB Module for Extended Border Node
36.1. SnaNAUWildcardName
Fully-qualified network NAU name. Entries take one of three
forms:
- Explicit entries do not contain the character '*'.
- Partial Wildcard entries have the form 'ccc*', where
'ccc' represents one to sixteen characters in a legal
SNA NAU Name.
- A full wildcard consists of a single character '*'.
Because the characters allowed in an SNA NAU name come from
a restricted character set, these names are not subject to
internationalization.
37. EFM-CU-MIB (revision 2007-11-14 00:00)
The objects in this MIB module are used to manage the Ethernet in the
Expires August 17, 2014 [Page 77]
Internet-Draft SMIv2 Textual Conventions February 2014
First Mile (EFM) Copper (EFMCu) Interfaces 2BASE-TL and 10PASS-TS,
defined in IEEE Std. 802.3ah-2004, which is now a part of IEEE Std.
802.3-2005. The following references are used throughout this MIB
module: [802.3ah] refers to: IEEE Std 802.3ah-2004: 'IEEE Standard
for Information technology - Telecommunications and information
exchange between systems - Local and metropolitan area networks -
Specific requirements - Part 3: Carrier Sense Multiple Access with
Collision Detection (CSMA/CD) Access Method and Physical Layer
Specifications - Amendment: Media Access Control Parameters, Physical
Layers and Management Parameters for Subscriber Access Networks', 07
September 2004. Of particular interest are Clause 61, 'Physical
Coding Sublayer (PCS) and common specifications, type 10PASS-TS and
type 2BASE-TL', Clause 30, 'Management', Clause 45, 'Management Data
Input/Output (MDIO) Interface', Annex 62A, 'PMD profiles for
10PASS-TS' and Annex 63A, 'PMD profiles for 2BASE-TL'. [G.991.2]
refers to: ITU-T Recommendation G.991.2: 'Single-pair High-speed
Digital Subscriber Line (SHDSL) transceivers', December 2003. [ANFP]
refers to: NICC Document ND1602:2005/08: 'Specification of the Access
Network Frequency Plan (ANFP) applicable to transmission systems used
on the BT Access Network,' August 2005. The following normative
documents are quoted by the DESCRIPTION clauses in this MIB module:
[G.993.1] refers to: ITU-T Recommendation G.993.1: 'Very High speed
Digital Subscriber Line transceivers', June 2004. [T1.424] refers
to: ANSI T1.424-2004: 'Interface Between Networks and Customer
Installation Very-high-bit-rate Digital Subscriber Lines (VDSL)
Metallic Interface (DMT Based)', June 2004. [TS 101 270-1] refers
to: ETSI TS 101 270-1: 'Transmission and Multiplexing (TM); Access
transmission systems on metallic access cables; Very high speed
Digital Subscriber Line (VDSL); Part 1: Functional requirements',
October 2005. Naming Conventions: Atn - Attenuation CO - Central
Office CPE - Customer Premises Equipment EFM - Ethernet in the First
Mile EFMCu - EFM Copper MDIO - Management Data Input/Output Mgn -
Margin PAF - PME Aggregation Function PBO - Power Back-Off PCS -
Physical Coding Sublayer PMD - Physical Medium Dependent PME -
Physical Medium Entity PSD - Power Spectral Density SNR - Signal to
Noise Ratio TCPAM - Trellis Coded Pulse Amplitude Modulation
Copyright (C) The IETF Trust (2007). This version of this MIB module
is part of RFC 5066; see the RFC itself for full legal notices.
37.1. EfmProfileIndex
A unique value, greater than zero, for each PME configuration
profile in the managed EFMCu port. It is RECOMMENDED that
values are assigned contiguously starting from 1. The value
for each profile MUST remain constant at least from one
re-initialization of the entity's network management system
to the next re-initialization.
Expires August 17, 2014 [Page 78]
Internet-Draft SMIv2 Textual Conventions February 2014
37.2. EfmProfileIndexOrZero
This textual convention is an extension of the
EfmProfileIndex convention. The latter defines a greater than
zero value used to identify a PME profile in the managed EFMCu
port. This extension permits the additional value of zero.
The value of zero is object-specific and MUST therefore be
defined as part of the description of any object that uses
this syntax.
Examples of the usage of zero value might include situations
where the current operational profile is unknown.
37.3. EfmProfileIndexList
This textual convention represents a list of up to 6
EfmProfileIndex values, any of which can be chosen for
configuration of a PME in a managed EFMCu port.
The EfmProfileIndex textual convention defines a greater than
zero value used to identify a PME profile.
The value of this object is a concatenation of zero or
more (up to 6) octets, where each octet contains an 8-bit
EfmProfileIndex value.
A zero-length octet string is object-specific and MUST
therefore be defined as part of the description of any object
that uses this syntax. Examples of the usage of a zero-length
value might include situations where an object using this
textual convention is irrelevant for a specific EFMCu port
type.
37.4. EfmTruthValueOrUnknown
This textual convention is an extension of the TruthValue
convention. The latter defines a boolean value with possible
values of true(1) and false(2). This extension permits the
additional value of unknown(0), which can be returned as the
result of a GET operation when an exact true or false value
of the object cannot be determined.
38. ENTITY-MIB (revision 2013-04-05 00:00)
The MIB module for representing multiple logical entities supported
by a single SNMP agent. Copyright (c) 2013 IETF Trust and the
persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
Expires August 17, 2014 [Page 79]
Internet-Draft SMIv2 Textual Conventions February 2014
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
38.1. PhysicalIndex
An arbitrary value that uniquely identifies the physical
entity. The value should be a small positive integer.
Index values for different physical entities are not
necessarily contiguous.
38.2. PhysicalIndexOrZero
This TEXTUAL-CONVENTION is an extension of the
PhysicalIndex convention, which defines a greater than zero
value used to identify a physical entity. This extension
permits the additional value of zero. The semantics of the
value zero are object-specific and must, therefore, be
defined as part of the description of any object that uses
this syntax. Examples of the usage of this extension are
situations where none or all physical entities need to be
referenced.
38.3. SnmpEngineIdOrNone
A specially formatted SnmpEngineID string for use with the
Entity MIB.
If an instance of an object of SYNTAX SnmpEngineIdOrNone has
a non-zero length, then the object encoding and semantics
are defined by the SnmpEngineID TEXTUAL-CONVENTION (see STD
62, RFC 3411).
If an instance of an object of SYNTAX SnmpEngineIdOrNone
contains a zero-length string, then no appropriate
SnmpEngineID is associated with the logical entity (i.e.,
SNMPv3 is not supported).
Expires August 17, 2014 [Page 80]
Internet-Draft SMIv2 Textual Conventions February 2014
38.4. PhysicalClass (deprecated)
Starting with version 4 of the ENTITY-MIB, this TC is
deprecated, and the usage of the IANAPhysicalClass TC from
the IANA-ENTITY-MIB is recommended instead.
An enumerated value that provides an indication of the
general hardware type of a particular physical entity.
There are no restrictions as to the number of
entPhysicalEntries of each entPhysicalClass, which must be
instantiated by an agent.
The enumeration 'other' is applicable if the physical entity
class is known but does not match any of the supported
values.
The enumeration 'unknown' is applicable if the physical
entity class is unknown to the agent.
The enumeration 'chassis' is applicable if the physical
entity class is an overall container for networking
equipment. Any class of physical entity, except a stack,
may be contained within a chassis; a chassis may only
be contained within a stack.
The enumeration 'backplane' is applicable if the physical
entity class is some sort of device for aggregating and
forwarding networking traffic, such as a shared backplane in
a modular ethernet switch. Note that an agent may model a
backplane as a single physical entity, which is actually
implemented as multiple discrete physical components (within
a chassis or stack).
The enumeration 'container' is applicable if the physical
entity class is capable of containing one or more removable
physical entities, possibly of different types. For
example, each (empty or full) slot in a chassis will be
modeled as a container. Note that all removable physical
entities should be modeled within a container entity, such
as field-replaceable modules, fans, or power supplies. Note
that all known containers should be modeled by the agent,
including empty containers.
Expires August 17, 2014 [Page 81]
Internet-Draft SMIv2 Textual Conventions February 2014
The enumeration 'powerSupply' is applicable if the physical
entity class is a power-supplying component.
The enumeration 'fan' is applicable if the physical entity
class is a fan or other heat-reduction component.
The enumeration 'sensor' is applicable if the physical
entity class is some sort of sensor, such as a temperature
sensor within a router chassis.
The enumeration 'module' is applicable if the physical
entity class is some sort of self-contained sub-system. If
the enumeration 'module' is removable, then it should be
modeled within a container entity; otherwise, it should be
modeled directly within another physical entity (e.g., a
chassis or another module).
The enumeration 'port' is applicable if the physical entity
class is some sort of networking port capable of receiving
and/or transmitting networking traffic.
The enumeration 'stack' is applicable if the physical entity
class is some sort of super-container (possibly virtual)
intended to group together multiple chassis entities. A
stack may be realized by a 'virtual' cable, a real
interconnect cable, attached to multiple chassis, or may in
fact be comprised of multiple interconnect cables. A stack
should not be modeled within any other physical entities,
but a stack may be contained within another stack. Only
chassis entities should be contained within a stack.
The enumeration 'cpu' is applicable if the physical entity
class is some sort of central processing unit.
39. ENTITY-SENSOR-MIB (revision 2002-12-16 00:00)
This module defines Entity MIB extensions for physical sensors.
Copyright (C) The Internet Society (2002). This version of this MIB
module is part of RFC 3433; see the RFC itself for full legal
notices.
39.1. EntitySensorDataType
Expires August 17, 2014 [Page 82]
Internet-Draft SMIv2 Textual Conventions February 2014
An object using this data type represents the Entity Sensor
measurement data type associated with a physical sensor
value. The actual data units are determined by examining an
object of this type together with the associated
EntitySensorDataScale object.
An object of this type SHOULD be defined together with
objects of type EntitySensorDataScale and
EntitySensorPrecision. Together, associated objects of
these three types are used to identify the semantics of an
object of type EntitySensorValue.
Valid values are:
other(1): a measure other than those listed below
unknown(2): unknown measurement, or arbitrary,
relative numbers
voltsAC(3): electric potential
voltsDC(4): electric potential
amperes(5): electric current
watts(6): power
hertz(7): frequency
celsius(8): temperature
percentRH(9): percent relative humidity
rpm(10): shaft revolutions per minute
cmm(11),: cubic meters per minute (airflow)
truthvalue(12): value takes { true(1), false(2) }
39.2. EntitySensorDataScale
An object using this data type represents a data scaling
factor, represented with an International System of Units
(SI) prefix. The actual data units are determined by
examining an object of this type together with the
associated EntitySensorDataType object.
An object of this type SHOULD be defined together with
objects of type EntitySensorDataType and
EntitySensorPrecision. Together, associated objects of
these three types are used to identify the semantics of an
object of type EntitySensorValue.
Expires August 17, 2014 [Page 83]
Internet-Draft SMIv2 Textual Conventions February 2014
39.3. EntitySensorPrecision
An object using this data type represents a sensor
precision range.
An object of this type SHOULD be defined together with
objects of type EntitySensorDataType and
EntitySensorDataScale. Together, associated objects of
these three types are used to identify the semantics of an
object of type EntitySensorValue.
If an object of this type contains a value in the range 1 to
9, it represents the number of decimal places in the
fractional part of an associated EntitySensorValue fixed-
point number.
If an object of this type contains a value in the range -8
to -1, it represents the number of accurate digits in the
associated EntitySensorValue fixed-point number.
The value zero indicates the associated EntitySensorValue
object is not a fixed-point number.
Agent implementors must choose a value for the associated
EntitySensorPrecision object so that the precision and
accuracy of the associated EntitySensorValue object is
correctly indicated.
For example, a physical entity representing a temperature
sensor that can measure 0 degrees to 100 degrees C in 0.1
degree increments, +/- 0.05 degrees, would have an
EntitySensorPrecision value of '1', an EntitySensorDataScale
value of 'units(9)', and an EntitySensorValue ranging from
'0' to '1000'. The EntitySensorValue would be interpreted
as 'degrees C * 10'.
39.4. EntitySensorValue
Expires August 17, 2014 [Page 84]
Internet-Draft SMIv2 Textual Conventions February 2014
An object using this data type represents an Entity Sensor
value.
An object of this type SHOULD be defined together with
objects of type EntitySensorDataType, EntitySensorDataScale
and EntitySensorPrecision. Together, associated objects of
those three types are used to identify the semantics of an
object of this data type.
The semantics of an object using this data type are
determined by the value of the associated
EntitySensorDataType object.
If the associated EntitySensorDataType object is equal to
'voltsAC(3)', 'voltsDC(4)', 'amperes(5)', 'watts(6),
'hertz(7)', 'celsius(8)', or 'cmm(11)', then an object of
this type MUST contain a fixed point number ranging from
-999,999,999 to +999,999,999. The value -1000000000
indicates an underflow error. The value +1000000000
indicates an overflow error. The EntitySensorPrecision
indicates how many fractional digits are represented in the
associated EntitySensorValue object.
If the associated EntitySensorDataType object is equal to
'percentRH(9)', then an object of this type MUST contain a
number ranging from 0 to 100.
If the associated EntitySensorDataType object is equal to
'rpm(10)', then an object of this type MUST contain a number
ranging from -999,999,999 to +999,999,999.
If the associated EntitySensorDataType object is equal to
'truthvalue(12)', then an object of this type MUST contain
either the value 'true(1)' or the value 'false(2)'.
If the associated EntitySensorDataType object is equal to
'other(1)' or unknown(2)', then an object of this type MUST
contain a number ranging from -1000000000 to 1000000000.
39.5. EntitySensorStatus
Expires August 17, 2014 [Page 85]
Internet-Draft SMIv2 Textual Conventions February 2014
An object using this data type represents the operational
status of a physical sensor.
The value 'ok(1)' indicates that the agent can obtain the
sensor value.
The value 'unavailable(2)' indicates that the agent
presently cannot obtain the sensor value.
The value 'nonoperational(3)' indicates that the agent
believes the sensor is broken. The sensor could have a hard
failure (disconnected wire), or a soft failure such as out-
of-range, jittery, or wildly fluctuating readings.
40. ENTITY-STATE-TC-MIB (revision 2005-11-22 00:00)
This MIB defines state textual conventions. Copyright (C) The
Internet Society 2005. This version of this MIB module is part of
RFC 4268; see the RFC itself for full legal notices.
40.1. EntityAdminState
Represents the various possible administrative states.
A value of 'locked' means the resource is administratively
prohibited from use. A value of 'shuttingDown' means that
usage is administratively limited to current instances of
use. A value of 'unlocked' means the resource is not
administratively prohibited from use. A value of
'unknown' means that this resource is unable to
report administrative state.
40.2. EntityOperState
Expires August 17, 2014 [Page 86]
Internet-Draft SMIv2 Textual Conventions February 2014
Represents the possible values of operational states.
A value of 'disabled' means the resource is totally
inoperable. A value of 'enabled' means the resource
is partially or fully operable. A value of 'testing'
means the resource is currently being tested
and cannot therefore report whether it is operational
or not. A value of 'unknown' means that this
resource is unable to report operational state.
40.3. EntityUsageState
Represents the possible values of usage states.
A value of 'idle' means the resource is servicing no
users. A value of 'active' means the resource is
currently in use and it has sufficient spare capacity
to provide for additional users. A value of 'busy'
means the resource is currently in use, but it
currently has no spare capacity to provide for
additional users. A value of 'unknown' means
that this resource is unable to report usage state.
40.4. EntityAlarmStatus
Expires August 17, 2014 [Page 87]
Internet-Draft SMIv2 Textual Conventions February 2014
Represents the possible values of alarm status.
An Alarm [RFC3877] is a persistent indication
of an error or warning condition.
When no bits of this attribute are set, then no active
alarms are known against this entity and it is not under
repair.
When the 'value of underRepair' is set, the resource is
currently being repaired, which, depending on the
implementation, may make the other values in this bit
string not meaningful.
When the value of 'critical' is set, one or more critical
alarms are active against the resource. When the value
of 'major' is set, one or more major alarms are active
against the resource. When the value of 'minor' is set,
one or more minor alarms are active against the resource.
When the value of 'warning' is set, one or more warning
alarms are active against the resource. When the value
of 'indeterminate' is set, one or more alarms of whose
perceived severity cannot be determined are active
against this resource.
A value of 'unknown' means that this resource is
unable to report alarm state.
40.5. EntityStandbyStatus
Represents the possible values of standby status.
A value of 'hotStandby' means the resource is not
providing service, but it will be immediately able to
take over the role of the resource to be backed up,
without the need for initialization activity, and will
contain the same information as the resource to be
backed up. A value of 'coldStandy' means that the
resource is to back up another resource, but will not
be immediately able to take over the role of a resource
to be backed up, and will require some initialization
activity. A value of 'providingService' means the
resource is providing service. A value of
'unknown' means that this resource is unable to
report standby state.
Expires August 17, 2014 [Page 88]
Internet-Draft SMIv2 Textual Conventions February 2014
41. FCIP-MGMT-MIB (revision 2006-02-06 00:00)
The module defines management information specific to FCIP devices.
Copyright(C) The Internet Society (2006). This version of this MIB
module is part of RFC 4404; see the RFC itself for full legal
notices.
41.1. FcipDomainIdInOctetForm
The Domain ID of a FC entity in octet form
to support the concatenation(000000h||Domain_ID)
format defined in the FSPF routing protocol.
41.2. FcipEntityMode
The type of port mode provided by an FCIP Entity
for an FCIP Link. An FCIP Entity can be an E-Port
mode for one of its FCIP Link Endpoints or a B-Port
mode for another of its FCIP Link Endpoints.
41.3. FcipEntityId
The FCIP entity identifier as defined in RFC 3821.
42. FC-MGMT-MIB (revision 2005-04-26 00:00)
This module defines management information specific to Fibre Channel-
attached devices. Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC 4044; see the RFC itself
for full legal notices.
42.1. FcNameIdOrZero
The World Wide Name (WWN) associated with a Fibre Channel
(FC) entity. WWNs were initially defined as 64-bits in
length. The latest definition (for future use) is 128-bits
long. The zero-length string value is used in
circumstances in which the WWN is unassigned/unknown.
42.2. FcAddressIdOrZero
Expires August 17, 2014 [Page 89]
Internet-Draft SMIv2 Textual Conventions February 2014
A 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.
42.3. FcDomainIdOrZero
The Domain Id (of an FC switch), or zero if the no Domain
Id has been assigned.
42.4. FcPortType
The type of a Fibre Channel port, as indicated by the use
of the appropriate value assigned by IANA.
42.5. FcClasses
A set of Fibre Channel classes of service.
42.6. FcBbCredit
The buffer-to-buffer credit of an FC port.
42.7. FcBbCreditModel
The buffer-to-buffer credit model of an Fx_Port.
42.8. FcDataFieldSize
The Receive Data Field Size associated with an FC port.
42.9. FcUnitFunctions
Expires August 17, 2014 [Page 90]
Internet-Draft SMIv2 Textual Conventions February 2014
A set of functions that a Fibre Channel Interconnect
Element or Platform might perform. A value with no bits set
indicates the function(s) are unknown. The individual bits
have the following meanings:
other - none of the following.
hub - a device that interconnects L_Ports, but does not
operate as an FL_Port.
switch - a fabric element conforming to the Fibre Channel
switch fabric set of standards (e.g., [FC-SW-3]).
bridge - a device that encapsulates Fibre Channel frames
within another protocol (e.g., [FC-BB], FC-BB-2).
gateway - a device that converts an FC-4 to another protocol
(e.g., FCP to iSCSI).
host - a computer system that provides end users with
services such as computation and storage access.
storageSubsys - an integrated collection of storage
controllers, storage devices, and necessary software that
provides storage services to one or more hosts.
storageAccessDev - a device that provides storage management
and access for heterogeneous hosts and heterogeneous devices
(e.g., medium changer).
nas - a device that connects to a network and provides file
access services.
wdmux - a device that modulates/demodulates each of several
data streams (e.g., Fibre Channel protocol data streams)
onto/from a different part of the light spectrum in an
optical fiber.
storageDevice - a disk/tape/etc. device (without the
controller and/or software required for it to be a
'storageSubsys').
43. FIBRE-CHANNEL-FE-MIB (revision 2000-05-18 00:00)
The MIB module for Fibre Channel Fabric Element.
Expires August 17, 2014 [Page 91]
Internet-Draft SMIv2 Textual Conventions February 2014
43.1. MilliSeconds
Represents time unit value in milliseconds.
43.2. MicroSeconds
Represents time unit value in microseconds.
43.3. FcNameId
Represents the Worldwide Name associated with
a Fibre Channel (FC) entity.
43.4. FcAddressId
Represents Fibre Channel Address ID, a 24-bit
value unique within the address space of a Fabric.
43.5. FcRxDataFieldSize
Represents the receive data field size of an
NxPort or FxPort.
43.6. FcBbCredit
Represents the buffer-to-buffer credit of an
NxPort or FxPort.
43.7. FcphVersion
Represents the version of FC-PH supported by an
NxPort or FxPort.
43.8. FcStackedConnMode
Represents an enumerated value used to indicate
the Class 1 Stacked Connect Mode supported by
an NxPort or FxPort.
Expires August 17, 2014 [Page 92]
Internet-Draft SMIv2 Textual Conventions February 2014
43.9. FcCosCap
Represents the class of service capability of an
NxPort or FxPort.
43.10. FcFeModuleCapacity
Represents the maximum number of modules within
a Fabric Element.
43.11. FcFeFxPortCapacity
Represents the maximum number of FxPorts within
a module.
43.12. FcFeModuleIndex
Represents the module index within a conceptual table.
43.13. FcFeFxPortIndex
Represents the FxPort index within a conceptual table.
43.14. FcFeNxPortIndex
Represents the NxPort index within a conceptual table.
43.15. FcBbCreditModel
Represents the BB_Credit model of an FxPort.
44. FLOAT-TC-MIB (revision 2011-07-27 00:00)
Textual conventions for the representation of floating-point numbers.
Copyright (c) 2011 IETF Trust and the persons identified as authors
of the code. All rights reserved. Redistribution and use in source
and binary forms, with or without modification, is permitted pursuant
to, and subject to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info).
Expires August 17, 2014 [Page 93]
Internet-Draft SMIv2 Textual Conventions February 2014
This version of this MIB module is part of RFC 6340; see the RFC
itself for full legal notices.
44.1. Float32TC
This type represents a 32-bit (4-octet) IEEE
floating-point number in binary interchange format.
44.2. Float64TC
This type represents a 64-bit (8-octet) IEEE
floating-point number in binary interchange format.
44.3. Float128TC
This type represents a 128-bit (16-octet) IEEE
floating-point number in binary interchange format.
45. FLOW-METER-MIB (revision 1999-10-25 00:00)
MIB for the RTFM Traffic Flow Meter.
45.1. UTF8OwnerString
An administratively assigned name for the owner of a
resource, conceptually the same as OwnerString in the RMON
MIB [RMON-MIB].
To facilitate internationalisation, this name 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 the UTF-8 standard [UTF-8].
45.2. PeerType
Indicates the type of a PeerAddress (see below). The values
used are from the 'Address Family Numbers' section of the
Assigned Numbers RFC [ASG-NBR]. Peer types from other address
families may also be used, provided only that they are
identified by their assigned Address Family numbers.
Expires August 17, 2014 [Page 94]
Internet-Draft SMIv2 Textual Conventions February 2014
45.3. PeerAddress
Specifies the value of a peer address for various network
protocols. Address format depends on the actual protocol,
as indicated below:
IPv4: ipv4(1)
4-octet IpAddress (defined in the SNMPv2 SMI [RFC2578])
IPv6: ipv6(2)
16-octet IpAddress (defined in the
IPv6 Addressing RFC [V6-ADDR])
CLNS: nsap(3)
NsapAddress (defined in the SNMPv2 SMI [RFC2578])
Novell: ipx(11)
4-octet Network number,
6-octet Host number (MAC address)
AppleTalk: appletalk(12)
2-octet Network number (sixteen bits),
1-octet Host number (eight bits)
DECnet: decnet(13)
1-octet Area number (in low-order six bits),
2-octet Host number (in low-order ten bits)
45.4. AdjacentType
Indicates the type of an adjacent address. May be a medium
type or (if metering is taking place inside a tunnel) a
PeerType (see above).
The values used for IEEE 802 medium types are from the 'Network
Management Parameters (ifType definitions)' section of the
Assigned Numbers RFC [ASG-NBR]. Other medium types may also
be used, provided only that they are identified by their
assigned ifType numbers.
45.5. AdjacentAddress
Expires August 17, 2014 [Page 95]
Internet-Draft SMIv2 Textual Conventions February 2014
Specifies the value of an adjacent address. May be a Medium
Access Control (MAC) address or (if metering is taking place
inside a tunnel) a PeerAddress (see above).
MAC Address format depends on the actual medium, as follows:
Ethernet: ethernet(7)
6-octet 802.3 MAC address in 'canonical' order
Token Ring: tokenring(9)
6-octet 802.5 MAC address in 'canonical' order
FDDI: fddi(15)
FddiMACLongAddress, i.e. a 6-octet MAC address
in 'canonical' order (defined in [FDDI-MIB])
45.6. TransportType
Indicates the type of a TransportAddress (see below). Values
will depend on the actual protocol; for IP they will be those
given in the 'Protocol Numbers' section of the Assigned Numbers
RFC [ASG-NBR], including icmp(1), tcp(6) and udp(17).
45.7. TransportAddress
Specifies the value of a transport address for various
network protocols. Format as follows:
IP:
2-octet UDP or TCP port number
Other protocols:
2-octet port number
45.8. RuleAddress
Specifies the value of an address. Is a superset of
MediumAddress, PeerAddress and TransportAddress.
45.9. FlowAttributeNumber
Uniquely identifies an attribute within a flow data record.
Expires August 17, 2014 [Page 96]
Internet-Draft SMIv2 Textual Conventions February 2014
45.10. RuleAttributeNumber
Uniquely identifies an attribute which may be tested in
a rule. These include attributes whose values come directly
from (or are computed from) the flow's packets, and the five
'meter' variables used to hold an Attribute Number.
45.11. ActionNumber
Uniquely identifies the action of a rule, i.e. the Pattern
Matching Engine's opcode number. Details of the opcodes
are given in the 'Traffic Flow Measurement: Architecture'
document [RTFM-ARC].
46. FORCES-MIB (revision 2010-03-10 00:00)
This MIB module contains managed object definitions for the ForCES
Protocol. Copyright (c) 2010 IETF Trust and the persons identified
as authors of the code. All rights reserved. Redistribution and use
in source and binary forms, with or without modification, is
permitted pursuant to, and subject to the license terms contained in,
the Simplified BSD License set forth in Section 4.c of the IETF
Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). This version of this MIB
module is part of RFC 5813; see the RFC itself for full legal
notices.
46.1. ForcesID
The ForCES identifier is a 4-octet quantity.
46.2. ForcesProtocolVersion
ForCES protocol version number.
The version numbers used are defined in the
specifications of the respective protocol:
1 - ForCESv1, RFC 5810.
47. FRAME-RELAY-DTE-MIB (revision 1997-05-01 02:29)
The MIB module to describe the use of a Frame Relay interface by a
DTE.
Expires August 17, 2014 [Page 97]
Internet-Draft SMIv2 Textual Conventions February 2014
47.1. DLCI
The range of DLCI values. Note that this varies by
interface configuration; normally, interfaces may use
0..1023, but may be configured to use ranges as large
as 0..2^23.
48. FR-MFR-MIB (revision 2000-11-30 00:00)
This is the MIB used to control and monitor the multilink frame relay
(MFR) function described in FRF.16.
48.1. MfrBundleLinkState
The possible states for a bundle link, as defined in
Annex A of FRF.16.
49. FRSLD-MIB (revision 2002-01-03 00:00)
The MIB module to describe generic objects for FRF.13 Frame Relay
Service Level Definitions.
49.1. FrsldTxRP
The reference point a PVC uses for calculation
of transmitter related statistics.
The valid values for this type of object are as follows:
- srcLocalRP(1) for the local source
- ingTxLocalRP(2) for the local ingress queue input
- tpTxLocalRP(3) for the local traffic policing
- eqiTxLocalRP(4) for the local egress queue input
- eqoTxLocalRP(5) for the local egress queue output
- otherTxLocalRP(6) for any other local transmit point
- srcRemoteRP(7) for the remote source
- ingTxLocalRP(8) for the remote ingress queue input
- tpTxLocalRP(9) for the remote traffic policing
- eqiTxRemoteRP(10) for the remote egress queue input
- eqoTxRemoteRP(11) for the remote egress queue output
- otherTxRemoteRP(12) for any other remote xmit point
Expires August 17, 2014 [Page 98]
Internet-Draft SMIv2 Textual Conventions February 2014
49.2. FrsldRxRP
The reference point a PVC uses for calculation
of receiver related statistics.
The valid values for this object are as follows:
- desLocalRP(1) for the local destination
- ingRxLocalRP(2) for the local ingress queue input
- tpRxLocalRP(3) for the local traffic policing
- eqiRxLocalRP(4) for the local egress queue input
- eqoRxLocalRP(5) for the local egress queue output
- otherRxLocalRP(6) for any other local receive point
- desRemoteRP(7) for the remote destination
- ingRxRemoteRP(8) for the remote ingress input
- tpRxRemoteRP(9) for the remote traffic policing
- eqiRxRemoteRP(10) for the remote egress queue input
- eqoRxRemoteRP(11) for the remote egress queue output
- otherRxRemoteRP(12) for any other remote receive point
50. GMPLS-TC-STD-MIB (revision 2007-02-28 00:00)
Copyright (C) The IETF Trust (2007). This version of this MIB module
is part of RFC 4801; see the RFC itself for full legal notices. This
MIB module defines TEXTUAL-CONVENTIONs for concepts used in
Generalized Multiprotocol Label Switching (GMPLS) networks.
50.1. GmplsFreeformLabelTC
This TEXTUAL-CONVENTION can be used as the syntax of an object
that contains any GMPLS Label. Objects with this syntax can be
used to represent labels that have label types that are not
defined in any RFCs. The freeform GMPLS Label may also be used
by systems that do not wish to represent labels that have
label types defined in RFCs using type-specific syntaxes.
50.2. GmplsLabelTypeTC
Expires August 17, 2014 [Page 99]
Internet-Draft SMIv2 Textual Conventions February 2014
Determines the interpretation that should be applied to an
object that encodes a label. The possible types are:
gmplsMplsLabel(1) - The label is an MPLS Packet, Cell,
or Frame Label and is encoded as
described for the TEXTUAL-
CONVENTION MplsLabel defined in
RFC 3811.
gmplsPortWavelengthLabel(2) - The label is a Port or Wavelength
Label as defined in RFC 3471.
gmplsFreeformLabel(3) - The label is any form of label
encoded as an OCTET STRING using
the TEXTUAL-CONVENTION
GmplsFreeformLabel.
gmplsSonetLabel(4) - The label is a Synchronous Optical
Network (SONET) Label as
defined in RFC 4606.
gmplsSdhLabel(5) - The label is a Synchronous Digital
Hierarchy (SDH) Label as defined
in RFC 4606.
gmplsWavebandLabel(6) - The label is a Waveband Label as
defined in RFC 3471.
50.3. GmplsSegmentDirectionTC
The direction of data flow on an Label Switched Path (LSP)
segment with respect to the head of the LSP.
Where an LSP is signaled using a conventional signaling
protocol, the 'head' of the LSP is the source of the signaling
(also known as the ingress) and the 'tail' is the destination
(also known as the egress). For unidirectional LSPs, this
usually matches the direction of flow of data.
For manually configured unidirectional LSPs, the direction of
the LSP segment matches the direction of flow of data. For
manually configured bidirectional LSPs, an arbitrary decision
must be made about which LER is the 'head'.
Expires August 17, 2014 [Page 100]
Internet-Draft SMIv2 Textual Conventions February 2014
51. GSMP-MIB (revision 2002-05-31 00:00)
This MIB contains managed object definitions for the General Switch
Management Protocol, GSMP, version 3
51.1. GsmpNameType
The Name is a 48-bit quantity.
A 48-bit IEEE 802 MAC address, if
available, may be used.
51.2. GsmpPartitionType
Defining if partitions are used and how the partition id
is negotiated.
51.3. GsmpPartitionIdType
A 8-bit quantity. The format of the Partition ID is not
defined in GSMP. If desired, the Partition ID can be
divided into multiple sub-identifiers within a single
partition. For example: the Partition ID could be
subdivided into a 6-bit partition number and a 2-bit
sub-identifier which would allow a switch to support 64
partitions with 4 available IDs per partition.
51.4. GsmpVersion
The version numbers defined for the GSMP protocol.
The version numbers used are defined in the
specifications of the respective protocol,
1 - GSMPv1.1 [RFC1987]
2 - GSMPv2.0 [RFC2397]
3 - GSMPv3 [RFC3292]
Other numbers may be defined for other versions
of the GSMP protocol.
51.5. GsmpLabelType
Expires August 17, 2014 [Page 101]
Internet-Draft SMIv2 Textual Conventions February 2014
The label is structured as a TLV, a tuple, consisting of
a Type, a Length, and a Value. The structure is defined
in [RFC 3292]. The label TLV is encoded as a 2 octet type
field, followed by a 2 octet Length field, followed by a
variable length Value field.
Additionally, a label field can be composed of many stacked
labels that together constitute the label.
52. HC-ALARM-MIB (revision 2002-12-16 00:00)
This module defines Remote Monitoring MIB extensions for High
Capacity Alarms. Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3434; see the RFC itself
for full legal notices.
52.1. HcValueStatus
This data type indicates the validity and sign of the data
in associated object instances which represent the absolute
value of a high capacity numeric quantity. Such an object
may be represented with one or more object instances. An
object of type HcValueStatus MUST be defined within the same
structure as the object(s) representing the high capacity
absolute value.
If the associated object instance(s) representing the high
capacity absolute value could not be accessed during the
sampling interval, and is therefore invalid, then the
associated HcValueStatus object will contain the value
'valueNotAvailable(1)'.
If the associated object instance(s) representing the high
capacity absolute value are valid and actual value of the
sample is greater than or equal to zero, then the associated
HcValueStatus object will contain the value
'valuePositive(2)'.
If the associated object instance(s) representing the high
capacity absolute value are valid and the actual value of
the sample is less than zero, then the associated
HcValueStatus object will contain the value
'valueNegative(3)'. The associated absolute value should be
multiplied by -1 to obtain the true sample value.
Expires August 17, 2014 [Page 102]
Internet-Draft SMIv2 Textual Conventions February 2014
53. HCNUM-TC (revision 2000-06-08 00:00)
A MIB module containing textual conventions for high capacity data
types. This module addresses an immediate need for data types not
directly supported in the SMIv2. This short-term solution is meant
to be deprecated as a long-term solution is deployed.
53.1. CounterBasedGauge64
The CounterBasedGauge64 type represents a non-negative
integer, which may increase or decrease, but shall never
exceed a maximum value, nor fall below a minimum value. The
maximum value can not be greater than 2^64-1
(18446744073709551615 decimal), and the minimum value can
not be smaller than 0. The value of a CounterBasedGauge64
has its maximum value whenever the information being modeled
is greater than or equal to its maximum value, and has its
minimum value whenever the information being modeled is
smaller than or equal to its minimum value. If the
information being modeled subsequently decreases below
(increases above) the maximum (minimum) value, the
CounterBasedGauge64 also decreases (increases).
Note that this TC is not strictly supported in SMIv2,
because the 'always increasing' and 'counter wrap' semantics
associated with the Counter64 base type are not preserved.
It is possible that management applications which rely
solely upon the (Counter64) ASN.1 tag to determine object
semantics will mistakenly operate upon objects of this type
as they would for Counter64 objects.
This textual convention represents a limited and short-term
solution, and may be deprecated as a long term solution is
defined and deployed to replace it.
53.2. ZeroBasedCounter64
Expires August 17, 2014 [Page 103]
Internet-Draft SMIv2 Textual Conventions February 2014
This TC describes an object which counts events with the
following semantics: objects of this type will be set to
zero(0) on creation and will thereafter count appropriate
events, wrapping back to zero(0) when the value 2^64 is
reached.
Provided that an application discovers the new object within
the minimum time to wrap it can use the initial value as a
delta since it last polled the table of which this object is
part. It is important for a management station to be aware
of this minimum time and the actual time between polls, and
to discard data if the actual time is too long or there is
no defined minimum time.
Typically this TC is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in
use.
Note that this textual convention does not retain all the
semantics of the Counter64 base type. Specifically, a
Counter64 has an arbitrary initial value, but objects
defined with this TC are required to start at the value
zero. This behavior is not likely to have any adverse
effects on management applications which are expecting
Counter64 semantics.
This textual convention represents a limited and short-term
solution, and may be deprecated as a long term solution is
defined and deployed to replace it.
54. HC-PerfHist-TC-MIB (revision 2004-02-03 00:00)
This MIB Module provides Textual Conventions to be used by systems
supporting 15 minute based performance history counts that require
high-capacity counts. Copyright (C) The Internet Society (2004).
This version of this MIB module is part of RFC 3705: see the RFC
itself for full legal notices.
54.1. HCPerfValidIntervals
Expires August 17, 2014 [Page 104]
Internet-Draft SMIv2 Textual Conventions February 2014
The number of near end intervals for which data was
collected. The value of an object with an
HCPerfValidIntervals syntax will be 96 unless the
measurement was (re-)started within the last 1440 minutes,
in which case the value will be the number of complete 15
minute intervals for which the agent has at least some data.
In certain cases (e.g., in the case where the agent is a
proxy) it is possible that some intervals are unavailable.
In this case, this interval is the maximum interval number
for which data is available.
54.2. HCPerfInvalidIntervals
The number of near end intervals for which no data is
available. The value of an object with an
HCPerfInvalidIntervals syntax will typically be zero except
in cases where the data for some intervals are not available
(e.g., in proxy situations).
54.3. HCPerfTimeElapsed
The number of seconds that have elapsed since the beginning
of the current measurement period. If, for some reason,
such as an adjustment in the system's time-of-day clock or
the addition of a leap second, the duration of the current
interval exceeds the maximum value, the agent will return
the maximum value.
For 15 minute intervals, the range is limited to (0..899).
For 24 hour intervals, the range is limited to (0..86399).
54.4. HCPerfIntervalThreshold
This convention defines a range of values that may be set
in a fault threshold alarm control. As the number of
seconds in a 15-minute interval numbers at most 900,
objects of this type may have a range of 0...900, where the
value of 0 disables the alarm.
Expires August 17, 2014 [Page 105]
Internet-Draft SMIv2 Textual Conventions February 2014
54.5. HCPerfCurrentCount
A gauge associated with a performance measurement in a
current 15 minute measurement interval. The value of an
object with an HCPerfCurrentCount syntax starts from zero
and is increased when associated events occur, until the
end of the 15 minute interval. At that time the value of
the gauge is stored in the first 15 minute history
interval, and the gauge is restarted at zero. In the case
where the agent has no valid data available for the
current interval, the corresponding object instance is not
available and upon a retrieval request a corresponding
error message shall be returned to indicate that this
instance does not exist.
This count represents a non-negative integer, which
may increase or decrease, but shall never exceed 2^64-1
(18446744073709551615 decimal), nor fall below 0. The
value of an object with HCPerfCurrentCount syntax
assumes its maximum value whenever the underlying count
exceeds 2^64-1. If the underlying count subsequently
decreases below 2^64-1 (due, e.g., to a retroactive
adjustment as a result of entering or exiting unavailable
time), then the object's value also decreases.
Note that this TC is not strictly supported in SMIv2,
because the 'always increasing' and 'counter wrap'
semantics associated with the Counter64 base type are not
preserved. It is possible that management applications
which rely solely upon the (Counter64) ASN.1 tag to
determine object semantics will mistakenly operate upon
objects of this type as they would for Counter64 objects.
This textual convention represents a limited and short-
term solution, and may be deprecated as a long term
solution is defined and deployed to replace it.
54.6. HCPerfIntervalCount
Expires August 17, 2014 [Page 106]
Internet-Draft SMIv2 Textual Conventions February 2014
A gauge associated with a performance measurement in
a previous 15 minute measurement interval. In the case
where the agent has no valid data available for a
particular interval, the corresponding object instance is
not available and upon a retrieval request a corresponding
error message shall be returned to indicate that this
instance does not exist.
Let X be an object with HCPerfIntervalCount syntax.
Let Y be an object with HCPerfCurrentCount syntax.
Let Z be an object with HCPerfTotalCount syntax.
Then, in a system supporting a history of n intervals with
X(1) and X(n) the most and least recent intervals
respectively, the following applies at the end of a 15
minute interval:
- discard the value of X(n)
- the value of X(i) becomes that of X(i-1)
for n >= i > 1
- the value of X(1) becomes that of Y.
- the value of Z, if supported, is adjusted.
This count represents a non-negative integer, which
may increase or decrease, but shall never exceed 2^64-1
(18446744073709551615 decimal), nor fall below 0. The
value of an object with HCPerfIntervalCount syntax
assumes its maximum value whenever the underlying count
exceeds 2^64-1. If the underlying count subsequently
decreases below 2^64-1 (due, e.g., to a retroactive
adjustment as a result of entering or exiting unavailable
time), then the value of the object also decreases.
Note that this TC is not strictly supported in SMIv2,
because the 'always increasing' and 'counter wrap'
semantics associated with the Counter64 base type are not
preserved. It is possible that management applications
which rely solely upon the (Counter64) ASN.1 tag to
determine object semantics will mistakenly operate upon
objects of this type as they would for Counter64 objects.
This textual convention represents a limited and short-
term solution, and may be deprecated as a long term
solution is defined and deployed to replace it.
Expires August 17, 2014 [Page 107]
Internet-Draft SMIv2 Textual Conventions February 2014
54.7. HCPerfTotalCount
A gauge representing the aggregate of previous valid 15
minute measurement intervals. Intervals for which no
valid data was available are not counted.
This count represents a non-negative integer, which
may increase or decrease, but shall never exceed 2^64-1
(18446744073709551615 decimal), nor fall below 0. The
value of an object with HCPerfTotalCount syntax
assumes its maximum value whenever the underlying count
exceeds 2^64-1. If the underlying count subsequently
decreases below 2^64-1 (due, e.g., to a retroactive
adjustment as a result of entering or exiting unavailable
time), then the object's value also decreases.
Note that this TC is not strictly supported in SMIv2,
because the 'always increasing' and 'counter wrap'
semantics associated with the Counter64 base type are not
preserved. It is possible that management applications
which rely solely upon the (Counter64) ASN.1 tag to
determine object semantics will mistakenly operate upon
objects of this type as they would for Counter64 objects.
This textual convention represents a limited and short-
term solution, and may be deprecated as a long term
solution is defined and deployed to replace it.
55. HDSL2-SHDSL-LINE-MIB (revision 2005-12-07 00:00)
This MIB module defines a collection of objects for managing HDSL2/
SHDSL lines. An agent may reside at either end of the line; however,
the MIB module is designed to require no management communication
between the modems beyond that inherent in the low-level EOC line
protocol as defined in ANSI T1E1.4/2000-006 (for HDSL2 lines) or in
ITU G.991.2 (for SHDSL lines). Copyright (C) The Internet Society
(2005). This version of this MIB module is part of RFC 4319; see the
RFC itself for full legal notices.
55.1. Hdsl2ShdslPerfCurrDayCount
Expires August 17, 2014 [Page 108]
Internet-Draft SMIv2 Textual Conventions February 2014
A gauge associated with interface performance measurements in
a current 1-day (24 hour) measurement interval.
The value of this gauge starts at zero at the beginning of an
interval and is increased when associated events occur, until
the end of the 1-day interval. At that time, the value of the
gauge is stored in the previous 1-day history interval, as
defined in a companion object of type
Hdsl2Shdsl1DayIntevalCount, and the current interval gauge
is restarted at zero.
In the case where the agent has no valid data available for
this interval, the corresponding object instance is not
available, and upon a retrieval request, a corresponding error
message shall be returned to indicate that this instance does
not exist. Please note that zero is a valid value.
55.2. Hdsl2Shdsl1DayIntervalCount
A counter associated with interface performance measurements
during the most previous 1-day (24 hour) measurement interval.
The value of this gauge is equal to the value of the current
day gauge, as defined in a companion object of type
Hdsl2ShdslPerfCurrDayCount, at the end of its most recent
interval.
In the case where the agent has no valid data available for
this interval, the corresponding object instance is not
available, and upon a retrieval request, a corresponding error
message shall be returned to indicate that this instance does
not exist.
55.3. Hdsl2ShdslPerfTimeElapsed
The number of seconds that have elapsed since the beginning of
the current measurement period. If, for some reason, such as
an adjustment in the system's time-of-day clock or the addition
of a leap second, the current interval exceeds the maximum
value, the agent will return the maximum value.
For 15-minute intervals, the range is limited to (0..899).
For 24-hour intervals, the range is limited to (0..86399).
Expires August 17, 2014 [Page 109]
Internet-Draft SMIv2 Textual Conventions February 2014
55.4. Hdsl2ShdslPerfIntervalThreshold
This convention defines a range of values that may be set in
a fault threshold alarm control. As the number of seconds in
a 15-minute interval numbers at most 900, objects of this type
may have a range of 0...900, where the value of 0 disables the
alarm.
55.5. Hdsl2ShdslUnitId
This is the unique identification for all units in an
HDSL2/SHDSL span. It is based on the EOC unit addressing
scheme with reference to the xtuC.
55.6. Hdsl2ShdslUnitSide
This is the referenced side of an HDSL2/SHDSL unit - Network
or Customer side. The side facing the Network is the Network
side, while the side facing the Customer is the Customer side.
55.7. Hdsl2ShdslWirePair
This is the referenced pair of wires in an HDSL2/SHDSL segment.
HDSL2 only supports a single pair (wirePair1 or two wire),
SHDSL lines support an optional second pair (wirePair2 or four
wire), and G.shdsl.bis support an optional third pair
(wirePair3 or six wire) and an optional fourth pair
(wirePair4 or eight wire).
55.8. Hdsl2ShdslTransmissionModeType
Contains the regional setting of the HDSL2/SHDSL span,
represented as a bit-map of possible settings. The various
bit positions are as follows:
Bit Meaning Description
1 region 1 Indicates ITU-T G.991.2 Annex A.
2 region 2 Indicates ITU-T G.991.2 Annex B.
Expires August 17, 2014 [Page 110]
Internet-Draft SMIv2 Textual Conventions February 2014
55.9. Hdsl2ShdslClockReferenceType
The various STU-C symbol clock references for the
HDSL2/SHDSL span, represented as an enumeration.
56. HOST-RESOURCES-MIB (revision 2000-03-06 00:00)
This MIB is for use in managing host systems. The term `host' is
construed to mean any computer that communicates with other similar
computers attached to the internet and that is directly used by one
or more human beings. Although this MIB does not necessarily apply
to devices whose primary function is communications services (e.g.,
terminal servers, routers, bridges, monitoring equipment), such
relevance is not explicitly precluded. This MIB instruments
attributes common to all internet hosts including, for example, both
personal computers and systems that run variants of Unix.
56.1. KBytes
Storage size, expressed in units of 1024 bytes.
56.2. ProductID
This textual convention is intended to identify the
manufacturer, model, and version of a specific
hardware or software product. It is suggested that
these OBJECT IDENTIFIERs are allocated such that all
products from a particular manufacturer are registered
under a subtree distinct to that manufacturer. In
addition, all versions of a product should be
registered under a subtree distinct to that product.
With this strategy, a management station may uniquely
determine the manufacturer and/or model of a product
whose productID is unknown to the management station.
Objects of this type may be useful for inventory
purposes or for automatically detecting
incompatibilities or version mismatches between
various hardware and software components on a system.
For example, the product ID for the ACME 4860 66MHz
clock doubled processor might be:
enterprises.acme.acmeProcessors.a4860DX2.MHz66
A software product might be registered as:
Expires August 17, 2014 [Page 111]
Internet-Draft SMIv2 Textual Conventions February 2014
enterprises.acme.acmeOperatingSystems.acmeDOS.six(6).one(1)
56.3. InternationalDisplayString
This data type is used to model textual information
in some character set. A network management station
should use a local algorithm to determine which
character set is in use and how it should be
displayed. Note that this character set may be
encoded with more than one octet per symbol, but will
most often be NVT ASCII. When a size clause is
specified for an object of this type, the size refers
to the length in octets, not the number of symbols.
57. HPR-IP-MIB (revision 1998-09-24 00:00)
The MIB module for HPR over IP. This module contains two groups: -
the HPR over IP Monitoring Group provides a count of the UDP packets
sent by a link station for each APPN traffic type. - the HPR over IP
Configuration Group provides for reading and setting the mappings
between APPN traffic types and TOS Precedence settings in the IP
header. These mappings are configured at the APPN port level, and
are inherited by the APPN connection networks and link stations
associated with an APPN port. A port-level mapping can, however, be
overridden for a particular connection network or link station.
57.1. AppnTrafficType
APPN traffic type. The first four values correspond
to APPN transmission priorities (network, high, medium and
low), while the fifth is used for both LLC commands (XID,
TEST, DISC, and DM) and function-routed NLPs (XID_DONE_RQ
and XID_DONE_RSP).
57.2. AppnTOSPrecedence
Expires August 17, 2014 [Page 112]
Internet-Draft SMIv2 Textual Conventions February 2014
A DisplayString representing the setting of the three TOS
Precedence bits in the IP Type of Service field for this APPN
traffic type. The HPR over IP architecture specifies the
following default mapping:
APPN traffic type IP TOS Precedence bits
------------------ ----------------------
Network 110
High 100
Medium 010
Low 001
LLC commands, etc. 110
58. HPR-MIB (revision 1997-05-14 00:00)
This is the MIB module for objects used to manage network devices
with HPR capabilities.
58.1. HprNceTypes
A bit string identifying the set of functions provided by a
network connection endpoint (NCE). The following values are
defined:
bit 0: control point
bit 1: logical unit
bit 2: boundary function
bit 3: route setup
58.2. HprRtpCounter
An object providing statistics for an RTP connection. A
Management Station can detect discontinuities in this counter
by monitoring the correspondingly indexed
hprRtpCounterDisconTime object.
59. IANA-ITU-ALARM-TC-MIB (revision 2004-09-09 00:00)
The MIB module defines the ITU Alarm textual convention for objects
expected to require regular extension. Copyright (C) The Internet
Society (2004). The initial version of this MIB module was published
in RFC 3877. For full legal notices see the RFC itself.
Supplementary information may be available on:
http://www.ietf.org/copyrights/ianamib.html
Expires August 17, 2014 [Page 113]
Internet-Draft SMIv2 Textual Conventions February 2014
59.1. IANAItuProbableCause
ITU-T probable cause values. Duplicate values defined in
X.733 are appended with X733 to ensure syntactic uniqueness.
Probable cause value 0 is reserved for special purposes.
The Internet Assigned Number Authority (IANA) is responsible
for the assignment of the enumerations in this TC.
IANAItuProbableCause value of 0 is reserved for special
purposes and MUST NOT be assigned.
Values of IANAItuProbableCause in the range 1 to 1023 are
reserved for causes that correspond to ITU-T probable cause.
All other requests for new causes will be handled on a
first-come, first served basis and will be assigned
enumeration values starting with 1025.
Request should come in the form of well-formed
SMI [RFC2578] for enumeration names that are unique and
sufficiently descriptive.
While some effort will be taken to ensure that new probable
causes do not conceptually duplicate existing probable
causes it is acknowledged that the existence of conceptual
duplicates in the starting probable cause list is an known
industry reality.
To aid IANA in the administration of probable cause names
and values, the OPS Area Director will appoint one or more
experts to help review requests.
See http://www.iana.org
59.2. IANAItuEventType
Expires August 17, 2014 [Page 114]
Internet-Draft SMIv2 Textual Conventions February 2014
The ITU event Type values.
The Internet Assigned Number Authority (IANA) is
responsible for the assignment of the enumerations
in this TC.
Request should come in the form of well-formed
SMI [RFC2578] for enumeration names that are unique
and sufficiently descriptive.
See http://www.iana.org
60. IFCP-MGMT-MIB (revision 2011-03-09 00:00)
This module defines management information specific to Internet Fibre
Channel Protocol (iFCP) gateway management. Copyright (c) 2011 IETF
Trust and the persons identified as authors of the code. All rights
reserved. Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to the
license terms contained in, the Simplified BSD License set forth in
Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
Documents (http://trustee.ietf.org/license-info).
60.1. IfcpIpTOVorZero
The maximum propagation delay, in seconds,
for an encapsulated FC frame to traverse the
IP network. A value of 0 implies fibre
channel frame lifetime limits will not be
enforced.
60.2. IfcpLTIorZero
The value for the Liveness Test Interval
(LTI) being used in an iFCP connection, in
seconds. A value of 0 implies no Liveness
Test Interval will be used.
60.3. IfcpSessionStates
The value for an iFCP session state.
Expires August 17, 2014 [Page 115]
Internet-Draft SMIv2 Textual Conventions February 2014
60.4. IfcpAddressMode
The values for iFCP Address Translation
Mode.
61. IF-MIB (revision 2000-06-14 00:00)
The MIB module to describe generic objects for network interface sub-
layers. This MIB is an updated version of MIB-II's ifTable, and
incorporates the extensions defined in RFC 1229.
61.1. OwnerString (deprecated)
This data type is used to model an administratively
assigned name of the owner of a resource. This information
is taken from the NVT ASCII character set. It is suggested
that this name contain one or more of the following: ASCII
form of the manager station's transport address, management
station name (e.g., domain name), network management
personnel's name, location, or phone number. In some cases
the agent itself will be the owner of an entry. In these
cases, this string shall be set to a string starting with
'agent'.
61.2. InterfaceIndex
A 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.
61.3. InterfaceIndexOrZero
This 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,
Expires August 17, 2014 [Page 116]
Internet-Draft SMIv2 Textual Conventions February 2014
or when none or all interfaces need to be referenced.
62. INET-ADDRESS-MIB (revision 2005-02-04 00:00)
This MIB module defines textual conventions for representing Internet
addresses. An Internet address can be an IPv4 address, an IPv6
address, or a DNS domain name. This module also defines textual
conventions for Internet port numbers, autonomous system numbers, and
the length of an Internet address prefix. Copyright (C) The Internet
Society (2005). This version of this MIB module is part of RFC 4001,
see the RFC itself for full legal notices.
62.1. InetAddressType
Expires August 17, 2014 [Page 117]
Internet-Draft SMIv2 Textual Conventions February 2014
A 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)).
Expires August 17, 2014 [Page 118]
Internet-Draft SMIv2 Textual Conventions February 2014
62.2. InetAddress
Denotes 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.
62.3. InetAddressIPv4
Represents an IPv4 network address:
Octets Contents Encoding
1-4 IPv4 address network-byte order
The corresponding InetAddressType value is ipv4(1).
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.
Expires August 17, 2014 [Page 119]
Internet-Draft SMIv2 Textual Conventions February 2014
62.4. InetAddressIPv6
Represents an IPv6 network address:
Octets Contents Encoding
1-16 IPv6 address network-byte order
The corresponding InetAddressType value is ipv6(2).
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.
62.5. InetAddressIPv4z
Represents a non-global IPv4 network address, together
with its zone index:
Octets Contents Encoding
1-4 IPv4 address network-byte order
5-8 zone index network-byte order
The corresponding InetAddressType value is ipv4z(3).
The zone index (bytes 5-8) is used to disambiguate identical
address values on nodes that have interfaces attached to
different zones of the same scope. The zone index may contain
the special value 0, which refers to the default zone for each
scope.
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.
62.6. InetAddressIPv6z
Expires August 17, 2014 [Page 120]
Internet-Draft SMIv2 Textual Conventions February 2014
Represents a non-global IPv6 network address, together
with its zone index:
Octets Contents Encoding
1-16 IPv6 address network-byte order
17-20 zone index network-byte order
The corresponding InetAddressType value is ipv6z(4).
The zone index (bytes 17-20) is used to disambiguate
identical address values on nodes that have interfaces
attached to different zones of the same scope. The zone index
may contain the special value 0, which refers to the default
zone for each scope.
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.
62.7. InetAddressDNS
Represents a DNS domain name. The name SHOULD be fully
qualified whenever possible.
The corresponding InetAddressType is dns(16).
The DESCRIPTION clause of InetAddress objects that may have
InetAddressDNS values MUST fully describe how (and when)
these names are to be resolved to IP addresses.
The resolution of an InetAddressDNS value may require to
query multiple DNS records (e.g., A for IPv4 and AAAA for
IPv6). The order of the resolution process and which DNS
record takes precedence depends on the configuration of the
resolver.
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair.
Expires August 17, 2014 [Page 121]
Internet-Draft SMIv2 Textual Conventions February 2014
62.8. InetAddressPrefixLength
Denotes the length of a generic Internet network address
prefix. A value of n corresponds to an IP address mask
that has n contiguous 1-bits from the most significant
bit (MSB), with all other bits set to 0.
An InetAddressPrefixLength value is always interpreted within
the context of an InetAddressType value. Every usage of the
InetAddressPrefixLength 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
InetAddressPrefixLength textual convention, if they appear
in the same logical row.
InetAddressPrefixLength values larger than
the maximum length of an IP address for a specific
InetAddressType are treated as the maximum significant
value applicable for the InetAddressType. The maximum
significant value is 32 for the InetAddressType
'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType
'ipv6(2)' and 'ipv6z(4)'. The maximum significant value
for the InetAddressType 'dns(16)' is 0.
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 the Internet network address prefix
is unknown or does not apply.
The upper bound of the prefix length has been chosen to
be consistent with the maximum size of an InetAddress.
62.9. InetPortNumber
Expires August 17, 2014 [Page 122]
Internet-Draft SMIv2 Textual Conventions February 2014
Represents 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
.
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.
62.10. InetAutonomousSystemNumber
Represents an autonomous system number that identifies an
Autonomous System (AS). An AS is a set of routers under a
single technical administration, using an interior gateway
protocol and common metrics to route packets within the AS,
and using an exterior gateway protocol to route packets to
other ASes'. IANA maintains the AS number space and has
delegated large parts to the regional registries.
Autonomous system numbers are currently limited to 16 bits
(0..65535). There is, however, work in progress to enlarge the
autonomous system number space to 32 bits. Therefore, this
textual convention uses an Unsigned32 value without a
range restriction in order to support a larger autonomous
system number space.
62.11. InetScopeType
Represents a scope type. This textual convention can be used
in cases where a MIB has to represent different scope types
and there is no context information, such as an InetAddress
object, that implicitly defines the scope type.
Note that not all possible values have been assigned yet, but
they may be assigned in future revisions of this specification.
Applications should therefore be able to deal with values
not yet assigned.
Expires August 17, 2014 [Page 123]
Internet-Draft SMIv2 Textual Conventions February 2014
62.12. InetZoneIndex
A zone index identifies an instance of a zone of a
specific scope.
The zone index MUST disambiguate identical address
values. For link-local addresses, the zone index will
typically be the interface index (ifIndex as defined in the
IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers
to the default zone. The default zone may be used in cases
where the valid zone index is not known (e.g., when a
management application has to write a link-local IPv6
address without knowing the interface index value). The
default zone SHOULD NOT be used as an easy way out in
cases where the zone index for a non-global IPv6 address
is known.
62.13. InetVersion
A value representing a version of the IP protocol.
unknown(0) An unknown or unspecified version of the IP
protocol.
ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5).
ipv6(2) The IPv6 protocol as defined in RFC 2460.
Note that this textual convention SHOULD NOT be used to
distinguish different address types associated with IP
protocols. The InetAddressType has been designed for this
purpose.
63. INTEGRATED-SERVICES-MIB (revision 1995-11-03 05:00)
The MIB module to describe the Integrated Services Protocol
63.1. SessionNumber
Expires August 17, 2014 [Page 124]
Internet-Draft SMIv2 Textual Conventions February 2014
The Session Number convention is used for
numbers identifying sessions or saved PATH or
RESV information. It is a number in the range
returned by a TestAndIncr variable, having no
protocol meaning whatsoever but serving instead
as simple identifier.
The alternative was a very complex instance or
instance object that became unwieldy.
63.2. Protocol
The value of the IP Protocol field of an IP
Datagram Header. This identifies the protocol
layer above IP. For example, the value 6 is
used for TCP and the value 17 is used for UDP.
The values of this field are defined in the As-
signed Numbers RFC.
63.3. SessionType
The value of the C-Type field of a Session ob-
ject, as defined in the RSVP specification.
This value determines the lengths of octet
strings and use of certain objects such as the
'port' variables. If the C-Type calls for an
IP6 address, one would expect all source, des-
tination, and next/previous hop addresses to be
16 bytes long, and for the ports to be UDP/TCP
port numbers, for example.
63.4. Port
The value of the UDP or TCP Source or Destina-
tion Port field, a virtual destination port or
generalized port identifier used with the IPSEC
Authentication Header or Encapsulating Security
Payload, or other session discriminator. If it
is not used, the value should be of length 0.
This pair, when coupled with the IP Addresses
of the source and destination system and the IP
protocol field, uniquely identifies a data
stream.
Expires August 17, 2014 [Page 125]
Internet-Draft SMIv2 Textual Conventions February 2014
63.5. MessageSize
The size of a message in bytes. This is used
to specify the minimum and maximum size of a
message along an integrated services route.
63.6. BitRate
The rate, in bits/second, that data may move
in the context. Applicable contexts minimally
include the speed of an interface or virtual
circuit, the data rate of a (potentially aggre-
gated) data flow, or the data rate to be allo-
cated for use by a flow.
63.7. BurstSize
The number of octets of IP Data, including IP
Headers, that a stream may send without concern
for policing.
63.8. QosService
The class of service in use by a flow.
64. IP-MIB (revision 2006-02-02 00:00)
The MIB module for managing IP and ICMP implementations, but
excluding their management of IP routes. Copyright (C) The Internet
Society (2006). This version of this MIB module is part of RFC 4293;
see the RFC itself for full legal notices.
64.1. IpAddressOriginTC
Expires August 17, 2014 [Page 126]
Internet-Draft SMIv2 Textual Conventions February 2014
The origin of the address.
manual(2) indicates that the address was manually configured
to a specified address, e.g., by user configuration.
dhcp(4) indicates an address that was assigned to this
system by a DHCP server.
linklayer(5) indicates an address created by IPv6 stateless
auto-configuration.
random(6) indicates an address chosen by the system at
random, e.g., an IPv4 address within 169.254/16, or an RFC
3041 privacy address.
64.2. IpAddressStatusTC
Expires August 17, 2014 [Page 127]
Internet-Draft SMIv2 Textual Conventions February 2014
The status of an address. Most of the states correspond to
states from the IPv6 Stateless Address Autoconfiguration
protocol.
The preferred(1) state indicates that this is a valid
address that can appear as the destination or source address
of a packet.
The deprecated(2) state indicates that this is a valid but
deprecated address that should no longer be used as a source
address in new communications, but packets addressed to such
an address are processed as expected.
The invalid(3) state indicates that this isn't a valid
address and it shouldn't appear as the destination or source
address of a packet.
The inaccessible(4) state indicates that the address is not
accessible because the interface to which this address is
assigned is not operational.
The unknown(5) state indicates that the status cannot be
determined for some reason.
The tentative(6) state indicates that the uniqueness of the
address on the link is being verified. Addresses in this
state should not be used for general communication and
should only be used to determine the uniqueness of the
address.
The duplicate(7) state indicates the address has been
determined to be non-unique on the link and so must not be
used.
The optimistic(8) state indicates the address is available
for use, subject to restrictions, while its uniqueness on
a link is being verified.
In the absence of other information, an IPv4 address is
always preferred(1).
64.3. IpAddressPrefixOriginTC
Expires August 17, 2014 [Page 128]
Internet-Draft SMIv2 Textual Conventions February 2014
The origin of this prefix.
manual(2) indicates a prefix that was manually configured.
wellknown(3) indicates a well-known prefix, e.g., 169.254/16
for IPv4 auto-configuration or fe80::/10 for IPv6 link-local
addresses. Well known prefixes may be assigned by IANA,
the address registries, or by specification in a standards
track RFC.
dhcp(4) indicates a prefix that was assigned by a DHCP
server.
routeradv(5) indicates a prefix learned from a router
advertisement.
Note: while IpAddressOriginTC and IpAddressPrefixOriginTC
are similar, they are not identical. The first defines how
an address was created, while the second defines how a
prefix was found.
64.4. Ipv6AddressIfIdentifierTC
This data type is used to model IPv6 address
interface identifiers. This is a binary string
of up to 8 octets in network byte-order.
65. IPMROUTE-STD-MIB (revision 2000-09-22 00:00)
The MIB module for management of IP Multicast routing, but
independent of the specific multicast routing protocol in use.
65.1. LanguageTag
An RFC 1766-style language tag, with all alphabetic
characters converted to lowercase. This restriction is
intended to make the lexical ordering imposed by SNMP useful
when applied to language tags. Note that it is
theoretically possible for a valid language tag to exceed
the allowed length of this syntax, and thus be impossible to
represent with this syntax. Sampling of language tags in
current use on the Internet suggests that this limit does
not pose a serious problem in practice.
Expires August 17, 2014 [Page 129]
Internet-Draft SMIv2 Textual Conventions February 2014
66. IPOA-MIB (revision 1998-02-09 00:00)
This module defines a portion of the management information base
(MIB) for managing Classical IP and ARP over ATM entities.
66.1. IpoaEncapsType
The encapsulation type used on a VC.
66.2. IpoaVpiInteger
An integer large enough to contain the value of a VPI.
66.3. IpoaVciInteger
An integer large enough to contain the value of a VCI.
66.4. IpoaAtmAddr
The ATM address used by the network entity.
The semantics are implied by the length.
The address types are:
- no address (0 octets)
- E.164 (8 octets)
- NSAP (20 octets)
In addition, when subaddresses are used IpoaAtmAddr
may represent the concatenation of address and
subaddress. The associated address types are:
- E.164, E.164 (16 octets)
- E.164, NSAP (28 octets)
- NSAP, NSAP (40 octets)
Address lengths other than defined in this definition
imply address types defined elsewhere.
Note: The E.164 address is encoded in BCD format.
66.5. IpoaAtmConnKind
Expires August 17, 2014 [Page 130]
Internet-Draft SMIv2 Textual Conventions February 2014
The use of call control. The use is as follows:
pvc(1)
Virtual link of a PVC. Should not be
used in a PVC/SVC (i.e., SPVC)
crossconnect.
svcIncoming(2)
Virtual link established after a
received signaling request to setup
an SVC.
svcOutgoing(3)
Virtual link established after a
transmitted or forwarded signaling
request to setup an SVC.
spvcInitiator(4)
Virtual link at the PVC side of an
SVC/PVC crossconnect, where the
switch is the initiator of the SPVC
setup.
spvcTarget(5)
Virtual link at the PVC side of an
SVC/PVC crossconnect, where the
switch is the target of the SPVC
setup.
An spvcInitiator is always cross-connected to
an svcOutgoing, and an spvcTarget is always
cross-connected to an svcIncoming.
67. IPS-AUTH-MIB (revision 2006-05-22 00:00)
The IP Storage Authorization MIB module. Copyright (C) The Internet
Society (2006). This version of this MIB module is part of RFC 4545;
see the RFC itself for full legal notices.
67.1. IpsAuthAddress
Expires August 17, 2014 [Page 131]
Internet-Draft SMIv2 Textual Conventions February 2014
IP Storage requires the use of address information
that uses not only the InetAddress type defined in the
INET-ADDRESS-MIB, but also Fibre Channel type defined
in the Fibre Channel Management MIB. Although these
address types are recognized in the IANA Address Family
Numbers MIB, the addressing mechanisms have not been
merged into a well-known, common type. This data type,
the IpsAuthAddress, performs the merging for this MIB
module.
The formats of objects of this type are determined by
a corresponding object with syntax AddressFamilyNumbers,
and thus every object defined using this TC must
identify the object with syntax AddressFamilyNumbers
that specifies its type.
The syntax and semantics of this object depend on the
identified AddressFamilyNumbers object as follows:
AddressFamilyNumbers this object
==================== ===========
ipV4(1) restricted to the same syntax and
semantics as the InetAddressIPv4 TC.
ipV6(2) restricted to the same syntax and
semantics as the InetAddressIPv6 TC.
fibreChannelWWPN (22)
& fibreChannelWWNN(23) restricted to the same syntax and
semantics as the FcNameIdOrZero TC.
Types other than the above should not be used unless
the corresponding format of the IpsAuthAddress object is
further specified (e.g., in a future revision of this TC).
68. IPSEC-SPD-MIB (revision 2007-02-07 00:00)
This MIB module defines configuration objects for managing IPsec
Security Policies. In general, this MIB can be implemented anywhere
IPsec security services exist (e.g., bump-in-the-wire, host, gateway,
firewall, router, etc.). Copyright (C) The IETF Trust (2007). This
version of this MIB module is part of RFC 4807; see the RFC itself
for full legal notices.
Expires August 17, 2014 [Page 132]
Internet-Draft SMIv2 Textual Conventions February 2014
68.1. SpdBooleanOperator
The SpdBooleanOperator operator is used to specify
whether sub-components in a decision-making process are
ANDed or ORed together to decide if the resulting
expression is true or false.
68.2. SpdAdminStatus
The SpdAdminStatus is used to specify the administrative
status of an object. Objects that are disabled MUST NOT
be used by the packet processing engine.
68.3. SpdIPPacketLogging
SpdIPPacketLogging specifies whether an audit message
SHOULD be logged if a packet is passed through a Security
Association (SA) and if some of that packet is included in
the log event. A value of '-1' indicates no logging. A
value of '0' or greater indicates that logging SHOULD be
done and indicates the number of bytes starting at the
beginning of the packet to place in the log. Values greater
than the size of the packet being processed indicate that
the entire packet SHOULD be sent.
Examples:
'-1' no logging
'0' log but do not include any of the packet in the log
'20' log and include the first 20 bytes of the packet
in the log.
68.4. SpdTimePeriod
Expires August 17, 2014 [Page 133]
Internet-Draft SMIv2 Textual Conventions February 2014
This property identifies an overall range of calendar dates
and time. In a boolean context, a value within this time
range, inclusive, is considered true.
This information is encoded as an octet string using
the UTF-8 transformation format described in STD 63,
RFC 3629.
It uses the format suggested in RFC 3060. An octet string
represents a start date and time and an end date and time.
For example:
yyyymmddThhmmss/yyyymmddThhmmss
Where: yyyy = year mm = month dd = day
hh = hour mm = minute ss = second
The first 'yyyymmddThhmmss' sub-string indicates the start
date and time. The second 'yyyymmddThhmmss' sub-string
indicates the end date and time. The character 'T' within
these sub-strings indicates the beginning of the time
portion of each sub-string. The solidus character '/'
separates the start from the end date and time. The end
date and time MUST be subsequent to the start date and
time.
There are also two allowed substitutes for a
'yyyymmddThhmmss' sub-string: one for the start date and
time, and one for the end date and time.
If the start date and time are replaced with the string
'THISANDPRIOR', this sub-string would indicate the current
date and time and the previous dates and time.
If the end date and time are replaced with the string
'THISANDFUTURE', this sub-string would indicate the current
date and time and the subsequent dates and time.
Any of the following SHOULD be considered a
'wrongValue' error:
- Setting a value with the end date and time earlier than
or equal to the start date and time.
- Setting the start date and time to 'THISANDFUTURE'.
- Setting the end date and time to 'THISANDPRIOR'.
Expires August 17, 2014 [Page 134]
Internet-Draft SMIv2 Textual Conventions February 2014
69. IPV6-FLOW-LABEL-MIB (revision 2003-08-28 00:00)
This MIB module provides commonly used textual conventions for IPv6
Flow Labels. Copyright (C) The Internet Society (2003). This
version of this MIB module is part of RFC 3595, see the RFC itself
for full legal notices.
69.1. IPv6FlowLabel
The flow identifier or Flow Label in an IPv6
packet header that may be used to discriminate
traffic flows.
69.2. IPv6FlowLabelOrAny
The flow identifier or Flow Label in an IPv6
packet header that may be used to discriminate
traffic flows. The value of -1 is used to
indicate a wildcard, i.e. any value.
70. IPV6-TC
70.1. Ipv6Address
This data type is used to model IPv6 addresses.
This is a binary string of 16 octets in network
byte-order.
70.2. Ipv6AddressPrefix
This data type is used to model IPv6 address
prefixes. This is a binary string of up to 16
octets in network byte-order.
70.3. Ipv6AddressIfIdentifier
This data type is used to model IPv6 address
interface identifiers. This is a binary string
of up to 8 octets in network byte-order.
Expires August 17, 2014 [Page 135]
Internet-Draft SMIv2 Textual Conventions February 2014
70.4. Ipv6IfIndex
A unique value, greater than zero for each
internetwork-layer interface in the managed
system. It is recommended that values are assigned
contiguously starting from 1. The value for each
internetwork-layer interface must remain constant
at least from one re-initialization of the entity's
network management system to the next
re-initialization.
70.5. Ipv6IfIndexOrZero
This textual convention is an extension of the
Ipv6IfIndex convention. The latter defines
a greater than zero value used to identify an IPv6
interface 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.
71. ISCSI-MIB (revision 2006-05-22 00:00)
The iSCSI Protocol MIB module. Copyright (C) The Internet Society
(2006). This version of this MIB module is part of RFC 4544; see the
RFC itself for full legal notices.
71.1. IscsiTransportProtocol
This data type is used to define the transport
protocols that will carry iSCSI PDUs.
71.2. IscsiDigestMethod
Expires August 17, 2014 [Page 136]
Internet-Draft SMIv2 Textual Conventions February 2014
This data type represents the methods possible
for digest negotiation.
none - a placeholder for a secondary digest method
that means only the primary method can be
used.
other - a digest method other than those defined below.
noDigest - does not support digests (will operate without
a digest (Note: implementations must support
digests to be compliant with the RFC3720).
CRC32c - require a CRC32C digest.
71.3. IscsiName
This data type is used for objects whose value is an
iSCSI name with the properties described in RFC 3720
section 3.2.6.1, and encoded as specified in RFC 3720
section 3.2.6.2. A zero-length string indicates the
absence of an iSCSI name.
72. ISDN-MIB (revision 1996-09-23 16:42)
The MIB module to describe the management of ISDN interfaces.
72.1. IsdnSignalingProtocol
This data type is used as the syntax of the
isdnSignalingProtocol object in the
definition of ISDN-MIB's isdnSignalingTable.
The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the
IANA.)
Requests for new values should be made to IANA via
email (iana@iana.org).
73. ISIS-MIB (revision 2006-04-04 00:00)
This document describes a management information base for the IS-IS
Routing protocol, as described in ISO 10589, when it is used to
Expires August 17, 2014 [Page 137]
Internet-Draft SMIv2 Textual Conventions February 2014
construct routing tables for IP networks, as described in RFC 1195.
This document is based on a 1994 IETF document by Chris Gunner. This
version has been modified to include current syntax, to exclude
portions of the protocol that are not relevant to IP, and to add
management support for current practice. Copyright (C) The Internet
Society (2006). This version of this MIB module is part of RFC 4444;
see the RFC itself for full legal notices.
73.1. IsisOSINSAddress
OSI Network Service Address, e.g., NSAP, SNPA, or Network
Entity Title
73.2. IsisSystemID
The ID for an Intermediate System. This should
be unique within a network, and is included
in all PDUs originated by an Intermediate System.
The protocol does not place any meanings upon
the bits, other than using ordering to break
ties in electing a Designated IS on a LAN.
73.3. IsisLinkStatePDUID
The 8-byte Link State PDU (LSP) ID,
consisting of the 6-byte SystemID of the
originating IS; a one-byte PseudoNode ID,
which is 0 unless the LSP represents the
topology of a LAN; and a one-byte LSP
fragment number that is issued in sequence,
starting with 0. Non-zero PseudoNode IDs
need to be unique to the IS but need not
match the IfIndex.
73.4. IsisAdminState
Type used in enabling and disabling a row.
73.5. IsisLSPBuffSize
Integer sub-range for maximum LSP size.
Expires August 17, 2014 [Page 138]
Internet-Draft SMIv2 Textual Conventions February 2014
73.6. IsisLevelState
States of the IS-IS protocol.
73.7. IsisSupportedProtocol
Types of network protocol supported by Integrated IS-IS.
The values for ISO8473 and IP are those registered for
these protocols in ISO TR9577.
73.8. IsisDefaultMetric
Integer sub-range for default metric for single hop.
ISO 10589 provides for 4 types of metric. Only the
'default' metric is used in practice.
73.9. IsisWideMetric
Wide metric for IS Neighbors. ISO 10589 provides a
6-bit metric. Traffic Engineering extensions provide
24-bit metrics.
73.10. IsisFullMetric
Full metric for IP Routes. Traffic Engineering extensions
provide 32-bit metrics.
73.11. IsisMetricType
Is this an Internal or External Metric?
73.12. IsisMetricStyle
Do we use RFC 1195 style metrics or wide metrics?
73.13. IsisISLevel
Identifies a level.
Expires August 17, 2014 [Page 139]
Internet-Draft SMIv2 Textual Conventions February 2014
73.14. IsisLevel
Identifies one or more levels.
73.15. IsisPDUHeader
A block to contain the header from a PDU.
73.16. IsisCircuitID
ID for a circuit.
73.17. IsisISPriority
Integer sub-range for IS-IS priority.
73.18. IsisUnsigned16TC
An Unsigned32 further restricted to 16 bits. Note that
the ASN.1 BER encoding may still require 24 bits for
some values.
73.19. IsisUnsigned8TC
An Unsigned32 further restricted to 8 bits. Note that
the ASN.1 BER encoding may still require 16 bits for
some values.
74. ISNS-MIB (revision 2007-07-11 00:00)
This module defines management information specific to internet
Storage Name Service (iSNS) management. Copyright (C) The IETF Trust
(2007). This version of this MIB module is part of RFC 4939; see the
RFC itself for full legal notices.
74.1. IsnsDiscoveryDomainSetId
The unique Discovery Domain Set Identifier associated with a
Discovery Domain Set (DDS).
Expires August 17, 2014 [Page 140]
Internet-Draft SMIv2 Textual Conventions February 2014
74.2. IsnsDdsStatusType
The status of a Discovery Domain Set (DDS) registered in the
iSNS. The initially assigned values are below:
Bit Status
--------- ---------
31 DDS Enabled
All others RESERVED
Setting a bit to 1 indicates the feature is enabled.
Otherwise, it is disabled. The future assignment of any of
the reserved values will be documented in a revision of
RFC 4171.
74.3. IsnsDiscoveryDomainId
The unique Discovery Domain Identifier (DD_ID) associated
with each Discovery Domain (DD). This is used to
uniquely index and reference a DD.
74.4. IsnsDdFeatureType
This type defines the features that each Discovery Domain
(DD) has.
Bit Status
--------- ---------
31 Boot List
All others RESERVED
Boot List: this feature indicates that the targets
in this DD provide boot capabilities for the member
initiators.
Setting a bit to 1 indicates the feature is enabled.
Otherwise, it is disabled. The future assignment of any of
the reserved values will be documented in a revision of
RFC 4171.
74.5. IsnsDdDdsModificationType
Expires August 17, 2014 [Page 141]
Internet-Draft SMIv2 Textual Conventions February 2014
The methods that can be used to modify the Discovery
Domain and Discovery Domain Sets in an iSNS Server
instance.
Bit Flag Description
--------- ------------------------------------
0 Control Nodes are allowed
1 Target iSCSI Nodes are allowed
2 Initiator iSCSI Nodes are allowed
3 Target iFCP Ports are allowed
4 Initiator iFCP Ports are allowed
Setting a bit to 1 indicates the feature is
enabled. Otherwise, it is disabled.
74.6. IsnsEntityIndexIdOrZero
The identifier for the unique integer Entity Index
associated with an iSNS registered Entity object, and the
value zero. The value zero is object-specific and MUST
therefore be defined as part of the description of any
object that uses this syntax. Examples of the usage of
zero might include situations where the Entity is unknown,
or not yet registered in the iSNS server. If a value of
zero is not valid for an object, then that MUST be
indicated.
74.7. IsnsPortalGroupIndexId
The identifier for the unique integer Portal Group Index
associated with an iSNS registered Portal Group object.
74.8. IsnsPortalIndexId
Expires August 17, 2014 [Page 142]
Internet-Draft SMIv2 Textual Conventions February 2014
The identifier for the unique integer Portal Index
associated with an iSNS registered Portal object. The
index is created by the iSNS Server for mapping between
registered objects. The Portal Index used for a specific
portal IP-address and port number pair is only persistent
across reboots for portals that have been explicitly added
to a Discovery Domain (DD). If a portal is not explicitly
registered in any DD, then the index used for a portal can
change after a server reinitialization.
74.9. IsnsPortalPortTypeId
The UDP or TCP port type being used by a Portal for an
Entity.
74.10. IsnsPortalGroupTagIdOrNull
The Portal Group Tag (PGT) represents an association
between a Portal and iSCSI Node using the value range
0 to 65535. A PGT with no association is a NULL
value. The value of -1 indicates a NULL value.
74.11. IsnsPortalSecurityType
Expires August 17, 2014 [Page 143]
Internet-Draft SMIv2 Textual Conventions February 2014
Indicates security attribute settings for a Portal that is
registered in the iSNS server. The bitmapVALID field must
be set in order for the contents to be considered valid
information. The definitions of the bit fields are based
on RFC 4171. The initial representation of each bit setting
(0 or 1) is indicated below.
Bit Flag Description
--------- ------------------------------------
25 1 = Tunnel Mode Preferred; 0 = No Preference
26 1 = Transport Mode Preferred; 0 = No
Preference
27 1 = PFS Enabled; 0 = PFS Disabled
28 1 = Aggressive Mode Enabled; 0 = Disabled
29 1 = Main Mode Enabled; 0 = MM Disabled
30 1 = IKE/IPsec Enabled; 0 = IKE/IPsec
Disabled
31 1 = Bitmap VALID; 0 = INVALID
All others RESERVED
The future assignment of any of the reserved values will be
documented in a revision of RFC 4171.
74.12. IsnsNodeIndexId
The identifier for the unique integer Node Index associated
with a storage node. This index provides a 1-to-1 mapping
to an iSCSI node name. The iSCSI node name maximum length
is too long to be used for an index directly. The iSCSI
node index used for a specific iSCSI node name is identical
in all DDs, and is persistent across server
reinitializations when the iSCSI node is a member of a
Discovery Domain (DD) or is registered as a Control Node.
Furthermore, index values for recently deregistered objects
SHOULD NOT be reused in the short term.
74.13. IsnsIscsiNodeType
Expires August 17, 2014 [Page 144]
Internet-Draft SMIv2 Textual Conventions February 2014
The iSCSI Node Type defines the functions of the registered
object. The definitions of each setting are defined in
RFC 4171.
Bit Node Type
--------- ---------
29 Control
30 Initiator
31 Target
All others RESERVED
Setting a bit to 1 indicates the node has the corresponding
characteristics. The future assignment of any of the
reserved values will be documented in a revision of
RFC 4171.
74.14. IsnsFcClassOfServiceType
This defines the Fibre Channel Class of Service types
that are supported by the registered port. The
definitions are as defined in RFC 4171.
Bit FC COS Type
--------- ----------------
28 Fibre Channel Class 3 Supported
29 Fibre Channel Class 2 Supported
All others RESERVED
Setting a bit to 1 indicates the class of service is
supported. The future assignment of any of the
reserved values will be documented in a revision of
RFC 4171.
74.15. IsnsIscsiScnType
Expires August 17, 2014 [Page 145]
Internet-Draft SMIv2 Textual Conventions February 2014
The iSCSI Node State Change Notification (SCN) values
for a node as defined in RFC 4171.
Bit Description
------------ ----------------
24 Initiator and self information only
25 Target and self information only
26 Management registration/SCN
27 Object removed
28 Object added
29 Object updated
30 DD or DDS member removed (Mgmt
Reg/SCN only)
31 (Lsb) DD or DDS member added (Mgmt
Reg/SCN only)
All others Reserved
Setting a bit to 1 indicates that type of SCN is enabled.
The future assignment of any of the reserved values will be
documented in a revision of RFC 4171.
74.16. IsnsIfcpScnType
The iFCP State Change Notification (SCN) values for an iFCP
object as defined in RFC 4171.
Bit Description
------------ ----------------
24 Initiator and self information only
25 Target and self information only
26 Management registration/SCN
27 Object removed
28 Object added
29 Object updated
30 DD or DDS member removed (Mgmt
Reg/SCN only)
31 (Lsb) DD or DDS member added (Mgmt
Reg/SCN only)
All others Reserved
Setting a bit to 1 indicates that type of SCN is enabled.
The future assignment of any of the reserved values will be
documented in a revision of RFC 4171.
74.17. IsnsFcPortRoleType
Expires August 17, 2014 [Page 146]
Internet-Draft SMIv2 Textual Conventions February 2014
The FC Port Role defines the functions of the registered
object. The definitions of each setting are defined in
RFC 4171.
Bit Port Role
--------- ---------
29 Control
30 FCP Initiator
31 FCP Target
All others RESERVED
Setting a bit to 1 indicates the port has the corresponding
characteristics. The future assignment of any of the
reserved values will be documented in a revision of
RFC 4171.
74.18. IsnsSrvrDiscoveryMethodsType
The types of iSNS Server discovery methods that are enabled
on an iSNS Server. The options are DHCP, Service Location
Protocol (SLP), multicast group iSNS heartbeat, broadcast
group iSNS heartbeat, configured server list, and other.
The iSNS Server may support additional discovery methods
not indicated.
75. ITU-ALARM-TC-MIB (revision 2004-09-09 00:00)
This MIB module defines the ITU Alarm textual convention for objects
not expected to require regular extension. Copyright (C) The
Internet Society (2004). The initial version of this MIB module was
published in RFC 3877. For full legal notices see the RFC itself.
Supplementary information may be available on:
http://www.ietf.org/copyrights/ianamib.html
75.1. ItuPerceivedSeverity
ITU perceived severity values
75.2. ItuTrendIndication
ITU trend indication values for alarms.
Expires August 17, 2014 [Page 147]
Internet-Draft SMIv2 Textual Conventions February 2014
76. Job-Monitoring-MIB (revision 1999-02-19 00:00)
The MIB module for monitoring job in servers, printers, and other
devices. Version: 1.0
76.1. JmUTF8StringTC
To facilitate internationalization, this TC represents
information taken from the ISO/IEC IS 10646-1 character set,
encoded as an octet string using the UTF-8 character encoding
scheme.
See section 3.6.1, entitled: 'Text generated by the server or
device'.
76.2. JmJobStringTC
To facilitate internationalization, this TC represents
information using any coded character set registered by IANA as
specified in section 3.7. While it is recommended that the
coded character set be UTF-8 [UTF-8], the actual coded
character set SHALL be indicated by the value of the
jobCodedCharSet(8) attribute for the job.
See section 3.6.2, entitled: 'Text supplied by the job
submitter'.
76.3. JmNaturalLanguageTagTC
An IETF RFC 1766-compliant 'language tag', with zero or more
sub-tags that identify a natural language. While RFC 1766
specifies that the US-ASCII values are case-insensitive, this
MIB specification requires that all characters SHALL be lower
case in order to simplify comparing by management applications.
See section 3.6.1, entitled: 'Text generated by the server or
device' and section 3.6.2, entitled: 'Text supplied by the job
submitter'.
76.4. JmTimeStampTC
Expires August 17, 2014 [Page 148]
Internet-Draft SMIv2 Textual Conventions February 2014
The simple time at which an event took place. The units are
in seconds since the system was booted.
NOTE - JmTimeStampTC is defined in units of seconds, rather
than 100ths of seconds, so as to be simpler for agents to
implement (even if they have to implement the 100ths of a
second to comply with implementing sysUpTime in MIB-II[mib-
II].)
NOTE - JmTimeStampTC is defined as an Integer32 so that it can
be used as a value of an attribute, i.e., as a value of the
jmAttributeValueAsInteger object. The TimeStamp textual-
convention defined in SNMPv2-TC [SMIv2-TC] is defined as an
APPLICATION 3 IMPLICIT INTEGER tag, not an Integer32 which is
defined in SNMPv2-SMI [SMIv2-TC] as UNIVERSAL 2 IMPLICIT
INTEGER, so cannot be used in this MIB as one of the values of
jmAttributeValueAsInteger.
76.5. JmJobSourcePlatformTypeTC
The source platform type that can submit jobs to servers or
devices in any of the 3 configurations.
This is a type 2 enumeration. See Section 3.7.1.2. See also
IANA operating-system-names registry.
76.6. JmFinishingTC
Expires August 17, 2014 [Page 149]
Internet-Draft SMIv2 Textual Conventions February 2014
The type of finishing operation.
These values are the same as the enum values of the IPP
'finishings' attribute. See Section 3.7.1.2.
other(1),
Some other finishing operation besides one of the specified
or registered values.
unknown(2),
The finishing is unknown.
none(3),
Perform no finishing.
staple(4),
Bind the document(s) with one or more staples. The exact
number and placement of the staples is site-defined.
punch(5),
Holes are required in the finished document. The exact
number and placement of the holes is site-defined. The
punch specification MAY be satisfied (in a site- and
implementation-specific manner) either by
drilling/punching, or by substituting pre-drilled media.
cover(6),
Select a non-printed (or pre-printed) cover for the
document. This does not supplant the specification of a
printed cover (on cover stock medium) by the document
itself.
bind(7)
Binding is to be applied to the document; the type and
placement of the binding is product-specific.
This is a type 2 enumeration. See Section 3.7.1.2.
76.7. JmPrintQualityTC
Print quality settings.
These values are the same as the enum values of the IPP 'print-
quality' attribute. See Section 3.7.1.2.
This is a type 2 enumeration. See Section 3.7.1.2.
Expires August 17, 2014 [Page 150]
Internet-Draft SMIv2 Textual Conventions February 2014
76.8. JmPrinterResolutionTC
Printer resolutions.
Nine octets consisting of two 4-octet SIGNED-INTEGERs followed
by a SIGNED-BYTE. The values are the same as those specified
in the Printer MIB [printmib]. The first SIGNED-INTEGER
contains the value of prtMarkerAddressabilityXFeedDir. The
second SIGNED-INTEGER contains the value of
prtMarkerAddressabilityFeedDir. The SIGNED-BYTE contains the
value of prtMarkerAddressabilityUnit.
Note: the latter value is either 3 (tenThousandsOfInches) or 4
(micrometers) and the addressability is in 10,000 units of
measure. Thus the SIGNED-INTEGERs represent integral values in
either dots-per-inch or dots-per-centimeter.
The syntax is the same as the IPP 'printer-resolution'
attribute. See Section 3.7.1.2.
76.9. JmTonerEconomyTC
Toner economy settings.
This is a type 2 enumeration. See Section 3.7.1.2.
76.10. JmBooleanTC
Boolean true or false value.
This is a type 2 enumeration. See Section 3.7.1.2.
76.11. JmMediumTypeTC
Identifies the type of medium.
other(1),
The type is neither one of the values listed in this
specification nor a registered value.
unknown(2),
The type is not known.
stationery(3),
Expires August 17, 2014 [Page 151]
Internet-Draft SMIv2 Textual Conventions February 2014
Separately cut sheets of an opaque material.
transparency(4),
Separately cut sheets of a transparent material.
envelope(5),
Envelopes that can be used for conventional mailing
purposes.
envelopePlain(6),
Envelopes that are not preprinted and have no windows.
envelopeWindow(7),
Envelopes that have windows for addressing purposes.
continuousLong(8),
Continuously connected sheets of an opaque material
connected along the long edge.
continuousShort(9),
Continuously connected sheets of an opaque material
connected along the short edge.
tabStock(10),
Media with tabs.
multiPartForm(11),
Form medium composed of multiple layers not pre-attached to
one another; each sheet MAY be drawn separately from an
input source.
labels(12),
Label-stock.
multiLayer(13)
Form medium composed of multiple layers which are pre-
attached to one another, e.g. for use with impact printers.
This is a type 2 enumeration. See Section 3.7.1.2. These enum
values correspond to the keyword name strings of the
prtInputMediaType object in the Printer MIB [print-mib]. There
is no printer description attribute in IPP/1.0 that represents
these values.
76.12. JmJobCollationTypeTC
Expires August 17, 2014 [Page 152]
Internet-Draft SMIv2 Textual Conventions February 2014
This value is the type of job collation. Implementations that
don't support multiple documents or don't support multiple
copies SHALL NOT support the uncollatedDocuments(5) value.
This is a type 2 enumeration. See Section 3.7.1.2. See also
Section 3.4, entitled 'Monitoring Job Progress'.
76.13. JmJobSubmissionIDTypeTC
Identifies the format type of a job submission ID.
Each job submission ID is a fixed-length, 48-octet printable
US-ASCII [US-ASCII] coded character string containing no
control characters, consisting of the fields defined in section
3.5.1.
This is like a type 2 enumeration. See section 3.7.3.
76.14. JmJobStateTC
The current state of the job (pending, processing, completed,
etc.). The following figure shows the normal job state
transitions:
+----> canceled(7)
/
+---> pending(3) -------> processing(5) ------+------> completed(9)
| ^ ^ \
--->+ | | +----> aborted(8)
| v v /
+---> pendingHeld(4) processingStopped(6) ---+
Figure 4 - Normal Job State Transitions
Normally a job progresses from left to right. Other state
transitions are unlikely, but are not forbidden. Not shown are
the transitions to the canceled state from the pending,
pendingHeld, and processingStopped states.
Jobs in the pending, processing, and processingStopped states
are called 'active', while jobs in the pendingHeld, canceled,
aborted, and completed states are called 'inactive'. Jobs
reach one of the three terminal states: completed, canceled, or
aborted, after the jobs have completed all activity, and all
MIB objects and attributes have reached their final values for
Expires August 17, 2014 [Page 153]
Internet-Draft SMIv2 Textual Conventions February 2014
the job.
These values are the same as the enum values of the IPP 'job-
state' job attribute. See Section 3.7.1.2.
unknown(2),
The job state is not known, or its state is indeterminate.
pending(3),
The job is a candidate to start processing, but is not yet
processing.
pendingHeld(4),
The job is not a candidate for processing for any number of
reasons but will return to the pending state as soon as the
reasons are no longer present. The job's
jmJobStateReasons1 object and/or jobStateReasonsN (N=2..4)
attributes SHALL indicate why the job is no longer a
candidate for processing. The reasons are represented as
bits in the jmJobStateReasons1 object and/or
jobStateReasonsN (N=2..4) attributes. See the
JmJobStateReasonsNTC (N=1..4) textual convention for the
specification of each reason.
processing(5),
One or more of:
1. the job is using, or is attempting to use, one or
more purely software processes that are analyzing,
creating, or interpreting a PDL, etc.,
2. the job is using, or is attempting to use, one or
more hardware devices that are interpreting a PDL,
making mark on a medium, and/or performing finishing,
such as stapling, etc., OR
3. (configuration 2) the server has made the job ready
for printing, but the output device is not yet printing
it, either because the job hasn't reached the output
device or because the job is queued in the output
device or some other spooler, awaiting the output
device to print it.
When the job is in the processing state, the entire job
state includes the detailed status represented in the
device MIB indicated by the hrDeviceIndex value of the
job's physicalDevice attribute, if the agent implements
such a device MIB.
Expires August 17, 2014 [Page 154]
Internet-Draft SMIv2 Textual Conventions February 2014
Implementations MAY, though they NEED NOT, include
additional values in the job's jmJobStateReasons1 object
to indicate the progress of the job, such as adding the
jobPrinting value to indicate when the device is actually
making marks on a medium and/or the processingToStopPoint
value to indicate that the server or device is in the
process of canceling or aborting the job.
processingStopped(6),
The job has stopped while processing for any number of
reasons and will return to the processing state as soon
as the reasons are no longer present.
The job's jmJobStateReasons1 object and/or the job's
jobStateReasonsN (N=2..4) attributes MAY indicate why the
job has stopped processing. For example, if the output
device is stopped, the deviceStopped value MAY be
included in the job's jmJobStateReasons1 object.
NOTE - When an output device is stopped, the device
usually indicates its condition in human readable form
at the device. The management application can obtain
more complete device status remotely by querying the
appropriate device MIB using the job's deviceIndex
attribute(s), if the agent implements such a device MIB
canceled(7),
A client has canceled the job and the server or device
has completed canceling the job AND all MIB objects and
attributes have reached their final values for the job.
While the server or device is canceling the job, the
job's jmJobStateReasons1 object SHOULD contain the
processingToStopPoint value and one of the
canceledByUser, canceledByOperator, or canceledAtDevice
values. The canceledByUser, canceledByOperator, or
canceledAtDevice values remain while the job is in the
canceled state.
aborted(8),
The job has been aborted by the system, usually while the
job was in the processing or processingStopped state and
the server or device has completed aborting the job AND
all MIB objects and attributes have reached their final
values for the job. While the server or device is
aborting the job, the job's jmJobStateReasons1 object MAY
contain the processingToStopPoint and abortedBySystem
values. If implemented, the abortedBySystem value SHALL
remain while the job is in the aborted state.
Expires August 17, 2014 [Page 155]
Internet-Draft SMIv2 Textual Conventions February 2014
completed(9)
The job has completed successfully or with warnings or
errors after processing and all of the media have been
successfully stacked in the appropriate output bin(s) AND
all MIB objects and attributes have reached their final
values for the job. The job's jmJobStateReasons1 object
SHOULD contain one of: completedSuccessfully,
completedWithWarnings, or completedWithErrors values.
This is a type 2 enumeration. See Section 3.7.1.2.
76.15. JmAttributeTypeTC
The type of the attribute which identifies the attribute.
NOTE - The enum assignments are grouped logically with values
assigned in groups of 20, so that additional values may be
registered in the future and assigned a value that is part of
their logical grouping.
Values in the range 2**30 to 2**31-1 are reserved for private
or experimental usage. This range corresponds to the same
range reserved in IPP. Implementers are warned that use of
such values may conflict with other implementations.
Implementers are encouraged to request registration of enum
values following the procedures in Section 3.7.1.
See Section 3.2 entitled 'The Attribute Mechanism' for a
description of this textual-convention and its use in the
jmAttributeTable. See Section 3.3.8 for the specification of
each attribute. The comment(s) after each enum assignment
specifies the data type(s) of the attribute.
This is a type 2 enumeration. See Section 3.7.1.2.
76.16. JmJobServiceTypesTC
Specifies the type(s) of service to which the job has been
submitted (print, fax, scan, etc.). The service type is
represented as an enum that is bit encoded with each job
service type so that more general and arbitrary services can be
created, such as services with more than one destination type,
or ones with only a source or only a destination. For example,
a job service might scan, faxOut, and print a single job. In
this case, three bits would be set in the jobServiceTypes
attribute, corresponding to the hexadecimal values: 0x8 + 0x20
Expires August 17, 2014 [Page 156]
Internet-Draft SMIv2 Textual Conventions February 2014
+ 0x4, respectively, yielding: 0x2C.
Whether this attribute is set from a job attribute supplied by
the job submission client or is set by the recipient job
submission server or device depends on the job submission
protocol. With either implementation, the agent SHALL return a
non-zero value for this attribute indicating the type of the
job.
One of the purposes of this attribute is to permit a requester
to filter out jobs that are not of interest. For example, a
printer operator MAY only be interested in jobs that include
printing. That is why the attribute is in the job
identification category.
The following service component types are defined (in
hexadecimal) and are assigned a separate bit value for use with
the jobServiceTypes attribute:
other 0x1
The job contains some instructions that are not one of the
identified types.
unknown 0x2
The job contains some instructions whose type is unknown to
the agent.
print 0x4
The job contains some instructions that specify printing
scan 0x8
The job contains some instructions that specify scanning
faxIn 0x10
The job contains some instructions that specify receive fax
faxOut 0x20
The job contains some instructions that specify sending fax
getFile 0x40
The job contains some instructions that specify accessing
files or documents
putFile 0x80
The job contains some instructions that specify storing
files or documents
mailList 0x100
Expires August 17, 2014 [Page 157]
Internet-Draft SMIv2 Textual Conventions February 2014
The job contains some instructions that specify
distribution of documents using an electronic mail system.
These bit definitions are the equivalent of a type 2 enum
except that combinations of them MAY be used together. See
section 3.7.1.2.
76.17. JmJobStateReasons1TC
The JmJobStateReasonsNTC (N=1..4) textual-conventions are used
with the jmJobStateReasons1 object and jobStateReasonsN
(N=2..4), respectively, to provide additional information
regarding the current jmJobState object value. These values
MAY be used with any job state or states for which the reason
makes sense. See section 3.3.9.1 for the specification of each
bit value defined for use with the JmJobStateReasons1TC.
These bit definitions are the equivalent of a type 2 enum
except that combinations of bits may be used together. See
section 3.7.1.2.
76.18. JmJobStateReasons2TC
This textual-convention is used with the jobStateReasons2
attribute to provides additional information regarding the
jmJobState object. See section 3.3.9.2 for the specification
of JmJobStateReasons2TC. See section 3.3.9.1 for the
description under JmJobStateReasons1TC for additional
information that applies to all reasons.
These bit definitions are the equivalent of a type 2 enum
except that combinations of them may be used together. See
section 3.7.1.2.
76.19. JmJobStateReasons3TC
This textual-convention is used with the jobStateReasons3
attribute to provides additional information regarding the
jmJobState object. See section 3.3.9.3 for the specification
of JmJobStateReasons3TC. See section 3.3.9.1 for the
description under JmJobStateReasons1TC for additional
information that applies to all reasons.
These bit definitions are the equivalent of a type 2 enum
except that combinations of them may be used together. See
Expires August 17, 2014 [Page 158]
Internet-Draft SMIv2 Textual Conventions February 2014
section 3.7.1.2.
76.20. JmJobStateReasons4TC
This textual-convention is used in the jobStateReasons4
attribute to provides additional information regarding the
jmJobState object. See section 3.3.9.4 for the specification
of JmJobStateReasons4TC. See section 3.3.9.1 for the
description under JmJobStateReasons1TC for additional
information that applies to all reasons.
These bit definitions are the equivalent of a type 2 enum
except that combinations of them may be used together. See
section 3.7.1.2.
77. L2TP-MIB (revision 2002-08-23 00:00)
The MIB module that describes managed objects of general use by the
Layer Two Transport Protocol.
77.1. L2tpMilliSeconds
A period of time measured in units of .001 of seconds
when used in conjunction with the DISPLAY-HINT will
show seconds and fractions of second with a resolution
of .001 of a second.
78. LANGTAG-TC-MIB (revision 2007-11-09 00:00)
This MIB module defines a textual convention for representing BCP 47
language tags.
78.1. LangTag
Expires August 17, 2014 [Page 159]
Internet-Draft SMIv2 Textual Conventions February 2014
A language tag, constructed in accordance with BCP 47.
Only lowercase characters are allowed. The purpose of this
restriction is to provide unique language tags for use as
indexes. BCP 47 recommends case conventions for user
interfaces, but objects using this TEXTUAL-CONVENTION MUST
use only lowercase.
Values MUST be well-formed language tags, in conformance
with the definition of well-formed tags in BCP 47. An
implementation MAY further limit the values it accepts to
those permitted by a 'validating' processor, as defined in
BCP 47.
In theory, BCP 47 language tags are of unlimited length.
The language tag described in this TEXTUAL-CONVENTION is of
limited length. The analysis of language tag lengths in BCP
47 confirms that this limit will not pose a problem in
practice. In particular, this length is greater than the
minimum requirements set out in Section 4.3.1.
A zero-length language tag is not a valid language tag.
This can be used to express 'language tag absent' where
required, for example, when used as an index field.
79. LISP-MIB (revision 2013-10-21 00:00)
This MIB module contains managed objects to support monitoring
devices that support the Locator/ID Separation Protocol (LISP).
Copyright (c) 2013 IETF Trust and the persons identified as authors
of the code. All rights reserved. Redistribution and use in source
and binary forms, with or without modification, is permitted pursuant
to, and subject to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info).
79.1. LispAddressType
LISP architecture can be applied to a wide variety of
address-families. This textual-convention is a generalization
for representing addresses belonging to those address-families.
For convenience, this document refers to any such address as a
LISP address. LispAddressType textual-convention consists of
Expires August 17, 2014 [Page 160]
Internet-Draft SMIv2 Textual Conventions February 2014
the following four-tuple:
1. IANA Address Family Number: A field of length 2 octets,
whose value is of the form following the assigned
AddressFamilyNumbers textual-convention described in
IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS, available from
http://www.iana.org/assignments/ianaaddressfamilynumbers-mib.
The enumerations are also listed in [IANA]. Note that this
list of address family numbers is maintained by IANA.
2. Length of LISP address: A field of length 1 octet, whose
value indicates the octet-length of the next (third)
field of this LispAddressType four-tuple.
3. LISP address: A field of variable length as indicated in
the previous (second) field, whose value is an address
of the IANA Address Family indicated in the first field
of this LispAddressType four-tuple. Note that any of
the IANA Address Families can be represented.
Particularly when the address family is LISP Canonical
Address Format (LCAF)
with IANA-assigned Address Family Number 16387, then the
first octet of this field indicates the LCAF type, and the
rest of this field is same as the encoding format of the
LISP Canonical Address after the length field, as defined
in LCAF document.
4. Mask-length of address: A field of length 1 octet, whose
value is the mask-length to be applied to the LISP
address specified in the previous (third) field.
To illustrate the use of this object, consider the LISP MIB
Object below titled lispMapCacheEntry. This object begins
with the following entities:
lispMapCacheEntry ::= SEQUENCE {
lispMapCacheEidLength INTEGER,
lispMapCacheEid LispAddressType,
... [skip] ...
Example 1: Suppose that the IPv4 EID-Prefix stored is
192.0.2.0/24. In this case, the values within
lispMapCacheEntry would be:
lispMapCacheEidLength = 8
lispMapCacheEid = 1, 4, 192.0.2.0, 24
Expires August 17, 2014 [Page 161]
Internet-Draft SMIv2 Textual Conventions February 2014
... [skip] ...
where 8 is the total length in octets of the next object
(lispMapCacheEID of type LispAddressType). Then, the value
1 indicates the IPv4 AF (per the
IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 4 indicates that
the AF is 4 octets in length, 192.0.2.0 is the IPv4 address,
and the value 24 is the mask-length in bits. Note that the
lispMapCacheEidLength value of 8 is used to compute the
length of the fourth (last) field in lispMapCacheEid to be 1
octet -- as computed by 8 - (2 + 1 + 4) = 1.
Example 2: Suppose that the IPv6 EID-Prefix stored is
2001:db8:a::/48. In this case, the values within
lispMapCacheEntry would be:
lispMapCacheEidLength = 20
lispMapCacheEid = 2, 16, 2001:db8:a::, 48
... [skip] ...
where 20 is the total length in octets of the next object
(lispMapCacheEID of type LispAddressType). Then, the value
2 indicates the IPv6 AF (per the
IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 16 indicates
that the AF is 16 octets in length, 2001:db8:a:: is the IPv6
address, and the value 48 is the mask-length in bits. Note
that the lispMapCacheEidLength value of 20 is used to
compute the length of the fourth (last) field in
lispMapCacheEid to be 1 octet -- as computed by
20 - (2 + 1 + 16) = 1.
Example 3: As an example where LCAF is used, suppose
that the IPv4 EID-Prefix stored is 192.0.2.0/24 and it
is part of LISP Instance ID 101. In this case, the values
within lispMapCacheEntry would be:
lispMapCacheEidLength = 11
lispMapCacheEid = 16387, 7, 2, 101, 1, 192.0.2.0, 24
... [skip] ...
where 11 is the total length in octets of the next object
(lispMapCacheEID of type LispAddressType). Then, the value
16387 indicates the LCAF AF (see the
Expires August 17, 2014 [Page 162]
Internet-Draft SMIv2 Textual Conventions February 2014
IANA-ADDRESS-FAMILY-NUMBERS-MIB), the value 7 indicates that
the LCAF AF is 7 octets in length in this case, 2 indicates
that LCAF Type 2 encoding is used (see the LCAF document), 101
gives the Instance ID, 1 gives the AFI (per the
IANA-ADDRESS-FAMILY-NUMBERS-MIB) for an IPv4 address, 192.0.2.0
is the IPv4 address, and 24 is the mask-length in bits. Note
that the lispMapCacheEidLength value of 11 octets is used to
compute the length of the last field in lispMapCacheEid to be 1
octet -- as computed by 11 - (2 + 1 + 1 + 1 + 1 + 4) = 1.
Note: all LISP header formats and locations of specific
flags, bits, and fields are as given in the base LISP
references of RFC 6830, RFC 6832, and RFC 6833.
80. LMP-MIB (revision 2006-08-14 00:00)
Copyright (C) 2006 The Internet Society. This version of the MIB
module is part of RFC 4631; see the RFC itself for full legal
notices. This MIB module contains managed object definitions for the
Link Management Protocol (LMP) as defined in 'Link Management
Protocol'.
80.1. LmpInterval
The interval delay, in milliseconds.
80.2. LmpRetransmitInterval
The retransmission interval delay in milliseconds.
80.3. LmpNodeId
Represents a Node ID in network byte order. Node ID is an
address of type IPv4.
81. MAU-MIB (revision 2007-04-21 00:00)
Management information for 802.3 MAUs. The following reference is
used throughout this MIB module: [IEEE802.3] refers to: IEEE Std
802.3, 2005 Edition: 'IEEE Standard for Information technology -
Telecommunications and information exchange between systems - Local
and metropolitan area networks - Specific requirements - Part 3:
Carrier sense multiple access with collision detection (CSMA/CD)
Expires August 17, 2014 [Page 163]
Internet-Draft SMIv2 Textual Conventions February 2014
access method and physical layer specifications'. Of particular
interest is Clause 30, 'Management'. Copyright (C) The IETF Trust
(2007). This version of this MIB module is part of RFC 4836; see the
RFC itself for full legal notices.
81.1. JackType (deprecated)
********* THIS TC IS DEPRECATED **********
This TC has been deprecated in favour of
IANAifJackType.
Common enumeration values for repeater
and interface MAU jack types.
82. MIDCOM-MIB (revision 2007-08-09 10:11)
This MIB module defines a set of basic objects for configuring
middleboxes, such as firewalls and network address translators, in
order to enable communication across these devices. Managed objects
defined in this MIB module are structured in three kinds of objects:
- transaction objects required according to the MIDCOM protocol
requirements defined in RFC 3304 and according to the MIDCOM protocol
semantics defined in RFC 3989, - configuration objects that can be
used for retrieving or setting parameters of the implementation of
transaction objects, - optional monitoring objects that provide
information about used resource and statistics The transaction
objects are organized in two subtrees: - objects modeling MIDCOM
policy rules in the midcomRuleTable - objects modeling MIDCOM policy
rule groups in the midcomGroupTable Note that typically,
configuration objects are not intended to be written by MIDCOM
clients. In general, write access to these objects needs to be
restricted more strictly than write access to objects in the
transaction subtrees. Copyright (C) The Internet Society (2008).
This version of this MIB module is part of RFC 5190; see the RFC
itself for full legal notices.
82.1. MidcomNatBindMode
An indicator of the kind of NAT resources used by a policy
rule. This definition corresponds to the definition of
NatBindMode in the NAT-MIB (RFC 4008). Value none(3) can
be used to indicate that the policy rule does not use
any NAT binding.
Expires August 17, 2014 [Page 164]
Internet-Draft SMIv2 Textual Conventions February 2014
82.2. MidcomNatSessionIdOrZero
A unique ID that is assigned to each NAT session by
a NAT implementation. This definition corresponds to
the definition of NatSessionId in the NAT-MIB (RFC 4008).
Value 0 can be used to indicate that the policy rule does
not use any NAT binding.
83. MIP-MIB (revision 1996-06-04 00:00)
The MIB Module for the Mobile IP.
83.1. RegistrationFlags
This data type is used to define the registration
flags for Mobile IP registration extension:
vjCompression
-- Request to use VJ compression
gre
-- Request to use GRE
minEnc
-- Request to use minimal encapsulation
decapsulationByMN
-- Decapsulation by mobile node
broadcastDatagram
-- Request to receive broadcasts
simultaneoursBindings
-- Request to retain prior binding(s).
84. MOBILEIPV6-MIB (revision 2006-02-01 00:00)
The MIB module for monitoring Mobile-IPv6 entities. Copyright (C)
The Internet Society 2006. This version of this MIB module is part
of RFC 4295; see the RFC itself for full legal notices.
84.1. Mip6BURequestRejectionCode
The value of the status field in the Binding
Acknowledgment message when the Binding Update
was rejected.
Expires August 17, 2014 [Page 165]
Internet-Draft SMIv2 Textual Conventions February 2014
85. MPLS-FTN-STD-MIB (revision 2004-06-03 00:00)
Copyright (C) The Internet Society (2004). The initial version of
this MIB module was published in RFC 3814. For full legal notices
see the RFC itself or see:
http://www.ietf.org/copyrights/ianamib.html This MIB module contains
managed object definitions for specifying FEC to NHLFE (FTN) mappings
and corresponding performance for MPLS.
85.1. MplsFTNEntryIndex
Index for an entry in mplsFTNTable.
85.2. MplsFTNEntryIndexOrZero
Index for an entry in mplsFTNTable or the special value
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 when none or all
entries in mplsFTNTable need to be referenced.
86. MPLS-L3VPN-STD-MIB (revision 2006-01-23 00:00)
This MIB contains managed object definitions for the Layer-3
Multiprotocol Label Switching Virtual Private Networks. Copyright
(C) The Internet Society (2006). This version of this MIB module is
part of RFC4382; see the RFC itself for full legal notices.
86.1. MplsL3VpnName
An identifier that is assigned to each MPLS/BGP VPN and
is used to uniquely identify it. This is assigned by the
system operator or NMS and SHOULD be unique throughout
the MPLS domain. If this is the case, then this identifier
can then be used at any LSR within a specific MPLS domain
to identify this MPLS/BGP VPN. It may also be possible to
preserve the uniqueness of this identifier across MPLS
domain boundaries, in which case this identifier can then
be used to uniquely identify MPLS/BGP VPNs on a more global
basis. This object MAY be set to the VPN ID as defined in
RFC 2685.
Expires August 17, 2014 [Page 166]
Internet-Draft SMIv2 Textual Conventions February 2014
86.2. MplsL3VpnRouteDistinguisher
Syntax for a route distinguisher and route target
as defined in [RFC4364].
86.3. MplsL3VpnRtType
Used to define the type of a route target usage.
Route targets can be specified to be imported,
exported, or both. For a complete definition of a
route target, see [RFC4364].
87. MPLS-LSR-STD-MIB (revision 2004-06-03 00:00)
This MIB module contains managed object definitions for the
Multiprotocol Label Switching (MPLS) Router as defined in: Rosen, E.,
Viswanathan, A., and R. Callon, Multiprotocol Label Switching
Architecture, RFC 3031, January 2001. Copyright (C) The Internet
Society (2004). The initial version of this MIB module was published
in RFC 3812. For full legal notices see the RFC itself or see:
http://www.ietf.org/copyrights/ianamib.html
87.1. MplsIndexType
Expires August 17, 2014 [Page 167]
Internet-Draft SMIv2 Textual Conventions February 2014
This is an octet string that can be used as a table
index in cases where a large addressable space is
required such as on an LSR where many applications
may be provisioning labels.
Note that the string containing the single octet with
the value 0x00 is a reserved value used to represent
special cases. When this TEXTUAL-CONVENTION is used
as the SYNTAX of an object, the DESCRIPTION clause
MUST specify if this special value is valid and if so
what the special meaning is.
In systems that provide write access to the MPLS-LSR-STD
MIB, mplsIndexType SHOULD be used as a simple multi-digit
integer encoded as an octet string.
No further overloading of the meaning of an index SHOULD
be made.
In systems that do not offer write access to the MPLS-LSR-STD
MIB, the mplsIndexType may contain implicit formatting that is
specific to the implementation to convey additional
information such as interface index, physical card or
device, or application id. The interpretation of this
additional formatting is implementation dependent and
not covered in this document. Such formatting MUST
NOT impact the basic functionality of read-only access
to the MPLS-LSR-STD MIB by management applications that are
not aware of the formatting rules.
87.2. MplsIndexNextType
Expires August 17, 2014 [Page 168]
Internet-Draft SMIv2 Textual Conventions February 2014
When a MIB module is used for configuration, an object with
this SYNTAX always contains a legal value (a non-zero-length
string) for an index that is not currently used in the relevant
table. The Command Generator (Network Management Application)
reads this variable and uses the (non-zero-length string)
value read when creating a new row with an SNMP SET.
When the SET is performed, the Command Responder (agent) must
determine whether the value is indeed still unused; Two Network
Management Applications may attempt to create a row
(configuration entry) simultaneously and use the same value. If
it is currently unused, the SET succeeds and the Command
Responder (agent) changes the value of this object, according
to an implementation-specific algorithm. If the value is in
use, however, the SET fails. The Network Management
Application must then re-read this variable to obtain a new
usable value.
Note that the string containing the single octet with
the value 0x00 is a reserved value used to represent
the special case where no additional indexes can be
provisioned, or in systems that do not offer
write access, objects defined using this TEXTUAL-CONVENTION
MUST return the string containing the single
octet with the value 0x00.
88. MPLS-TC-STD-MIB (revision 2004-06-03 00:00)
Copyright (C) The Internet Society (2004). The initial version of
this MIB module was published in RFC 3811. For full legal notices
see the RFC itself or see:
http://www.ietf.org/copyrights/ianamib.html This MIB module defines
TEXTUAL-CONVENTIONs for concepts used in Multiprotocol Label
Switching (MPLS) networks.
88.1. MplsAtmVcIdentifier
Expires August 17, 2014 [Page 169]
Internet-Draft SMIv2 Textual Conventions February 2014
A Label Switching Router (LSR) that
creates LDP sessions on ATM interfaces
uses the VCI or VPI/VCI field to hold the
LDP Label.
VCI values MUST NOT be in the 0-31 range.
The values 0 to 31 are reserved for other uses
by the ITU and ATM Forum. The value
of 32 can only be used for the Control VC,
although values greater than 32 could be
configured for the Control VC.
If a value from 0 to 31 is used for a VCI
the management entity controlling the LDP
subsystem should reject this with an
inconsistentValue error. Also, if
the value of 32 is used for a VC which is
NOT the Control VC, this should
result in an inconsistentValue error.
88.2. MplsBitRate
If the value of this object is greater than zero,
then this represents the bandwidth of this MPLS
interface (or Label Switched Path) in units of
'1,000 bits per second'.
The value, when greater than zero, represents the
bandwidth of this MPLS interface (rounded to the
nearest 1,000) in units of 1,000 bits per second.
If the bandwidth of the MPLS interface is between
((n * 1000) - 500) and ((n * 1000) + 499), the value
of this object is n, such that n > 0.
If the value of this object is 0 (zero), this
means that the traffic over this MPLS interface is
considered to be best effort.
88.3. MplsBurstSize
The number of octets of MPLS data that the stream
may send back-to-back without concern for policing.
The value of zero indicates that an implementation
does not support Burst Size.
Expires August 17, 2014 [Page 170]
Internet-Draft SMIv2 Textual Conventions February 2014
88.4. MplsExtendedTunnelId
A unique identifier for an MPLS Tunnel. This may
represent an IPv4 address of the ingress or egress
LSR for the tunnel. This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP.
88.5. MplsLabel
This value represents an MPLS label as defined in
[RFC3031], [RFC3032], [RFC3034], [RFC3035] and
[RFC3471].
The label contents are specific to the label being
represented, such as:
* The label carried in an MPLS shim header
(for LDP this is the Generic Label) is a 20-bit
number represented by 4 octets. Bits 0-19 contain
a label or a reserved label value. Bits 20-31
MUST be zero.
The following is quoted directly from [RFC3032].
There are several reserved label values:
i. A value of 0 represents the
'IPv4 Explicit NULL Label'. This label
value is only legal at the bottom of the
label stack. It indicates that the label
stack must be popped, and the forwarding
of the packet must then be based on the
IPv4 header.
ii. A value of 1 represents the
'Router Alert Label'. This label value is
legal anywhere in the label stack except at
the bottom. When a received packet
contains this label value at the top of
the label stack, it is delivered to a
local software module for processing.
The actual forwarding of the packet
is determined by the label beneath it
Expires August 17, 2014 [Page 171]
Internet-Draft SMIv2 Textual Conventions February 2014
in the stack. However, if the packet is
forwarded further, the Router Alert Label
should be pushed back onto the label stack
before forwarding. The use of this label
is analogous to the use of the
'Router Alert Option' in IP packets
[RFC2113]. Since this label
cannot occur at the bottom of the stack,
it is not associated with a
particular network layer protocol.
iii. A value of 2 represents the
'IPv6 Explicit NULL Label'. This label
value is only legal at the bottom of the
label stack. It indicates that the label
stack must be popped, and the forwarding
of the packet must then be based on the
IPv6 header.
iv. A value of 3 represents the
'Implicit NULL Label'.
This is a label that an LSR may assign and
distribute, but which never actually
appears in the encapsulation. When an
LSR would otherwise replace the label
at the top of the stack with a new label,
but the new label is 'Implicit NULL',
the LSR will pop the stack instead of
doing the replacement. Although
this value may never appear in the
encapsulation, it needs to be specified in
the Label Distribution Protocol, so a value
is reserved.
v. Values 4-15 are reserved.
* The frame relay label can be either 10-bits or
23-bits depending on the DLCI field size and the
upper 22-bits or upper 9-bits must be zero,
respectively.
* For an ATM label the lower 16-bits represents the
VCI, the next 12-bits represents the VPI and the
remaining bits MUST be zero.
Expires August 17, 2014 [Page 172]
Internet-Draft SMIv2 Textual Conventions February 2014
* The Generalized-MPLS (GMPLS) label contains a
value greater than 2^24-1 and used in GMPLS
as defined in [RFC3471].
88.6. MplsLabelDistributionMethod
The label distribution method which is also called
the label advertisement mode [RFC3036].
Each interface on an LSR is configured to operate
in either Downstream Unsolicited or Downstream
on Demand.
88.7. MplsLdpIdentifier
The LDP identifier is a six octet
quantity which is used to identify a
Label Switching Router (LSR) label space.
The first four octets identify the LSR and
must be a globally unique value, such as a
32-bit router ID assigned to the LSR, and the
last two octets identify a specific label
space within the LSR.
88.8. MplsLsrIdentifier
The Label Switching Router (LSR) identifier is the
first 4 bytes of the Label Distribution Protocol
(LDP) identifier.
88.9. MplsLdpLabelType
The Layer 2 label types which are defined for MPLS
LDP and/or CR-LDP are generic(1), atm(2), or
frameRelay(3).
88.10. MplsLSPID
Expires August 17, 2014 [Page 173]
Internet-Draft SMIv2 Textual Conventions February 2014
A unique identifier within an MPLS network that is
assigned to each LSP. This is assigned at the head
end of the LSP and can be used by all LSRs
to identify this LSP. This value is piggybacked by
the signaling protocol when this LSP is signaled
within the network. This identifier can then be
used at each LSR to identify which labels are
being swapped to other labels for this LSP. This
object can also be used to disambiguate LSPs that
share the same RSVP sessions between the same
source and destination.
For LSPs established using CR-LDP, the LSPID is
composed of the ingress LSR Router ID (or any of
its own IPv4 addresses) and a locally unique
CR-LSP ID to that LSR. The first two bytes carry
the CR-LSPID, and the remaining 4 bytes carry
the Router ID. The LSPID is useful in network
management, in CR-LSP repair, and in using
an already established CR-LSP as a hop in
an ER-TLV.
For LSPs signaled using RSVP-TE, the LSP ID is
defined as a 16-bit (2 byte) identifier used
in the SENDER_TEMPLATE and the FILTER_SPEC
that can be changed to allow a sender to
share resources with itself. The length of this
object should only be 2 or 6 bytes. If the length
of this octet string is 2 bytes, then it must
identify an RSVP-TE LSPID, or it is 6 bytes,
it must contain a CR-LDP LSPID.
88.11. MplsLspType
Expires August 17, 2014 [Page 174]
Internet-Draft SMIv2 Textual Conventions February 2014
Types of Label Switch Paths (LSPs)
on a Label Switching Router (LSR) or a
Label Edge Router (LER) are:
unknown(1) -- if the LSP is not known
to be one of the following.
terminatingLsp(2) -- if the LSP terminates
on the LSR/LER, then this
is an egressing LSP
which ends on the LSR/LER,
originatingLsp(3) -- if the LSP originates
from this LSR/LER, then
this is an ingressing LSP
which is the head-end of
the LSP,
crossConnectingLsp(4) -- if the LSP ingresses
and egresses on the LSR,
then it is
cross-connecting on that
LSR.
88.12. MplsOwner
Expires August 17, 2014 [Page 175]
Internet-Draft SMIv2 Textual Conventions February 2014
This object indicates the local network
management subsystem that originally created
the object(s) in question. The values of
this enumeration are defined as follows:
unknown(1) - the local network management
subsystem cannot discern which
component created the object.
other(2) - the local network management
subsystem is able to discern which component
created the object, but the component is not
listed within the following choices,
e.g., command line interface (cli).
snmp(3) - The Simple Network Management Protocol
was used to configure this object initially.
ldp(4) - The Label Distribution Protocol was
used to configure this object initially.
crldp(5) - The Constraint-Based Label Distribution
Protocol was used to configure this object
initially.
rsvpTe(6) - The Resource Reservation Protocol was
used to configure this object initially.
policyAgent(7) - A policy agent (perhaps in
combination with one of the above protocols) was
used to configure this object initially.
An object created by any of the above choices
MAY be modified or destroyed by the same or a
different choice.
88.13. MplsPathIndexOrZero
A unique identifier used to identify a specific
path used by a tunnel. A value of 0 (zero) means
that no path is in use.
88.14. MplsPathIndex
A unique value to index (by Path number) an
entry in a table.
Expires August 17, 2014 [Page 176]
Internet-Draft SMIv2 Textual Conventions February 2014
88.15. MplsRetentionMode
The label retention mode which specifies whether
an LSR maintains a label binding for a FEC
learned from a neighbor that is not its next hop
for the FEC.
If the value is conservative(1) then advertised
label mappings are retained only if they will be
used to forward packets, i.e., if label came from
a valid next hop.
If the value is liberal(2) then all advertised
label mappings are retained whether they are from
a valid next hop or not.
88.16. MplsTunnelAffinity
Describes the configured 32-bit Include-any,
include-all, or exclude-all constraint for
constraint-based link selection.
88.17. MplsTunnelIndex
A unique index into mplsTunnelTable.
For tunnels signaled using RSVP, this value
should correspond to the RSVP Tunnel ID
used for the RSVP-TE session.
88.18. MplsTunnelInstanceIndex
The tunnel entry with instance index 0
should refer to the configured tunnel
interface (if one exists).
Values greater than 0, but less than or
equal to 65535, should be used to indicate
signaled (or backup) tunnel LSP instances.
For tunnel LSPs signaled using RSVP,
this value should correspond to the
RSVP LSP ID used for the RSVP-TE
LSP.
Values greater than 65535 apply to FRR
Expires August 17, 2014 [Page 177]
Internet-Draft SMIv2 Textual Conventions February 2014
detour instances.
88.19. TeHopAddressType
A value that represents a type of address for a
Traffic Engineered (TE) Tunnel hop.
unknown(0) An unknown address type. This value
MUST be used if the value of the
corresponding TeHopAddress object is a
zero-length string. It may also be
used to indicate a TeHopAddress which
is not in one of the formats defined
below.
ipv4(1) An IPv4 network address as defined by
the InetAddressIPv4 TEXTUAL-CONVENTION
[RFC3291].
ipv6(2) A global IPv6 address as defined by
the InetAddressIPv6 TEXTUAL-CONVENTION
[RFC3291].
asnumber(3) An Autonomous System (AS) number as
defined by the TeHopAddressAS
TEXTUAL-CONVENTION.
unnum(4) An unnumbered interface index as
defined by the TeHopAddressUnnum
TEXTUAL-CONVENTION.
lspid(5) An LSP ID for TE Tunnels
(RFC3212) as defined by the
MplsLSPID TEXTUAL-CONVENTION.
Each definition of a concrete TeHopAddressType
value must be accompanied by a definition
of a TEXTUAL-CONVENTION for use with that
TeHopAddress.
To support future extensions, the TeHopAddressType
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
Expires August 17, 2014 [Page 178]
Internet-Draft SMIv2 Textual Conventions February 2014
subset of these address types for a compliant
implementation.
Implementations must ensure that TeHopAddressType
objects and any dependent objects
(e.g., TeHopAddress objects) are consistent.
An inconsistentValue error must be generated
if an attempt to change a TeHopAddressType
object would, for example, lead to an
undefined TeHopAddress value that is
not defined herein. In particular,
TeHopAddressType/TeHopAddress pairs
must be changed together if the address
type changes (e.g., from ipv6(2) to ipv4(1)).
88.20. TeHopAddress
Expires August 17, 2014 [Page 179]
Internet-Draft SMIv2 Textual Conventions February 2014
Denotes a generic Tunnel hop address,
that is, the address of a node which
an LSP traverses, including the source
and destination nodes. An address may be
very concrete, for example, an IPv4 host
address (i.e., with prefix length 32);
if this IPv4 address is an interface
address, then that particular interface
must be traversed. An address may also
specify an 'abstract node', for example,
an IPv4 address with prefix length
less than 32, in which case, the LSP
can traverse any node whose address
falls in that range. An address may
also specify an Autonomous System (AS),
in which case the LSP can traverse any
node that falls within that AS.
A TeHopAddress value is always interpreted within
the context of an TeHopAddressType value. Every
usage of the TeHopAddress TEXTUAL-CONVENTION
is required to specify the TeHopAddressType object
which provides the context. It is suggested that
the TeHopAddressType object is logically registered
before the object(s) which use the TeHopAddress
TEXTUAL-CONVENTION if they appear in the
same logical row.
The value of a TeHopAddress object must always be
consistent with the value of the associated
TeHopAddressType object. Attempts to set a
TeHopAddress object to a value which is
inconsistent with the associated TeHopAddressType
must fail with an inconsistentValue error.
88.21. TeHopAddressAS
Represents a two or four octet AS number.
The AS number is represented in network byte
order (MSB first). A two-octet AS number has
the two MSB octets set to zero.
Expires August 17, 2014 [Page 180]
Internet-Draft SMIv2 Textual Conventions February 2014
88.22. TeHopAddressUnnum
Represents an unnumbered interface:
octets contents encoding
1-4 unnumbered interface network-byte order
The corresponding TeHopAddressType value is
unnum(5).
89. NAT-MIB (revision 2005-03-21 00:00)
This MIB module defines the generic managed objects for NAT.
Copyright (C) The Internet Society (2005). This version of this MIB
module is part of RFC 4008; see the RFC itself for full legal
notices.
89.1. NatProtocolType
A list of protocols that support the network
address translation. Inclusion of the values is
not intended to imply that those protocols
need to be supported. Any change in this
TEXTUAL-CONVENTION should also be reflected in
the definition of NatProtocolMap, which is a
BITS representation of this.
89.2. NatProtocolMap
A bitmap of protocol identifiers that support
the network address translation. Any change
in this TEXTUAL-CONVENTION should also be
reflected in the definition of NatProtocolType.
89.3. NatAddrMapId
A unique id that is assigned to each address map
by a NAT enabled device.
Expires August 17, 2014 [Page 181]
Internet-Draft SMIv2 Textual Conventions February 2014
89.4. NatBindIdOrZero
A unique id that is assigned to each bind by
a NAT enabled device. The bind id will be zero
in the case of a Symmetric NAT.
89.5. NatBindId
A unique id that is assigned to each bind by
a NAT enabled device.
89.6. NatSessionId
A unique id that is assigned to each session by
a NAT enabled device.
89.7. NatBindMode
An indication of whether the bind is
an address bind or an address port bind.
89.8. NatAssociationType
An indication of whether the association is
static or dynamic.
89.9. NatTranslationEntity
An indication of a) the direction of a session for
which an address map entry, address bind or port
bind is applicable, and b) the entity (source or
destination) within the session that is subject to
translation.
90. NETWORK-SERVICES-MIB (revision 2000-03-03 00:00)
The MIB module describing network service applications
Expires August 17, 2014 [Page 182]
Internet-Draft SMIv2 Textual Conventions February 2014
90.1. DistinguishedName
A Distinguished Name represented in accordance with
RFC 2253, presented in the UTF-8 charset defined in
RFC 2279.
90.2. URLString
A Uniform Resource Locator represented in accordance
with RFCs 1738 and 2368, presented in the NVT ASCII
charset defined in RFC 854.
91. NHDP-MIB (revision 2012-10-22 10:00)
This NHDP-MIB module is applicable to routers implementing the
Neighborhood Discovery Protocol defined in RFC 6130. Copyright (c)
2012 IETF Trust and the persons identified as authors of the code.
All rights reserved. Redistribution and use in source and binary
forms, with or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC 6779; see the RFC
itself for full legal notices.
91.1. NeighborIfIndex
Expires August 17, 2014 [Page 183]
Internet-Draft SMIv2 Textual Conventions February 2014
An arbitrary, locally unique identifier associated with a
virtual interface of a discovered NHDP neighbor.
Due to the nature of NHDP, the local router
may not know if two distinct addresses belong to the
same interface of a neighbor or to two different
interfaces. As the local router gains more
knowledge of its neighbors, its local view may change, and
this table will be updated to reflect the local router's
current understanding, associating address sets to neighbor
interfaces. The local router identifies a virtual neighbor
interface through the receipt of address lists advertised
through an NHDP HELLO message.
All objects of type NeighborIfIndex are assigned by the agent
out of a common number space.
The value for each discovered virtual neighbor
interface may not remain constant from
one re-initialization of the entity's network management
agent to the next re-initialization. If the
local router gains information associating two virtual
interfaces on a neighbor as a common interface,
then the agent MUST aggregate the two address sets to
a single index chosen from the set of aggregated indexes,
and it MUST update all tables in this
MIB module that are indexed by indexes
of type NeighborIfIndex. It MAY then reuse freed
index values following the next agent restart.
The specific value is meaningful only within a given SNMP
entity.
91.2. NeighborRouterIndex
Expires August 17, 2014 [Page 184]
Internet-Draft SMIv2 Textual Conventions February 2014
An arbitrary, locally unique identifier associated with a
virtual discovered neighbor (one or two hop). Due to the
nature of NHDP, the local router may identify
multiple virtual neighbors that, in fact, are one and
the same. Neighbors that are two hops away with more than
one advertised address will exhibit this behavior. As the
local router's knowledge of its neighbors' topology
increases, the local router will be able to associate
multiple virtual neighbor indexes into a single virtual
neighbor index chosen from the set of aggregated indexes;
it MUST update all tables in this MIB module indexed by these
indexes, and it MAY reuse the freed indexes following the
next agent re-initialization.
All objects of type NeighborRouterIndex are assigned by
the agent out of a common number space.
The NeighborRouterIndex defines a discovered NHDP peer
virtual neighbor of the local router.
The value for each discovered virtual neighbor index MUST
remain constant at least from one re-initialization of
the entity's network management agent to the next
re-initialization, except if an application is deleted
and re-created.
The specific value is meaningful only within a given SNMP
entity. A NeighborRouterIndex value MUST not be reused
until the next agent restart.
92. NHRP-MIB (revision 1999-08-26 00:00)
This MIB contains managed object definitions for the Next Hop
Resolution Procol, NHRP, as defined in RFC 2332 [17].
92.1. NhrpGenAddr
The value of an internetwork layer or NBMA address.
93. NTPv4-MIB (revision 2010-05-17 00:00)
The Management Information Base for NTP time entities. Copyright (c)
2010 IETF Trust and the persons identified as authors of the code.
Expires August 17, 2014 [Page 185]
Internet-Draft SMIv2 Textual Conventions February 2014
All rights reserved. Redistribution and use in source and binary
forms, with or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info).
93.1. NtpStratum
The NTP stratum, with 16 representing no stratum.
93.2. NtpDateTime
NTP date/time on the device, in 128-bit
NTP date format. If time is not syncronized, this
field shall be a zero-length string.
This trusted certificate (TC) is not to be used for objects
that are used to set the time of the node querying this
object. NTP should be used for this -- or at least SNTP.
94. OPT-IF-MIB (revision 2003-08-13 00:00)
The MIB module to describe pre-OTN and OTN interfaces. Copyright (C)
The Internet Society (2003). This version of this MIB module is part
of RFC 3591; see the RFC itself for full legal notices.
94.1. OptIfAcTI
The trace identifier (TI) accepted at the receiver.
94.2. OptIfBitRateK
Indicates the index 'k' that is used to
represent a supported bit rate and the different
versions of OPUk, ODUk and OTUk.
Allowed values of k are defined in ITU-T G.709.
Currently allowed values in G.709 are:
k=1 represents an approximate bit rate of 2.5 Gbit/s,
k=2 represents an approximate bit rate of 10 Gbit/s,
k=3 represents an approximate bit rate of 40 Gbit/s.
Expires August 17, 2014 [Page 186]
Internet-Draft SMIv2 Textual Conventions February 2014
94.3. OptIfDEGM
Indicates the threshold level for declaring a Degraded Signal
defect (dDEG). A dDEG shall be declared if OptIfDEGM
consecutive bad PM Seconds are detected.
94.4. OptIfDEGThr
Indicates the threshold level for declaring a performance
monitoring (PM) Second to be bad. A PM Second is declared bad if
the percentage of detected errored blocks in that second is
greater than or equal to OptIfDEGThr.
94.5. OptIfDirectionality
Indicates the directionality of an entity.
94.6. OptIfSinkOrSource
Indicates the directionality of an entity
that is allowed only to be a source or sink.
94.7. OptIfExDAPI
The Destination Access Point Identifier (DAPI)
expected by the receiver.
94.8. OptIfExSAPI
The Source Access Point Identifier (SAPI)
expected by the receiver.
94.9. OptIfIntervalNumber
Uniquely identifies a 15-minute interval. The interval
identified by 1 is the most recently completed interval, and
the interval identified by n is the interval immediately
preceding the one identified by n-1.
Expires August 17, 2014 [Page 187]
Internet-Draft SMIv2 Textual Conventions February 2014
94.10. OptIfTIMDetMode
Indicates the mode of the Trace Identifier Mismatch (TIM)
Detection function.
94.11. OptIfTxTI
The trace identifier (TI) transmitted.
95. OSPF-MIB (revision 2006-11-10 00:00)
The MIB module to describe the OSPF Version 2 Protocol. Note that
some objects in this MIB module may pose a significant security risk.
Refer to the Security Considerations section in RFC 4750 for more
information. Copyright (C) The IETF Trust (2006). This version of
this MIB module is part of RFC 4750; see the RFC itself for full
legal notices.
95.1. AreaID
An OSPF Area Identifier.
Note that the Area ID, in OSPF, has the same format
as an IP address, but has the function of defining
a summarization point for link state advertisements.
95.2. RouterID
A OSPF Router Identifier.
Note that the Router ID, in OSPF, has the same format
as an IP address, but identifies the router independent
of its IP address.
95.3. Metric
The OSPF internal metric.
Note that the OSPF metric is defined as an unsigned value
in the range.
Expires August 17, 2014 [Page 188]
Internet-Draft SMIv2 Textual Conventions February 2014
95.4. BigMetric
The OSPF external metric.
95.5. Status
An indication of the operability of an OSPF
function or feature. For example, the status
of an interface: 'enabled' indicates that
it is willing to communicate with other OSPF routers,
and 'disabled' indicates that it is not.
95.6. PositiveInteger
A positive integer. Values in excess are precluded as
unnecessary and prone to interoperability issues.
95.7. HelloRange
The range of intervals in seconds on which Hello messages
are exchanged.
95.8. UpToMaxAge
The values in seconds that one might find or configure
for variables bounded by the maximum age of an LSA.
95.9. DesignatedRouterPriority
The range of values defined for the priority of a system
for becoming the designated router.
95.10. TOSType
Expires August 17, 2014 [Page 189]
Internet-Draft SMIv2 Textual Conventions February 2014
Type of Service (TOS) is defined as a mapping to the IP
Type of Service Flags as defined in the IP Forwarding
Table MIB
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TYPE OF SERVICE | 0 |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
IP TOS IP TOS
Field Policy Field Policy
Contents Code Contents Code
0 0 0 0 ==> 0 0 0 0 1 ==> 2
0 0 1 0 ==> 4 0 0 1 1 ==> 6
0 1 0 0 ==> 8 0 1 0 1 ==> 10
0 1 1 0 ==> 12 0 1 1 1 ==> 14
1 0 0 0 ==> 16 1 0 0 1 ==> 18
1 0 1 0 ==> 20 1 0 1 1 ==> 22
1 1 0 0 ==> 24 1 1 0 1 ==> 26
1 1 1 0 ==> 28 1 1 1 1 ==> 30
The remaining values are left for future definition.
95.11. OspfAuthenticationType
The authentication type.
96. OSPFV3-MIB (revision 2009-08-13 00:00)
The MIB module for OSPF version 3. Copyright (c) 2009 IETF Trust and
the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met: - Redistributions of source code must retain the above
copyright notice, this list of conditions and the following
disclaimer. - Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with
the distribution. - Neither the name of Internet Society, IETF or
IETF Trust, nor the names of specific contributors, may be used to
endorse or promote products derived from this software without
specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE
COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
Expires August 17, 2014 [Page 190]
Internet-Draft SMIv2 Textual Conventions February 2014
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of
this MIB module is part of RFC 5643; see the RFC itself for full
legal notices.
96.1. Ospfv3UpToRefreshIntervalTC
The values one might be able to configure for
variables bounded by the Refresh Interval.
96.2. Ospfv3DeadIntervalRangeTC
The range, in seconds, of dead interval value.
96.3. Ospfv3RouterIdTC
A 32-bit, unsigned integer uniquely identifying the
router in the Autonomous System. To ensure
uniqueness, this may default to the value of one of
the router's IPv4 host addresses if IPv4 is
configured on the router.
96.4. Ospfv3LsIdTC
A unique 32-bit identifier of the piece of the
routing domain that is being described by a link
state advertisement. In contrast to OSPFv2, the
Link State ID (LSID) has no addressing semantics.
96.5. Ospfv3AreaIdTC
An OSPFv3 Area Identifier. A value of zero
identifies the backbone area.
Expires August 17, 2014 [Page 191]
Internet-Draft SMIv2 Textual Conventions February 2014
96.6. Ospfv3IfInstIdTC
An OSPFv3 Interface Instance ID.
96.7. Ospfv3LsaSequenceTC
The sequence number field is a signed 32-bit
integer. It is used to detect old and duplicate
link state advertisements. The space of
sequence numbers is linearly ordered. The
larger the sequence number, the more recent the
advertisement.
96.8. Ospfv3LsaAgeTC
The age of the link state advertisement in
seconds. The high-order bit of the LS age
field is considered the DoNotAge bit for
support of on-demand circuits.
97. P-BRIDGE-MIB (revision 2006-01-09 00:00)
The Bridge MIB Extension module for managing Priority and Multicast
Filtering, defined by IEEE 802.1D-1998, including Restricted Group
Registration defined by IEEE 802.1t-2001. Copyright (C) The Internet
Society (2006). This version of this MIB module is part of RFC 4363;
See the RFC itself for full legal notices.
97.1. EnabledStatus
A simple status value for the object.
98. PerfHist-TC-MIB (revision 2003-08-13 00:00)
This MIB Module provides Textual Conventions to be used by systems
supporting 15 minute based performance history counts. Copyright (C)
The Internet Society (2003). This version of this MIB module is part
of RFC 3593; see the RFC itself for full legal notices.
Expires August 17, 2014 [Page 192]
Internet-Draft SMIv2 Textual Conventions February 2014
98.1. PerfCurrentCount
A counter associated with a
performance measurement in a current 15
minute measurement interval. The value
of this counter starts from zero and is
increased when associated events occur,
until the end of the 15 minute interval.
At that time the value of the counter is
stored in the first 15 minute history
interval, and the CurrentCount is
restarted at zero. In the
case where the agent has no valid data
available for the current interval the
corresponding object instance is not
available and upon a retrieval request
a corresponding error message shall be
returned to indicate that this instance
does not exist (for example, a noSuchName
error for SNMPv1 and a noSuchInstance for
SNMPv2 GET operation).
98.2. PerfIntervalCount
Expires August 17, 2014 [Page 193]
Internet-Draft SMIv2 Textual Conventions February 2014
A counter associated with a
performance measurement in a previous
15 minute measurement interval. In the
case where the agent has no valid data
available for a particular interval the
corresponding object instance is not
available and upon a retrieval request
a corresponding error message shall be
returned to indicate that this instance
does not exist (for example, a noSuchName
error for SNMPv1 and a noSuchInstance for
SNMPv2 GET operation).
In a system supporting
a history of n intervals with
IntervalCount(1) and IntervalCount(n) the
most and least recent intervals
respectively, the following applies at
the end of a 15 minute interval:
- discard the value of IntervalCount(n)
- the value of IntervalCount(i) becomes that
of IntervalCount(i-1) for n >= i > 1
- the value of IntervalCount(1) becomes that
of CurrentCount
- the TotalCount, if supported, is adjusted.
98.3. PerfTotalCount
A counter associated with a
performance measurements aggregating the
previous valid 15 minute measurement
intervals. (Intervals for which no valid
data was available are not counted)
99. PIM-STD-MIB (revision 2007-11-02 00:00)
The MIB module for management of PIM routers. Copyright (C) The IETF
Trust (2007). This version of this MIB module is part of RFC 5060;
see the RFC itself for full legal notices.
99.1. PimMode
Expires August 17, 2014 [Page 194]
Internet-Draft SMIv2 Textual Conventions February 2014
The PIM mode in which a group is operating.
none(1) The group is not using PIM, which may be the
case if, for example, it is a link-local or
unroutable group address.
ssm(2) Source-Specific Multicast (SSM) with PIM Sparse
Mode.
asm(3) Any Source Multicast (ASM) with PIM Sparse
Mode.
bidir(4) Bidirectional PIM.
dm(5) PIM Dense Mode.
other(6) Any other PIM mode.
99.2. PimGroupMappingOriginType
The mechanism by which a PIM group mapping was learned.
fixed(1) Link-local or unroutable group mappings.
configRp(2) Local static RP configuration.
configSsm(3) Local SSM Group configuration.
bsr(4) The PIM Bootstrap Router (BSR) mechanism.
autoRP(5) Cisco's Auto-RP mechanism.
embedded(6) The Embedded-RP mechanism where the RP address
is embedded in the multicast group address.
other(7) Any other mechanism.
100. PINT-MIB (revision 2001-02-01 00:00)
This MIB defines the objects necessary to monitor PINT Services
100.1. PintServiceType
This TC describes the type of a PINT service.
Expires August 17, 2014 [Page 195]
Internet-Draft SMIv2 Textual Conventions February 2014
100.2. PintPerfStatPeriod
This TC describes the statistics period of time.
Note that the values of the counters indexed with a value
SinceReboot(4) can be potentially affected by a counter rollover.
It is the responsibility of the application using this object to
take into account that the counter has been zeroed each time it
reached a value of (2**32-1).
101. PKTC-IETF-MTA-MIB (revision 2006-09-18 00:00)
This MIB module defines the basic management object for the
Multimedia Terminal Adapter devices compliant with PacketCable and
IPCablecom requirements. Copyright (C) The IETF Trust (2006). This
version of this MIB module is part of RFC 4682; see the RFC itself
for full legal notices.
101.1. PktcMtaDevProvEncryptAlg
This textual convention defines various types of the
encryption algorithms used for the encryption of the MTA
configuration file. The description of the encryption
algorithm for each enumerated value is as follows:
'none(0)' no encryption is used,
'des64CbcMode(1)' DES 64-bit key in CBC mode,
't3Des192CbcMode(2)' 3DES 192-bit key in CBC mode,
'aes128CbcMode(3)' AES 128-bit key in CBC mode,
'aes256CbcMode(4)' AES 256-bit key in CBC mode.
102. PKTC-IETF-SIG-MIB (revision 2007-12-18 00:00)
This MIB module supplies the basic management objects for the
PacketCable and IPCablecom Signaling protocols. This version of the
MIB includes common signaling and Network Call Signaling (NCS)-
related signaling objects. Copyright (C) The IETF Trust (2008).
This version of this MIB module is part of RFC 5098; see the RFC
itself for full legal notices.
Expires August 17, 2014 [Page 196]
Internet-Draft SMIv2 Textual Conventions February 2014
102.1. TenthdBm
This TEXTUAL-CONVENTION represents power levels that are
normally expressed in dBm. Units are in tenths of a dBm;
for example, -13.5 dBm will be represented as -135.
102.2. PktcCodecType
This TEXTUAL-CONVENTION defines various types of codecs
that MAY be supported. The description for each
enumeration is listed below:
Enumeration Description
other a defined codec not in the enumeration
unknown a codec not defined by the PacketCable
Codec Specification
g729 ITU-T Recommendation G.729
reserved for future use
g729E ITU-T Recommendation G.729E
pcmu Pulse Code Modulation u-law (PCMU)
g726at32 ITU-T Recommendation G.726-32 (32 kbit/s)
g728 ITU-T Recommendation G.728
pcma Pulse Code Modulation a-law (PCMA)
g726at16 ITU-T Recommendation G.726-16 (16 kbit/s)
g726at24 ITU-T Recommendation G.726-24 (24 kbit/s)
g726at40 ITU-T Recommendation G.726-40 (40 kbit/s)
ilbc IETF Internet low-bit rate codec
bv16 Broadcom BroadVoice16
The list of codecs is consistent with the IETF
Real-Time Transport Protocol (RTP) Profile registry and
the RTP Map Parameters Table in PacketCable Audio/Video
Codecs Specification [PKT-SP-CODEC]. The literal codec
name for each codec is listed below:
Codec Literal Codec Name
g729 G729
g729E G729E
pcmu PCMU
g726at32 G726-32
g728 G728
pcma PCMA
g726at16 G726-16
Expires August 17, 2014 [Page 197]
Internet-Draft SMIv2 Textual Conventions February 2014
g726at24 G726-24
g726at40 G726-40
ilbc iLBC
bv16 BV16
The literal codec name is the second column of the table
with codec RTP Map Parameters. The Literal Codec Name Column
contains the codec name used in the local connection
options (LCO) of the NCS messages create connection
(CRCX)/modify connection (MDCX) and is also used to
identify the codec in the Call Management System (CMS)
Provisioning Specification. The RTP Map Parameter column of
the Table contains the string used in the media attribute
line (a=) of the session description protocol (SDP)
parameters in NCS messages.
102.3. PktcRingCadence
Expires August 17, 2014 [Page 198]
Internet-Draft SMIv2 Textual Conventions February 2014
This object provides an encoding scheme for ring
cadences, including repeatability characteristics. All
fields in this object MUST be encoded in network-byte
order.
The first three higher-order octets are reserved. The
octets that follow are used to encode a 'bit-string', with
each bit corresponding to 50 milliseconds. A bit value of
'1' indicates the presence of a ring-tone, and a bit value
of '0' indicates the absence of a ring-tone, for that
duration (50 ms) (Note: A minimum number of octets
required to encode the bit-string MUST be used).
The first two of the reserved octets MUST indicate the
length of the encoded cadence (in bits) and MUST range
between 1 and 264. (Note: The length in bits MUST also be
consistent with the number of octets that encode the
cadence). The MTA MUST ignore any unused bits in the last
octet, but MUST reflect the value as provided on
subsequent SNMP GETs.
The third of the reserved octets indicates 'repeatability'
and MUST be either 0x80 or 0x00 -- the former value
indicating 'non-repeatability', and the latter indicating
'repeatability'.
The MTA MUST reject attempts to set a value that violates
any of the above requirements.
102.4. PktcSigType
This object lists the various types of signaling that may
be supported:
other(1) - set when signaling other than NCS is used
ncs(2) - Network Call Signaling is a derivation of MGCP
(Media Gateway Control Protocol) defined for
IPCablecom/PacketCable MTAs.
102.5. DtmfCode
Expires August 17, 2014 [Page 199]
Internet-Draft SMIv2 Textual Conventions February 2014
This TEXTUAL-CONVENTION represents the Dual-Tone
Multi-Frequency (DTMF) Character used
to indicate the start or end of the digit transition
sequence used for caller id or Visual Message Waiting
Indicator (VMWI).
Note: The DTMF code '*' is indicated using 'dtmfcodeStar',
and the DTMF code '#' is indicated using ' dtmfcodeHash'.
102.6. PktcSubscriberSideSigProtocol
This TEXTUAL-CONVENTION represents the Signaling
protocol being used for purposes such as caller id
or VMWI.
A value of fsk(1) indicates Frequency Shift Keying
(FSK).
A value of dtmf(2) indicates Dual-Tone Multi-Frequency
(DTMF).
103. PMIPV6-TC-MIB (revision 2012-05-07 00:00)
This MIB module provides textual conventions for Proxy Mobile IPv6
Management information. Copyright (c) 2012 IETF Trust and the
persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
103.1. Pmip6TimeStamp64
A 64-bit unsigned integer field containing a timestamp.
The value indicates the elapsed time since January 1,
1970, 00:00 UTC, by using a fixed-point format. In this
format, the integer number of seconds is contained in
the first 48 bits of the field, and the remaining 16
bits indicate the number of 1/65536 fractions of a
second.
103.2. Pmip6MnIdentifier
Expires August 17, 2014 [Page 200]
Internet-Draft SMIv2 Textual Conventions February 2014
The identity of a mobile node in the Proxy Mobile IPv6
domain. This is the stable identifier of a mobile node
that the mobility entities in a Proxy Mobile IPv6 domain
can always acquire and use for predictably identifying
a mobile node. Various forms of identifiers can be used
to identify a mobile node (MN). Two examples are a
Network Access Identifier (NAI) and an opaque
identifier applicable to a particular application.
103.3. Pmip6MnLLIdentifier
An identifier that identifies the attached interface of
a mobile node.
103.4. Pmip6MnIndex
A unique integer value, greater than zero, assigned to
each mobile node that is currently attached to the
Proxy Mobile IPv6 domain by the management system.
It is recommended that the values are assigned in a
monotonically increasing order starting from 1. It may
wrap after reaching its maximum value. The value for
each mobile node must remain constant at least from one
re-initialization of the entity's network management
system to the next re-initialization.
103.5. Pmip6MnLLIndex
A unique integer value, greater than zero, assigned to
each interface of a mobile node that is currently
attached to the Proxy Mobile IPv6 domain by the
management system.
It is recommended that the values are assigned in a
monotonically increasing order starting from 1. It may
wrap after reaching its maximum value. The value for
each interface of a mobile node must remain constant at
least from one re-initialization of the entity's network
management system to the next re-initialization.
103.6. Pmip6MnInterfaceATT
Expires August 17, 2014 [Page 201]
Internet-Draft SMIv2 Textual Conventions February 2014
The object specifies the access technology that
connects the mobile node to the access link on the
mobile access gateway.
The enumerated values and the corresponding access
technology are as follows:
reserved (0): Reserved (Not used)
logicalNetworkInterface (1): Logical network interface
pointToPointInterface (2): Point-to-point interface
ethernet (3): Ethernet interface
wirelessLan (4): Wireless LAN interface
wimax (5): Wimax interface
threeGPPGERAN (6): 3GPP GERAN
threeGPPUTRAN (7): 3GPP UTRAN
threeGPPEUTRAN (8): 3GPP E-UTRAN
threeGPP2eHRPD (9): 3GPP2 eHRPD
threeGPP2HRPD (10): 3GPP2 HRPD
threeGPP21xRTT (11): 3GPP2 1xRTT
threeGPP2UMB (12): 3GPP2 UMB
104. POLICY-BASED-MANAGEMENT-MIB (revision 2005-02-07 00:00)
The MIB module for policy-based configuration of SNMP
infrastructures. Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC 4011; see the RFC itself
for full legal notices.
104.1. PmUTF8String
An octet string containing information typically in
human-readable form.
To facilitate internationalization, this
information is represented by using the ISO/IEC
IS 10646-1 character set, encoded as an octet
string using the UTF-8 transformation format
described in RFC 3629.
As 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
0x10FFFF. Byte sequences that do not
correspond to the valid UTF-8 encoding of a
code point or that are outside this range are
prohibited.
Expires August 17, 2014 [Page 202]
Internet-Draft SMIv2 Textual Conventions February 2014
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.
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
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
RFC 3416.
Note that the size of PmUTF8String object is
measured in octets, not characters.
105. Printer-MIB (revision 2004-06-02 00:00)
The MIB module for management of printers. Copyright (C) The
Internet Society (2004). This version of this MIB module was
published in RFC 3805. For full legal notices see the RFC itself.
105.1. PrtMediaUnitTC
Units of measure for media dimensions.
Expires August 17, 2014 [Page 203]
Internet-Draft SMIv2 Textual Conventions February 2014
105.2. MediaUnit (deprecated)
Units of measure for media dimensions.
105.3. PrtCapacityUnitTC
Units of measure for media capacity.
105.4. CapacityUnit (deprecated)
Units of measure for media capacity.
105.5. PrtPrintOrientationTC
A generic representation for printing orientation on a
'page'.
105.6. PrtSubUnitStatusTC
Expires August 17, 2014 [Page 204]
Internet-Draft SMIv2 Textual Conventions February 2014
Status of a printer sub-unit.
The SubUnitStatus is an integer that is the sum of 5 distinct
values, Availability, Non-Critical, Critical, On-line, and
Transitioning. These values are:
Availability Value
Available and Idle 0 0000'b
Available and Standby 2 0010'b
Available and Active 4 0100'b
Available and Busy 6 0110'b
Unavailable and OnRequest 1 0001'b
Unavailable because Broken 3 0011'b
Unknown 5 0101'b
Non-Critical
No Non-Critical Alerts 0 0000'b
Non-Critical Alerts 8 1000'b
Critical
No Critical Alerts 0 0000'b
Critical Alerts 16 1 0000'b
On-Line
State is On-Line 0 0000'b
State is Off-Line 32 10 0000'b
Transitioning
At intended state 0 0000'b
Transitioning to intended state 64 100 0000'b
105.7. SubUnitStatus (deprecated)
Expires August 17, 2014 [Page 205]
Internet-Draft SMIv2 Textual Conventions February 2014
Status of a printer sub-unit.
The SubUnitStatus is an integer that is the sum of 5 distinct
values, Availability, Non-Critical, Critical, On-line, and
Transitioning. These values are:
Availability Value
Available and Idle 0 0000'b
Available and Standby 2 0010'b
Available and Active 4 0100'b
Available and Busy 6 0110'b
Unavailable and OnRequest 1 0001'b
Unavailable because Broken 3 0011'b
Unknown 5 0101'b
Non-Critical
No Non-Critical Alerts 0 0000'b
Non-Critical Alerts 8 1000'b
Critical
No Critical Alerts 0 0000'b
Critical Alerts 16 1 0000'b
On-Line
State is On-Line 0 0000'b
State is Off-Line 32 10 0000'b
Transitioning
At intended state 0 0000'b
Transitioning to intended state 64 100 0000'b
105.8. PresentOnOff
Presence and configuration of a device or feature.
105.9. PrtLocalizedDescriptionStringTC
An object MUST use this TEXTUAL-CONVENTION when its
'charset' is controlled by the value of
prtGeneralCurrentLocalization.
Expires August 17, 2014 [Page 206]
Internet-Draft SMIv2 Textual Conventions February 2014
105.10. PrtConsoleDescriptionStringTC
An object MUST use this TEXTUAL-CONVENTION when its
'charset' is controlled by the value of
prtConsoleLocalization.
105.11. CodedCharSet (deprecated)
The original description clause from RFC 1759 [RFC1759] was
technically inaccurate and therefore has been deleted.
105.12. PrtChannelStateTC
The state of this print job delivery channel. The value
determines whether print data is allowed through this channel.
105.13. PrtOutputStackingOrderTC
The current state of the stacking order for the associated
output sub-unit. 'firstToLast' means that as pages are output,
the front of the next page is placed against the back of the
previous page. 'lastToFirst' means that as pages are output,
the back of the next page is placed against the front of the
previous page.
105.14. PrtOutputPageDeliveryOrientationTC
The reading surface that will be 'up' when pages are delivered
to the associated output sub-unit. Values are Face-Up and Face
Down (Note: interpretation of these values is, in general,
context-dependent based on locale; presentation of these values
to an end-user should be normalized to the expectations of the
user.
105.15. PrtMarkerCounterUnitTC
The unit that will be used by the printer when reporting
counter values for this marking sub-unit. The
time units of measure are provided for a device like a
strip recorder that does not or cannot track the physical
dimensions of the media and does not use characters,
lines or sheets.
Expires August 17, 2014 [Page 207]
Internet-Draft SMIv2 Textual Conventions February 2014
105.16. PrtMarkerSuppliesSupplyUnitTC
Unit of this marker supply container/receptacle.
105.17. PrtMarkerSuppliesClassTC
Indicates whether this supply entity represents a supply
that is consumed or a receptacle that is filled.
105.18. PrtMarkerColorantRoleTC
The role played by this colorant.
105.19. PrtMarkerAddressabilityUnitTC
The unit of measure of distances, as applied to the marker's
resolution.
105.20. PrtMediaPathMaxSpeedPrintUnitTC
The unit of measure used in specifying the speed of all
media paths in the printer.
105.21. PrtInterpreterTwoWayTC
Indicates whether or not this interpreter returns information
back to the host.
105.22. PrtAlertSeverityLevelTC
The level of severity of this alert table entry. The printer
determines the severity level assigned to each entry in the
table. A critical alert is binary by nature and definition. A
warning is defined to be a non-critical alert. The original and
most common warning is unary. The binary warning was added later
and given a more distinguished name.
106. PTOPO-MIB (revision 2000-09-21 00:00)
The MIB module for physical topology information.
Expires August 17, 2014 [Page 208]
Internet-Draft SMIv2 Textual Conventions February 2014
106.1. PtopoGenAddr
The value of an address.
106.2. PtopoChassisIdType
This TC describes the source of a chassis identifier.
The enumeration 'chasIdEntPhysicalAlias(1)' represents a
chassis identifier based on the value of entPhysicalAlias
for a chassis component (i.e., an entPhysicalClass value of
'chassis(3)').
The enumeration 'chasIdIfAlias(2)' represents a chassis
identifier based on the value of ifAlias for an interface
on the containing chassis.
The enumeration 'chasIdPortEntPhysicalAlias(3)' represents
a chassis identifier based on the value of entPhysicalAlias
for a port or backplane component (i.e., entPhysicalClass
value of 'port(10)' or 'backplane(4)'), within the
containing chassis.
The enumeration 'chasIdMacAddress(4)' represents a chassis
identifier based on the value of a unicast source MAC
address (encoded in network byte order and IEEE 802.3
canonical bit order), of a port on the containing chassis.
The enumeration 'chasIdPtopoGenAddr(5)' represents a
chassis identifier based on a network address, associated
with a particular chassis. The encoded address is actually
composed of two fields. The first field is a single octet,
representing the IANA AddressFamilyNumbers value for the
specific address type, and the second field is the
PtopoGenAddr address value.
106.3. PtopoChassisId
Expires August 17, 2014 [Page 209]
Internet-Draft SMIv2 Textual Conventions February 2014
This TC describes the format of a chassis identifier
string. Objects of this type are always used with an
associated PtopoChassisIdType object, which identifies the
format of the particular PtopoChassisId object instance.
If the associated PtopoChassisIdType object has a value of
'chasIdEntPhysicalAlias(1)', then the octet string
identifies a particular instance of the entPhysicalAlias
object for a chassis component (i.e., an entPhysicalClass
value of 'chassis(3)').
If the associated PtopoChassisIdType object has a value of
'chasIdIfAlias(2)', then the octet string identifies a
particular instance of the ifAlias object for an interface
on the containing chassis.
If the associated PtopoChassisIdType object has a value of
'chasIdPortEntPhysicalAlias(3)', then the octet string
identifies a particular instance of the entPhysicalAlias
object for a port or backplane component within the
containing chassis.
If the associated PtopoChassisIdType object has a value of
'chasIdMacAddress(4)', then this string identifies a
particular unicast source MAC address (encoded in network
byte order and IEEE 802.3 canonical bit order), of a port on
the containing chassis.
If the associated PtopoChassisIdType object has a value of
'chasIdPtopoGenAddr(5)', then this string identifies a
particular network address, encoded in network byte order,
associated with one or more ports on the containing chassis.
The first octet contains the IANA Address Family Numbers
enumeration value for the specific address type, and octets
2 through N contain the PtopoGenAddr address value in
network byte order.
106.4. PtopoPortIdType
Expires August 17, 2014 [Page 210]
Internet-Draft SMIv2 Textual Conventions February 2014
This TC describes the source of a particular type of port
identifier used in the PTOPO MIB.
The enumeration 'portIdIfAlias(1)' represents a port
identifier based on the ifAlias MIB object.
The enumeration 'portIdPortEntPhysicalAlias(2)' represents a
port identifier based on the value of entPhysicalAlias for a
port or backplane component (i.e., entPhysicalClass value of
'port(10)' or 'backplane(4)'), within the containing
chassis.
The enumeration 'portIdMacAddr(3)' represents a port
identifier based on a unicast source MAC address, which has
been detected by the agent and associated with a particular
port.
The enumeration 'portIdPtopoGenAddr(4)' represents a port
identifier based on a network address, detected by the agent
and associated with a particular port.
106.5. PtopoPortId
Expires August 17, 2014 [Page 211]
Internet-Draft SMIv2 Textual Conventions February 2014
This TC describes the format of a port identifier string.
Objects of this type are always used with an associated
PtopoPortIdType object, which identifies the format of the
particular PtopoPortId object instance.
If the associated PtopoPortIdType object has a value of
'portIdIfAlias(1)', then the octet string identifies a
particular instance of the ifAlias object.
If the associated PtopoPortIdType object has a value of
'portIdEntPhysicalAlias(2)', then the octet string
identifies a particular instance of the entPhysicalAlias
object for a port component (i.e., entPhysicalClass value of
'port(10)').
If the associated PtopoPortIdType object has a value of
'portIdMacAddr(3)', then this string identifies a particular
unicast source MAC address associated with the port.
If the associated PtopoPortIdType object has a value of
'portIdPtopoGenAddr(4)', then this string identifies a
network address associated with the port. The first octet
contains the IANA AddressFamilyNumbers enumeration value for
the specific address type, and octets 2 through N contain
the PtopoGenAddr address value in network byte order.
106.6. PtopoAddrSeenState
Expires August 17, 2014 [Page 212]
Internet-Draft SMIv2 Textual Conventions February 2014
This TC describes the state of address detection for a
particular type of port identifier used in the PTOPO MIB.
The enumeration 'notUsed(1)' represents an entry for which
the particular MIB object is not applicable to the remote
connection endpoint,
The enumeration 'unknown(2)' represents an entry for which
the particular address collection state is not known.
The enumeration 'oneAddr(3)' represents an entry for which
exactly one source address (of the type indicated by the
particular MIB object), has been detected.
The enumeration 'multiAddr(4)' represents an entry for
which more than one source address (of the type indicated by
the particular MIB object), has been detected.
An agent is expected to set the initial state of the
PtopoAddrSeenState to 'notUsed(1)' or 'unknown(2)'.
Note that the PTOPO MIB does not restrict or specify the
means in which the PtopoAddrSeenState is known to an agent.
In particular, an agent may detect this information through
configuration data, or some means other than directly
monitoring all port traffic.
107. PW-CEP-STD-MIB (revision 2011-05-16 00:00)
This MIB module contains managed object definitions for Circuit
Emulation over Packet (CEP) as in [RFC4842]: Malis, A., Prayson, P.,
Cohen, R., and D. Zelig. 'Synchronous Optical Network/Synchronous
Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)',
RFC 4842. Copyright (c) 2011 IETF Trust and the persons identified
as authors of the code. All rights reserved. Redistribution and use
in source and binary forms, with or without modification, is
permitted pursuant to, and subject to the license terms contained in,
the Simplified BSD License set forth in Section 4.c of the IETF
Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
107.1. PwCepSonetEbm
Equipped Bit Mask (EBM) used for fractional STS-1/Virtual
Circuit 3 (VC-3). The EBM bits are the 28 least
significant bits out of the 32-bit value.
Expires August 17, 2014 [Page 213]
Internet-Draft SMIv2 Textual Conventions February 2014
107.2. PwCepSdhVc4Ebm
Equipped Bit Mask (EBM) used for each Tributary Unit Group
3 (TUG-3) in fractional VC-4 circuits. The EBM bits are
the 30 least significant bits out of the 32-bit value.
107.3. PwCepSonetVtgMap
The VT/VC types carried in the 7 VT groups (VTGs)/TUG-2s.
The format is 28 bits in the form of an Equipped Bit Mask
(EBM) for fractional STS-1/VC-3. The mapping specifies the
maximal occupancies of VT/VC within each VTG/TUG-2. For
example, all four bits are set to 1 in this object to
represent a VTG carrying VT1.5/VC11s, while only three
are set when VT2/VC12s are carried within this VTG.
The relevant bits are the 28 least significant bits out of
the 32-bit value.
107.4. PwCepFracAsyncMap
The type of asynchronous mapping carried inside STS-1,
VC-3, or TUG-3 containing TU-3 circuit.
108. PW-TC-STD-MIB (revision 2009-04-21 00:00)
This MIB module defines TEXTUAL-CONVENTIONS for concepts used in
pseudowire edge-to-edge networks. Copyright (c) 2009 IETF Trust and
the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met: - Redistributions of source code must retain the above
copyright notice, this list of conditions and the following
disclaimer. - Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with
the distribution. - Neither the name of Internet Society, IETF or
IETF Trust, nor the names of specific contributors, may be used to
endorse or promote products derived from this software without
specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE
COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
Expires August 17, 2014 [Page 214]
Internet-Draft SMIv2 Textual Conventions February 2014
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of
this MIB module is part of RFC 5542; see the RFC itself for full
legal notices.
108.1. PwGroupID
An administrative identification for grouping a
set of service-specific pseudowire services.
108.2. PwIDType
Pseudowire Identifier. Used to identify the PW
(together with some other fields) in the signaling
session.
108.3. PwIndexType
Pseudowire Index. A unique value, greater than zero,
for each locally defined PW. Used for indexing
several MIB tables associated with the particular PW.
It is recommended that values are assigned contiguously
starting from 1. The value for each PW MUST remain
constant at least from one re-initialization
to the next re-initialization.
108.4. PwIndexOrZeroType
This TEXTUAL-CONVENTION is an extension of the
PwIndexType convention. The latter defines a greater-
than-zero value used to identify a pseudowire
in the managed system. This extension permits the
additional value of zero. The zero value is object-specific
and MUST therefore be defined as part of the description of
any object that uses this syntax. Examples of the usage of
zero might include situations where pseudowire was unknown,
or where none or all pseudowires need to be referenced.
Expires August 17, 2014 [Page 215]
Internet-Draft SMIv2 Textual Conventions February 2014
108.5. PwOperStatusTC
Indicates the operational status of the PW.
- up(1): Ready to pass packets.
- down(2): PW signaling is not yet finished, or
indications available at the service
level indicate that the PW is not
passing packets.
- testing(3): AdminStatus at the PW level is set to
test.
- dormant(4): The PW is not in a condition to pass
packets but is in a 'pending' state,
waiting for some external event.
- notPresent(5): Some component is missing to accomplish
the setup of the PW. It can be
configuration error, incomplete
configuration, or a missing H/W component.
- lowerLayerDown(6): One or more of the lower-layer interfaces
responsible for running the underlying PSN
is not in OperStatus 'up' state.
108.6. PwAttachmentIdentifierType
An octet string used in the generalized Forward Error
Correction (FEC) element for identifying attachment forwarder
and groups. A NULL identifier is of zero length.
108.7. PwGenIdType
Represents the Attachment Group Identifier (AGI) Type and
Attachment Individual Identifier (AII) Type in generalized FEC
signaling and configuration.
108.8. PwCwStatusTC
Expires August 17, 2014 [Page 216]
Internet-Draft SMIv2 Textual Conventions February 2014
Indicates the status of the control word (CW) negotiation
based on the local configuration and the indications received
from the peer node.
waitingForNextMsg(1) indicates that the node is waiting for
another label mapping from the peer.
sentWrongBitErrorCode(2) indicates that the local node has
notified the peer about a mismatch in the C-bit.
rxWithdrawWithWrongBitErrorCode(3) indicates that a withdraw
message has been received with the wrong C-bit error code.
illegalReceivedBit(4) indicates a C-bit configuration with
the peer that is not compatible with the PW type.
cwPresent(5) indicates that the CW is present for this PW.
If signaling is used, the C-bit is set and agreed upon between
the nodes. For manually configured PW, the local
configuration requires the use of the CW.
cwNotPresent(6) indicates that the CW is not present for this
PW. If signaling is used, the C-bit is reset and agreed upon
between the nodes. For manually configured PW, the local
configuration requires that the CW not be used.
notYetKnown(7) indicates that a label mapping has not yet
been received from the peer.
108.9. PwStatus
Indicates the status of the PW and the interfaces affecting
this PW. If none of the bits are set, it indicates no faults
are reported.
108.10. PwFragSize
If set to a value other than zero, it indicates the desired
fragmentation length in bytes. If set to zero,
fragmentation is not desired for PSN bound packets.
Expires August 17, 2014 [Page 217]
Internet-Draft SMIv2 Textual Conventions February 2014
108.11. PwFragStatus
Indicates the status of the fragmentation/reassembly process
based on local configuration and peer capability.
noFrag(0) bit indicates that local configuration is for no
fragmentation.
cfgFragGreaterThanPsnMtu(1) bit indicates that the local node
is set to fragment, but the fragmentation size is greater
than the MTU available at the PSN between the nodes.
Fragmentation is not done in this case.
cfgFragButRemoteIncapable(2) bit indicates that the local
configuration conveys the desire for fragmentation but
the peer is not capable of reassembly.
remoteFragCapable(3) bit indicates that the remote node
is capable to accept fragmented PDUs.
fragEnabled(4) bit indicates that fragmentation will be used
on this PW. Fragmentation can be used if the local node was
configured for fragmentation, the peer has the capability
to accept fragmented packets, and the CW is in use for this
PW.
108.12. PwCfgIndexOrzero
Index in any of the relevant configuration tables for
supplement information regarding configuration of the
specific technology. Value zero implies no additional
configuration information is applicable.
109. PW-TDM-MIB (revision 2009-06-15 00:00)
This MIB contains managed object definitions for encapsulating TDM
(T1,E1, T3, E3, NxDS0) as pseudo-wires over packet-switching networks
(PSN). This MIB supplements the PW-STD-MIB as in: Zelig, D., Nadeau,
T. 'Pseudowire (PW) Management Information Base'. The PW-STD-MIB
contains structures and MIB associations generic to pseudowire (PW)
emulation. PW-specific MIBs (such as this) contain config and stats
for specific PW types. Copyright (c) 2009 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
Expires August 17, 2014 [Page 218]
Internet-Draft SMIv2 Textual Conventions February 2014
are met: - Redistributions of source code must retain the above
copyright notice, this list of conditions and the following
disclaimer. - Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with
the distribution. - Neither the name of Internet Society, IETF or
IETF Trust, nor the names of specific contributors, may be used to
endorse or promote products derived from this software without
specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE
COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of
this MIB module is part of RFC 5604; see the RFC itself for full
legal notices.
109.1. PwTDMCfgIndex
Index into the relevant pwXXXCfgTable.
110. Q-BRIDGE-MIB (revision 2006-01-09 00:00)
The VLAN Bridge MIB module for managing Virtual Bridged Local Area
Networks, as defined by IEEE 802.1Q-2003, including Restricted Vlan
Registration defined by IEEE 802.1u-2001 and Vlan Classification
defined by IEEE 802.1v-2001. Copyright (C) The Internet Society
(2006). This version of this MIB module is part of RFC 4363; See the
RFC itself for full legal notices.
110.1. PortList
Expires August 17, 2014 [Page 219]
Internet-Draft SMIv2 Textual Conventions February 2014
Each octet within this value specifies a set of eight
ports, with the first octet specifying ports 1 through
8, the second octet specifying ports 9 through 16, etc.
Within each octet, the most significant bit represents
the lowest numbered port, and the least significant bit
represents the highest numbered port. Thus, each port
of the bridge is represented by a single bit within the
value of this object. If that bit has a value of '1',
then that port is included in the set of ports; the port
is not included if its bit has a value of '0'.
110.2. VlanIndex
A value used to index per-VLAN tables: values of 0 and
4095 are not permitted. If the value is between 1 and
4094 inclusive, it represents an IEEE 802.1Q VLAN-ID with
global scope within a given bridged domain (see VlanId
textual convention). If the value is greater than 4095,
then it represents a VLAN with scope local to the
particular agent, i.e., one without a global VLAN-ID
assigned to it. Such VLANs are outside the scope of
IEEE 802.1Q, but it is convenient to be able to manage them
in the same way using this MIB.
110.3. VlanId
The VLAN-ID that uniquely identifies a VLAN. This
is the 12-bit VLAN-ID used in the VLAN Tag header.
The range is defined by the REFERENCEd specification.
110.4. VlanIdOrAny
The VLAN-ID that uniquely identifies a specific VLAN,
or any VLAN. The special value of 4095 is used to
indicate a wildcard, i.e., any VLAN. This can be used
in any situation where an object or table entry must
refer either to a specific VLAN or to any VLAN.
Note that a MIB object that is defined using this
TEXTUAL-CONVENTION should clarify the meaning of
'any VLAN' (i.e., the special value 4095).
Expires August 17, 2014 [Page 220]
Internet-Draft SMIv2 Textual Conventions February 2014
110.5. VlanIdOrNone
The VLAN-ID that uniquely identifies a specific VLAN,
or no VLAN. The special value of zero is used to
indicate that no VLAN-ID is present or used. This can
be used in any situation where an object or a table entry
must refer either to a specific VLAN, or to no VLAN.
Note that a MIB object that is defined using this
TEXTUAL-CONVENTION should clarify the meaning of
'no VLAN' (i.e., the special value 0).
110.6. VlanIdOrAnyOrNone
The VLAN-ID that uniquely identifies a specific VLAN,
any VLAN, or no VLAN. The special values 0 and 4095
have the same meaning as described in the VlanIdOrAny
and VlanIdOrNone TEXTUAL-CONVENTIONs.
Note that a MIB object that is defined using this
TEXTUAL-CONVENTION should clarify the meaning of
'any VLAN' and 'no VLAN' (i.e., the special values
0 and 4095).
111. RBRIDGE-MIB (revision 2013-01-07 00:00)
The RBridge MIB module for managing switches that support the TRILL
protocol.
111.1. RbridgeAddress
The Media Access Control (MAC) address used by an RBridge
port. This may match the RBridge IS-IS SystemID.
111.2. RbridgeNickname
The 16-bit identifier used in TRILL as an
abbreviation for the RBridge's 48-bit IS-IS System ID.
The value 0 means a nickname is not specified, the values
0xFFC0 through 0xFFFE are reserved for future allocation,
and the value 0xFFFF is permanently reserved.
Expires August 17, 2014 [Page 221]
Internet-Draft SMIv2 Textual Conventions February 2014
112. RIPv2-MIB (revision 1994-07-27 22:53)
The MIB module to describe the RIP2 Version 2 Protocol
112.1. RouteTag
the RouteTag type represents the contents of the Route Domain
field in the packet header or route entry
113. RMON2-MIB (revision 2006-05-02 00:00)
The MIB module for managing remote monitoring device implementations.
This MIB module extends the architecture introduced in the original
RMON MIB as specified in RFC 2819. Copyright (C) The Internet
Society (2006). This version of this MIB module is part of RFC 4502;
see the RFC itself for full legal notices.
113.1. ZeroBasedCounter32
This TC describes an object that counts events with the
following semantics: objects of this type will be set to
zero(0) on creation and will thereafter count appropriate
events, wrapping back to zero(0) when the value 2^32 is
reached.
Provided that an application discovers the new object within
the minimum time to wrap, it can use the initial value as a
delta since it last polled the table of which this object is
part. It is important for a management station to be aware of
this minimum time and the actual time between polls, and to
discard data if the actual time is too long or there is no
defined minimum time.
Typically, this TC is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in use.
113.2. LastCreateTime
Expires August 17, 2014 [Page 222]
Internet-Draft SMIv2 Textual Conventions February 2014
This TC describes an object that stores the value of the
sysUpTime object at the last time its entry was created.
This can be used for polling applications to determine that an
entry has been deleted and re-created between polls, causing
an otherwise undetectable discontinuity in the data.
If sysUpTime is reset to zero as a result of a re-
initialization of the network management (sub)system, then
the values of all LastCreateTime objects are also reset.
However, after approximately 497 days without a re-
initialization, the sysUpTime object will reach 2^^32-1 and
then increment to zero; in this case, existing values
of TimeStamp objects do not change. This can lead to
ambiguities in the value of TimeStamp objects.
113.3. TimeFilter
To be used for the index to a table. Allows an application
to download only those rows changed since a particular time.
Note that this is not a history mechanism. Only current values
of underlying objects are returned; saved instance values
associated with particular values of sysUpTime are not.
An entry is considered changed if the value of any object in the
entry changes, if the row is created, or if any object in the
entry is created or deleted. Note that deleted entries cannot
be detected or downloaded.
A time-filtered conceptual table is created by inserting a
single object of SYNTAX TimeFilter as the first INDEX component
in a copy of an existing basic conceptual table (i.e., any
SEQUENCE without a TimeFilter INDEX component). Thus, for
each conceptual entry 'I' in the basic table, there exists N
conceptual entries in the time-filtered version, indexed N.I,
where 'N' is equal to the value of sysUpTime.
When an application retrieves conceptual instances from a
time-filtered table, and an INDEX value is provided for the
TimeFilter INDEX component 'N', the agent will only consider
returning basic conceptual entries (e.g., 'fooColumn.N.I') if
any column within the basic conceptual entry has changed since
sysUpTime 'N'. If not, the basic conceptual entry will
be ignored for the particular retrieval operation.
Expires August 17, 2014 [Page 223]
Internet-Draft SMIv2 Textual Conventions February 2014
When sysUpTime is equal to zero, this table shall be empty.
One conceptual entry exists for each past value of sysUpTime,
except that the whole table is purged should sysUpTime wrap.
As an entry in a time-filtered table is updated (i.e., one of
the columns in the basic conceptual table is changed), new
conceptual entries are also created in the time-filtered version
(which still shares the now updated object values with all other
instances). The number of unique time-filtered instances that
are created is determined by the value of sysUpTime at which the
basic entry was last updated. One unique instance will exist
for each value of sysUpTime at the last update time for the row.
However, a new TimeFilter index instance is created for each new
sysUpTime value. The TimeFilter index values not associated
with entry updates are called duplicate time-filtered instances.
After some deployment experience, it has been determined that
a time-filtered table is more efficient if the agent
stops a MIB walk operation by skipping over rows with a
TimeFilter index value higher than the value in the received
GetNext/GetBulk request. That is, instead of incrementing a
TimeFilter index value, the agent will continue to the next
object or table. As a consequence, GetNext or GetBulk
operations will provide only one pass through a time-filtered
table.
It is suggested that an agent implement a time-filtered table
in this manner to improve performance and avoid a MIB walk
getting stuck in time-filtered tables. It is, however, still
acceptable for an agent to implement a time-filtered table in
the traditional manner (i.e., every conceptual time-filtered
instance is returned in GetNext and GetBulk PDU responses), and
management applications must be able to deal with such
traditional implementations.
See the appendix for further discussion of this textual
convention.
The following example is provided to demonstrate TimeFilter
behavior:
Consider the following basic conceptual table, basicFooTable.
(Note that the basic version of a time-filtered table may not
actually be defined.)
Expires August 17, 2014 [Page 224]
Internet-Draft SMIv2 Textual Conventions February 2014
basicFooTable:
basicFooTable ...
INDEX { fooIndex }
BasicFooEntry {
fooIndex Integer32,
fooCounts Counter32
}
For this example, the basicFooTable contains two static
conceptual entries (fooIndex equals '1' and '2'), created at
time zero. It also contains one dynamic conceptual entry
(fooIndex equals '3'), which is created at time '3' and deleted
at time '7'.
The time-filtered version of the basicFooTable could be defined
as follows:
FooTable:
fooTable ...
INDEX { fooTimeMark, fooIndex }
FooEntry {
fooTimeMark TimeFilter,
fooIndex Integer32,
fooCounts Counter32
}
Note that entries exist in the time-filtered conceptual table
only if they actually exist in the underlying (basic) table.
For this example, the fooTable will have three underlying
basic entries (fooIndex == 1, 2, and 3), with the following
activity (for sysUpTime equal 0 to 9):
- fooEntry.N.1 is created at time '0' and most recently
updated at time '6' to the value '5'.
- fooEntry.N.2 is created at time '0' and most recently
updated at time '8' to the value '9'.
- fooEntry.N.3 is created at time '3', updated at time '5'
to the value '17', and deleted at time '7'.
Expires August 17, 2014 [Page 225]
Internet-Draft SMIv2 Textual Conventions February 2014
The following tables show the values that would be returned for
MIB walk operations with various TimeFilter values, done at
different times. An application issues a retrieval request at
time 'T', with a TimeFilter value, 'N' (typically set to a lower
value, such as the value of sysUpTime at the last polling cycle).
The following values would be returned in a MIB walk of
fooCounts.N if T equals '0' and N equals '0':
fooCounts.N.I Value
==========================
fooCounts.0.1 0
fooCounts.0.2 0
Note that nothing is returned for fooCounts.0.3, since that
entry does not exist at sysUpTime equals '0'.
The following values would be returned in a full (traditional) MIB
walk of fooCounts.N if T equals '3' and N equals '0':
fooCounts.N.I Value
=======================
fooCounts.0.1 0
fooCounts.0.2 0
fooCounts.0.3 0
fooCounts.1.3 0
fooCounts.2.3 0
fooCounts.3.3 0
Note that there are no instances for T equals 1 or 2 for the
first two values of N, as these entries did not change
since they were created at time '0'.
Note that the current value for 'fooCounts.N.3' is returned
here, even for values of N less than '3' (when the entry was
created). The agent only considers the current existence of an
entry in the TimeFilter algorithm, not the time when the entry
was created.
Note that the instances 'fooCounts.0.3', 'fooCounts.1.3',
and 'fooCounts.2.3' are duplicates and can be suppressed by the
agent in a MIB walk.
The following values would be returned in a full (traditional)
MIB walk of fooCounts.N if T equals '6' and N equals '3':
Expires August 17, 2014 [Page 226]
Internet-Draft SMIv2 Textual Conventions February 2014
fooCounts.N.I Value
=======================
fooCounts.3.1 5
fooCounts.3.3 17
fooCounts.4.1 5
fooCounts.4.3 17
fooCounts.5.1 5
fooCounts.5.3 17
fooCounts.6.1 5
Note that no instances for entry 'fooCounts.N.2' are returned,
since it has not changed since time '3'.
Note that all instances except 'fooCounts.5.3' and
'fooCounts.6.1' are duplicates and can be suppressed by the
agent in a MIB walk.
The following values would be returned in a full (traditional)
MIB walk of fooCounts.N if T equals '9' and N equals '6':
fooCounts.N.I Value
=======================
fooCounts.6.1 5
fooCounts.6.2 9
fooCounts.7.2 9
fooCounts.8.2 9
Note that no instances for entry 'fooCounts.N.3' are returned,
since it was deleted at time '7'.
Note that instances 'fooCounts.6.2' and 'fooCounts.7.2'
are duplicates and can be suppressed by the agent in a MIB
walk.
113.4. DataSource
Expires August 17, 2014 [Page 227]
Internet-Draft SMIv2 Textual Conventions February 2014
Identifies the source of the data that the associated
function is configured to analyze. This source can be any
interface on this device.
In order to identify a particular interface, this
object shall identify the instance of the ifIndex
object, defined in [RFC2863], for the desired interface.
For example, if an entry were to receive data from
interface #1, this object would be set to ifIndex.1.
113.5. ControlString
This data type is used to communicate with a modem or a
serial data switch. A ControlString contains embedded
commands to control how the device will interact with the
remote device through the serial interface. Commands are
represented as two-character sequences beginning with
the '^' character.
The following commands are recognized by the device (note
that command characters are case sensitive):
^s Send string that follows, which is terminated by the
next command or the end of string.
^c Delay for the number of seconds that follows. Toss
out any data received rather than store it in a
buffer for parsing.
^t Set timeout to the value represented by the decimal
digits that follow. The default timeout is 20
seconds. Note that this timeout may be overridden
by a smaller serialTimeout configured for the
associated serial interface (see serialConfigTable).
^w Wait for the reply string that follows, which is
terminated by the next command or the end of string.
Partial and case-insensitive matching is applied, i.e.,
if the reply string (any case combination) is found
anywhere in the received string, then the a match is
found. If the current timeout elapses without a match,
then the remaining control string is ignored.
^! The ^ character.
^d Delay the number of seconds specified by the decimal
digits that follow.
^b Send break for the number of milliseconds specified by
Expires August 17, 2014 [Page 228]
Internet-Draft SMIv2 Textual Conventions February 2014
the decimal digits that follow. If no digits follow,
break will be enforced for 250 milliseconds by default.
The following ASCII control characters may be inserted into
the '^s' send string or the '^w' reply string:
^@ 0x00
^A 0x01
..
^M 0x0D
..
^Z 0x1A
^[ 0x1B
^ 0x1C
^] 0x1D
^^ 0x1E
^_ 0x1F
Binary data may also be inserted into the data stream. The
control sequence for each byte of binary data is ^0x##, where
## is the hexadecimal representation of the data byte. Two
ASCII characters (0-9, a-f, A-F) must follow the '^0x'
control prefix. For example, '^0x0D^0x0A' is interpreted as a
carriage return followed by a line feed.
114. RMON-MIB (revision 2000-05-11 00:00)
Remote network monitoring devices, often called monitors or probes,
are instruments that exist for the purpose of managing a network.
This MIB defines objects for managing remote network monitoring
devices.
114.1. OwnerString
Expires August 17, 2014 [Page 229]
Internet-Draft SMIv2 Textual Conventions February 2014
This data type is used to model an administratively
assigned name of the owner of a resource. Implementations
must accept values composed of well-formed NVT ASCII
sequences. In addition, implementations should accept
values composed of well-formed UTF-8 sequences.
It is suggested that this name contain one or more of
the following: IP address, management station name,
network manager's name, location, or phone number.
In some cases the agent itself will be the owner of
an entry. In these cases, this string shall be set
to a string starting with 'monitor'.
SNMP access control is articulated entirely in terms
of the contents of MIB views; access to a particular
SNMP object instance depends only upon its presence
or absence in a particular MIB view and never upon
its value or the value of related object instances.
Thus, objects of this type afford resolution of
resource contention only among cooperating
managers; they realize no access control function
with respect to uncooperative parties.
114.2. EntryStatus
The status of a table entry.
Setting this object to the value invalid(4) has the
effect of invalidating the corresponding entry.
That is, it effectively disassociates the mapping
identified with said entry.
It is an implementation-specific matter as to whether
the agent removes an invalidated entry from the table.
Accordingly, management stations must be prepared to
receive tabular information from agents that corresponds
to entries currently not in use. Proper
interpretation of such entries requires examination
of the relevant EntryStatus object.
An existing instance of this object cannot be set to
createRequest(2). This object may only be set to
createRequest(2) when this instance is created. When
this object is created, the agent may wish to create
supplemental object instances with default values
to complete a conceptual row in this table. Because the
creation of these default objects is entirely at the option
of the agent, the manager must not assume that any will be
Expires August 17, 2014 [Page 230]
Internet-Draft SMIv2 Textual Conventions February 2014
created, but may make use of any that are created.
Immediately after completing the create operation, the agent
must set this object to underCreation(3).
When in the underCreation(3) state, an entry is allowed to
exist in a possibly incomplete, possibly inconsistent state,
usually to allow it to be modified in multiple PDUs. When in
this state, an entry is not fully active.
Entries shall exist in the underCreation(3) state until
the management station is finished configuring the entry
and sets this object to valid(1) or aborts, setting this
object to invalid(4). If the agent determines that an
entry has been in the underCreation(3) state for an
abnormally long time, it may decide that the management
station has crashed. If the agent makes this decision,
it may set this object to invalid(4) to reclaim the
entry. A prudent agent will understand that the
management station may need to wait for human input
and will allow for that possibility in its
determination of this abnormally long period.
An entry in the valid(1) state is fully configured and
consistent and fully represents the configuration or
operation such a row is intended to represent. For
example, it could be a statistical function that is
configured and active, or a filter that is available
in the list of filters processed by the packet capture
process.
A manager is restricted to changing the state of an entry in
the following ways:
To: valid createRequest underCreation invalid
From:
valid OK NO OK OK
createRequest N/A N/A N/A N/A
underCreation OK NO OK OK
invalid NO NO NO OK
nonExistent NO OK NO OK
In the table above, it is not applicable to move the state
from the createRequest state to any other state because the
manager will never find the variable in that state. The
nonExistent state is not a value of the enumeration, rather
it means that the entryStatus variable does not exist at all.
An agent may allow an entryStatus variable to change state in
additional ways, so long as the semantics of the states are
followed. This allowance is made to ease the implementation of
Expires August 17, 2014 [Page 231]
Internet-Draft SMIv2 Textual Conventions February 2014
the agent and is made despite the fact that managers should
never exercise these additional state transitions.
115. ROHC-MIB (revision 2004-06-03 00:00)
This MIB module defines a set of basic objects for monitoring and
configuring robust header compression. The module covers information
about running instances of ROHC (compressors or decompressors) at IP
interfaces. Information about compressor contexts and decompressor
contexts has different structure for different profiles. Therefore
it is not provided by this MIB module, but by individual modules for
different profiles. Copyright (C) The Internet Society (2004). The
initial version of this MIB module was published in RFC 3816. For
full legal notices see the RFC itself or see:
http://www.ietf.org/copyrights/ianamib.html
115.1. RohcChannelIdentifier
A number identifying a channel.
The value of 0 must not be used as identifier
of an existing channel.
115.2. RohcChannelIdentifierOrZero
A number identifying a channel.
The value of 0 is indicates that
no channel is identified.
115.3. RohcCompressionRatio
A number indicating a compression ratio over
a set of bytes. The value is defined as
1000 * bytes(compressed) / bytes(original)
rounded to the next integer value.
Note that compressed sets of bytes can be larger
than the corresponding uncompressed ones.
Therefore, the number can be greater than 1000.
Expires August 17, 2014 [Page 232]
Internet-Draft SMIv2 Textual Conventions February 2014
116. RPKI-ROUTER-MIB (revision 2013-05-01 00:00)
This MIB module contains management objects to support monitoring of
the Resource Public Key Infrastructure (RPKI) protocol on routers.
Copyright (c) 2013 IETF Trust and the persons identified as authors
of the code. All rights reserved. Redistribution and use in source
and binary forms, with or without modification, is permitted pursuant
to, and subject to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC 6945; see the RFC
itself for full legal notices.
116.1. RpkiRtrConnectionType
The connection type used between a router (as a
client) and a cache server.
The following types have been defined in RFC 6810:
ssh(1) - Section 7.1; see also RFC 4252.
tls(2) - Section 7.2; see also RFC 5246.
tcpMD5(3) - Section 7.3; see also RFC 2385.
tcpAO(4) - Section 7.4; see also RFC 5925.
tcp(5) - Section 7.
ipsec(6) - Section 7; see also RFC 4301.
other(7) - none of the above.
117. RSERPOOL-MIB (revision 2009-04-07 00:00)
The MIB module for managing an RSerPool implementation. Copyright
(c) 2009 IETF Trust and the persons identified as authors of the
code. All rights reserved. Redistribution and use in source and
binary forms, with or without modification, are permitted provided
that the following conditions are met: - Redistributions of source
code must retain the above copyright notice, this list of conditions
and the following disclaimer. - Redistributions in binary form must
reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials
provided with the distribution. - Neither the name of Internet
Society, IETF or IETF Trust, nor the names of specific contributors,
may be used to endorse or promote products derived from this software
without specific prior written permission. THIS SOFTWARE IS PROVIDED
BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR
Expires August 17, 2014 [Page 233]
Internet-Draft SMIv2 Textual Conventions February 2014
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This version of this MIB module is part of RFC 5525; see the RFC
itself for full legal notices.
117.1. RSerPoolENRPServerIdentifierTC
The ID of an ENRP server
117.2. RSerPoolOperationScopeTC
The ID of an operation scope
117.3. RSerPoolPoolHandleTC
The pool handle
117.4. RserpoolPoolElementIdentifierTC
The pool element ID
117.5. RSerPoolPolicyIdentifierTC
The ID of the pool policy
117.6. RSerPoolPolicyLoadTC
The load status of a pool element
117.7. RSerPoolPolicyWeightTC
The weight of a pool element
Expires August 17, 2014 [Page 234]
Internet-Draft SMIv2 Textual Conventions February 2014
117.8. RSerPoolTransportUseTypeTC
The transport use of a pool element
117.9. RSerPoolOpaqueAddressTC
Opaque address
118. RSVP-MIB (revision 1995-11-03 05:00)
The MIB module to describe the RSVP Protocol
118.1. RsvpEncapsulation
This indicates the encapsulation that an RSVP
Neighbor is perceived to be using.
118.2. RefreshInterval
The number of milliseconds that are expected
to elapse between refreshes of path or reserva-
tion state. Unrefreshed Path or reservation
state is removed after a small multiple of this
period.
119. SCSI-MIB (revision 2006-03-30 00:00)
The SCSI MIB Module. Copyright (C) The Internet Society (2006).
This version of this MIB module is part of RFC 4455; see the RFC
itself for full legal notices.
119.1. ScsiLUN
This textual convention represents a SCSI Logical Unit
Number (LUN). The format of a LUN is documented in Tables
A.2 and A.3 of SAM-2 [SAM2].
119.2. ScsiIndexValue
An arbitrary integer value, greater than zero, for use
Expires August 17, 2014 [Page 235]
Internet-Draft SMIv2 Textual Conventions February 2014
as a unique index value.
119.3. ScsiPortIndexValueOrZero
This textual convention is an extension of the ScsiIndexValue
convention. The latter defines a greater than zero value used
to identify an index. This extension permits the additional
value of zero and is applicable only to indices of SCSI port.
Usage of the zero is object-specific and must therefore be
defined as part of the description of any object that uses
this syntax. Examples of the usage of zero might include
situations where the index was unknown, or when none or all
indices need to be referenced.
119.4. ScsiIndexValueOrZero
This textual convention is an extension of the ScsiIndexValue
convention. The latter defines a greater than zero value used
to identify an index. This extension permits the additional
value of zero. Usage of the zero is object-specific and must
therefore be defined as part of the description of any object
that uses this syntax. Examples of the usage of zero might
include situations where index was unknown, or when none or
all indices need to be referenced.
119.5. ScsiIdentifier
This textual convention represents a generic SCSI port
identifier.
The format depends on the transport used and is documented
in Tables A.2 and A.3 of SAM-2 [SAM2].
119.6. ScsiName
This textual convention represents the name of a SCSI
initiator device, a SCSI target device, a SCSI initiator port
or a SCSI target port.
The format depends on the transport used and is documented
in Tables A.4 and A.5 of SAM-2 [SAM2].
Every object defined using this syntax must define whether it
is
a) always used for a port,
b) always used for a device, or
c) the circumstances under which it is used for a port or
Expires August 17, 2014 [Page 236]
Internet-Draft SMIv2 Textual Conventions February 2014
device.
119.7. ScsiLuNameOrZero
This textual convention represents either the name of a SCSI
logical unit or a zero-length string. Objects defined with
this syntax must specify the meaning of the zero-length
string.
The format of the name of a LU is defined as:
- a zero-length octet string or
- a string of eight bytes.
119.8. ScsiDeviceOrPort
This type specifies whether a particular configuration is
applicable to a port or to a device.
119.9. ScsiIdCodeSet
This textual convention specifies the code set for the
identifier contained in an Identification Descriptor returned
in a logical unit's Device Identification Page, and is
formatted as defined in T10 SPC-2 (see REFERENCE) Table 172 -
Code Set
119.10. ScsiIdAssociation
This textual convention specifies what the identifier is
associated with (e.g., with the addressed physical/logical
device or with a particular port) for the identifier
contained in an Identification Descriptor returned in a
logical unit's Device Identification Page, and is
formatted as defined in T10 SPC-2 (see REFERENCE)
Table 173 - Association.
119.11. ScsiIdType
Expires August 17, 2014 [Page 237]
Internet-Draft SMIv2 Textual Conventions February 2014
This textual convention specifies the type for the identifier
contained in an Identification Descriptor returned in a
logical unit's Device Identification Page, and is formatted
as defined in T10 SPC-2 (see REFERENCE) table 174 - Identifier
Type.
119.12. ScsiIdValue
This textual convention represents an identifier. The objects
of type ScsiIdCodeSet, ScsiIdAssociation, ScsiIdType define
together the format.
The format is the same as contained in an Identification
Descriptor returned in a logical unit's Device Identification
Page, and is formatted as defined in T10 SPC-2
(see REFERENCE).
119.13. ScsiHrSWInstalledIndexOrZero
The index value for a software module's row in the Host
Resources MIBs hrSWInstalledTable. A zero value indicates
that no row in the hrSWInstalledTable is applicable.
120. SIP-MIB (revision 1994-03-31 18:18)
The MIB module to describe SMDS interfaces objects.
120.1. SMDSAddress
The 60-bit SMDS address,
preceded by 4 bits with the following values:
1100 when representing an individual address
1110 when representing a group address.
120.2. IfIndex
The value of this object identifies the
interface for which this entry contains
management information. The value of this
object for a particular interface has the same
value as the ifIndex object, defined in RFC
Expires August 17, 2014 [Page 238]
Internet-Draft SMIv2 Textual Conventions February 2014
1213, for the same interface.
121. SIP-TC-MIB (revision 2007-04-20 00:00)
Session Initiation Protocol (SIP) MIB TEXTUAL-CONVENTION module used
by other SIP-related MIB Modules. Copyright (C) The IETF Trust
(2007). This version of this MIB module is part of RFC 4780; see the
RFC itself for full legal notices.
121.1. SipTCTransportProtocol
This convention is a bit map. Each bit represents a transport
protocol. If a bit has value 1, then that selected transport
protocol is in some way dependent on the context of the object
using this convention. If a bit has value 0, then that
transport protocol is not selected. Combinations of bits can
be set when multiple transport protocols are selected.
bit 0: a protocol other than those defined here
bit 1: User Datagram Protocol
bit 2: Transmission Control Protocol
bit 3: Stream Control Transmission Protocol
bit 4: Transport Layer Security Protocol over TCP
bit 5: Transport Layer Security Protocol over SCTP
121.2. SipTCEntityRole
Expires August 17, 2014 [Page 239]
Internet-Draft SMIv2 Textual Conventions February 2014
This convention defines the role of a SIP entity. Examples of
SIP entities are proxies, user agents, redirect servers,
registrars, or combinations of the above.
User Agent (UA): A logical entity that can act as both a user
agent client and user agent server.
User Agent Client (UAC): A logical entity that creates a new
request, and then uses the client transaction state machinery
to send it. The role of UAC lasts only for the duration of
that transaction. In other words, if a piece of software
initiates a request, it acts as a UAC for the duration of that
transaction. If it receives a request later, it assumes the
role of a user agent server for the processing of that
transaction.
User Agent Server (UAS): A logical entity that generates a
response to a SIP request. The response accepts, rejects,
or redirects the request. This role lasts only for the
duration of that transaction. In other words, if a piece of
software responds to a request, it acts as a UAS for the
duration of that transaction. If it generates a request
later, it assumes the role of a user agent client for the
processing of that transaction.
Proxy, Proxy Server: An intermediary entity that acts as both
a server and a client for the purpose of making requests on
behalf of other clients. A proxy server primarily plays the
role of routing, which means its job is to ensure that a
request is sent to another entity 'closer' to the targeted
user. Proxies are also useful for enforcing policy. A proxy
interprets and, if necessary, rewrites specific parts of a
request message before forwarding it.
Redirect Server: A redirect server is a user agent server that
generates 3xx responses to requests it receives, directing the
client to contact an alternate set of URIs.
Registrar: A registrar is a server that accepts REGISTER
requests and places the information it receives in those
requests into the location service for the domain it handles.
Expires August 17, 2014 [Page 240]
Internet-Draft SMIv2 Textual Conventions February 2014
121.3. SipTCOptionTagHeaders
This convention defines the header fields that use the option
tags per Section 19.2 of RFC 3261. These tags are used in
Require (Section 20.32), Proxy-Require (Section 20.29),
Supported (Section 20.37), and Unsupported (Section 20.40)
header fields.
121.4. SipTCMethodName
This TEXTUAL-CONVENTION is a string that uniquely identifies a
SIP method. The scope of uniqueness is the context of all
defined SIP methods.
Experimental support of extension methods is acceptable and
expected. Extension methods are those defined in
officially sanctioned by IANA.
To support experimental extension methods, any object using
this TEXTUAL-CONVENTION as syntax MAY return/accept a method
identifier value other than those sanctioned by IANA. That
system MUST ensure no collisions with officially assigned
method names.
122. SLAPM-MIB (revision 2000-01-24 00:00)
The Service Level Agreement Performance Monitoring MIB (SLAPM-MIB)
provides data collection and monitoring capabilities for Service
Level Agreements (SLAs) policy definitions.
122.1. SlapmNameType (deprecated)
Expires August 17, 2014 [Page 241]
Internet-Draft SMIv2 Textual Conventions February 2014
The textual convention for naming entities
within this MIB. The actual contents of an object
defined using this textual convention should consist
of the distinguished name portion of an name.
This is usually the right-most
portion of the name. This convention is necessary,
since names within this MIB can be used as index
items and an instance identifier is limited to 128
subidentifiers.
This textual convention has been deprecated. All of the
tables defined within this MIB that use this textual
convention have been deprecated as well since the method
of using a portion of the name (either of a policy
definition or of a traffic profile) has been replaced
by using an Unsigned32 index. The new slapmPolicyNameTable
would then map the Unsigned32 index to a real name.
122.2. SlapmStatus
The textual convention for defining the various
slapmPRMonTable (or old slapmPolicyMonitorTable)
and the slapmSubcomponentTable states for actual policy
rule traffic monitoring.
122.3. SlapmPolicyRuleName
To facilitate internationalization, this TC
represents information taken from the ISO/IEC IS
10646-1 character set, encoded as an octet string
using the UTF-8 character encoding scheme described
in RFC 2044. For strings in 7-bit US-ASCII,
there is no impact since the UTF-8 representation
is identical to the US-ASCII encoding.
123. SMON-MIB (revision 1998-12-16 00:00)
The MIB module for managing remote monitoring device implementations
for Switched Networks
123.1. SmonDataSource
Expires August 17, 2014 [Page 242]
Internet-Draft SMIv2 Textual Conventions February 2014
Identifies the source of the data that the associated function
is configured to analyze. This Textual Convention
extends the DataSource Textual Convention defined by RMON 2
to the following data source types:
- ifIndex.
DataSources of this traditional form are called 'port-based',
but only if ifType. is not equal to 'propVirtual(53)'.
- smonVlanDataSource.
A dataSource of this form refers to a 'Packet-based VLAN'
and is called a 'VLAN-based' dataSource. is the VLAN
ID as defined by the IEEE 802.1Q standard [19]. The
value is between 1 and 4094 inclusive, and it represents
an 802.1Q VLAN-ID with global scope within a given
bridged domain, as defined by [19].
- entPhysicalEntry.
A dataSource of this form refers to a physical entity within
the agent (e.g. entPhysicalClass = backplane(4)) and is called
an 'entity-based' dataSource.
124. SNMP-FRAMEWORK-MIB (revision 2002-10-14 00:00)
The SNMP Management Architecture MIB Copyright (C) The Internet
Society (2002). This version of this MIB module is part of RFC 3411;
see the RFC itself for full legal notices.
124.1. SnmpEngineID
An SNMP engine's administratively-unique identifier.
Objects of this type are for identification, not for
addressing, even though it is possible that an
address may have been used in the generation of
a specific value.
The value for this object may not be all zeros or
all 'ff'H or the empty (zero length) string.
The initial value for this object may be configured
via an operator console entry or via an algorithmic
function. In the latter case, the following
example algorithm is recommended.
Expires August 17, 2014 [Page 243]
Internet-Draft SMIv2 Textual Conventions February 2014
In cases where there are multiple engines on the
same system, the use of this algorithm is NOT
appropriate, as it would result in all of those
engines ending up with the same ID value.
1) The very first bit is used to indicate how the
rest of the data is composed.
0 - as defined by enterprise using former methods
that existed before SNMPv3. See item 2 below.
1 - as defined by this architecture, see item 3
below.
Note that this allows existing uses of the
engineID (also known as AgentID [RFC1910]) to
co-exist with any new uses.
2) The snmpEngineID has a length of 12 octets.
The first four octets are set to the binary
equivalent of the agent's SNMP management
private enterprise number as assigned by the
Internet Assigned Numbers Authority (IANA).
For example, if Acme Networks has been assigned
{ enterprises 696 }, the first four octets would
be assigned '000002b8'H.
The remaining eight octets are determined via
one or more enterprise-specific methods. Such
methods must be designed so as to maximize the
possibility that the value of this object will
be unique in the agent's administrative domain.
For example, it may be the IP address of the SNMP
entity, or the MAC address of one of the
interfaces, with each address suitably padded
with random octets. If multiple methods are
defined, then it is recommended that the first
octet indicate the method being used and the
remaining octets be a function of the method.
3) The length of the octet string varies.
The first four octets are set to the binary
equivalent of the agent's SNMP management
private enterprise number as assigned by the
Expires August 17, 2014 [Page 244]
Internet-Draft SMIv2 Textual Conventions February 2014
Internet Assigned Numbers Authority (IANA).
For example, if Acme Networks has been assigned
{ enterprises 696 }, the first four octets would
be assigned '000002b8'H.
The very first bit is set to 1. For example, the
above value for Acme Networks now changes to be
'800002b8'H.
The fifth octet indicates how the rest (6th and
following octets) are formatted. The values for
the fifth octet are:
0 - reserved, unused.
1 - IPv4 address (4 octets)
lowest non-special IP address
2 - IPv6 address (16 octets)
lowest non-special IP address
3 - MAC address (6 octets)
lowest IEEE MAC address, canonical
order
4 - Text, administratively assigned
Maximum remaining length 27
5 - Octets, administratively assigned
Maximum remaining length 27
6-127 - reserved, unused
128-255 - as defined by the enterprise
Maximum remaining length 27
124.2. SnmpSecurityModel
An identifier that uniquely identifies a
Security Model of the Security Subsystem within
this SNMP Management Architecture.
The values for securityModel are allocated as
follows:
- The zero value does not identify any particular
security model.
Expires August 17, 2014 [Page 245]
Internet-Draft SMIv2 Textual Conventions February 2014
- Values between 1 and 255, inclusive, are reserved
for standards-track Security Models and are
managed by the Internet Assigned Numbers Authority
(IANA).
- Values greater than 255 are allocated to
enterprise-specific Security Models. An
enterprise-specific securityModel value is defined
to be:
enterpriseID * 256 + security model within
enterprise
For example, the fourth Security Model defined by
the enterprise whose enterpriseID is 1 would be
259.
This scheme for allocation of securityModel
values allows for a maximum of 255 standards-
based Security Models, and for a maximum of
256 Security Models per enterprise.
It is believed that the assignment of new
securityModel values will be rare in practice
because the larger the number of simultaneously
utilized Security Models, the larger the
chance that interoperability will suffer.
Consequently, it is believed that such a range
will be sufficient. In the unlikely event that
the standards committee finds this number to be
insufficient over time, an enterprise number
can be allocated to obtain an additional 256
possible values.
Note that the most significant bit must be zero;
hence, there are 23 bits allocated for various
organizations to design and define non-standard
securityModels. This limits the ability to
define new proprietary implementations of Security
Models to the first 8,388,608 enterprises.
It is worthwhile to note that, in its encoded
form, the securityModel value will normally
require only a single byte since, in practice,
the leftmost bits will be zero for most messages
and sign extension is suppressed by the encoding
Expires August 17, 2014 [Page 246]
Internet-Draft SMIv2 Textual Conventions February 2014
rules.
As of this writing, there are several values
of securityModel defined for use with SNMP or
reserved for use with supporting MIB objects.
They are as follows:
0 reserved for 'any'
1 reserved for SNMPv1
2 reserved for SNMPv2c
3 User-Based Security Model (USM)
124.3. SnmpMessageProcessingModel
An identifier that uniquely identifies a Message
Processing Model of the Message Processing
Subsystem within this SNMP Management Architecture.
The values for messageProcessingModel are
allocated as follows:
- Values between 0 and 255, inclusive, are
reserved for standards-track Message Processing
Models and are managed by the Internet Assigned
Numbers Authority (IANA).
- Values greater than 255 are allocated to
enterprise-specific Message Processing Models.
An enterprise messageProcessingModel value is
defined to be:
enterpriseID * 256 +
messageProcessingModel within enterprise
For example, the fourth Message Processing Model
defined by the enterprise whose enterpriseID
is 1 would be 259.
This scheme for allocating messageProcessingModel
values allows for a maximum of 255 standards-
based Message Processing Models, and for a
maximum of 256 Message Processing Models per
enterprise.
Expires August 17, 2014 [Page 247]
Internet-Draft SMIv2 Textual Conventions February 2014
It is believed that the assignment of new
messageProcessingModel values will be rare
in practice because the larger the number of
simultaneously utilized Message Processing Models,
the larger the chance that interoperability
will suffer. It is believed that such a range
will be sufficient. In the unlikely event that
the standards committee finds this number to be
insufficient over time, an enterprise number
can be allocated to obtain an additional 256
possible values.
Note that the most significant bit must be zero;
hence, there are 23 bits allocated for various
organizations to design and define non-standard
messageProcessingModels. This limits the ability
to define new proprietary implementations of
Message Processing Models to the first 8,388,608
enterprises.
It is worthwhile to note that, in its encoded
form, the messageProcessingModel value will
normally require only a single byte since, in
practice, the leftmost bits will be zero for
most messages and sign extension is suppressed
by the encoding rules.
As of this writing, there are several values of
messageProcessingModel defined for use with SNMP.
They are as follows:
0 reserved for SNMPv1
1 reserved for SNMPv2c
2 reserved for SNMPv2u and SNMPv2*
3 reserved for SNMPv3
124.4. SnmpSecurityLevel
Expires August 17, 2014 [Page 248]
Internet-Draft SMIv2 Textual Conventions February 2014
A Level of Security at which SNMP messages can be
sent or with which operations are being processed;
in particular, one of:
noAuthNoPriv - without authentication and
without privacy,
authNoPriv - with authentication but
without privacy,
authPriv - with authentication and
with privacy.
These three values are ordered such that
noAuthNoPriv is less than authNoPriv and
authNoPriv is less than authPriv.
124.5. SnmpAdminString
An 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
Expires August 17, 2014 [Page 249]
Internet-Draft SMIv2 Textual Conventions February 2014
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.
125. SNMP-REPEATER-MIB (revision 1996-09-14 00:00)
Management information for 802.3 repeaters. The following references
are used throughout this MIB module: [IEEE 802.3 Std] refers to IEEE
802.3/ISO 8802-3 Information processing systems - Local area networks
- Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications (1993).
[IEEE 802.3 Mgt] refers to IEEE 802.3u-1995, '10 Mb/s & 100 Mb/s
Management, Section 30,' Supplement to ANSI/IEEE 802.3. The
following terms are used throughout this MIB module. For complete
formal definitions, the IEEE 802.3 standards should be consulted
wherever possible: System - A managed entity compliant with this MIB,
and incorporating at least one managed 802.3 repeater. Chassis - An
enclosure for one managed repeater, part of a managed repeater, or
several managed repeaters. It typically contains an integral power
supply and a variable number of available module slots. Repeater-
unit - The portion of the repeater set that is inboard of the
physical media interfaces. The physical media interfaces (MAUs,
AUIs) may be physically separated from the repeater-unit, or they may
be integrated into the same physical package. Trivial repeater-unit
- An isolated port that can gather statistics. Group - A
Expires August 17, 2014 [Page 250]
Internet-Draft SMIv2 Textual Conventions February 2014
recommended, but optional, entity defined by the IEEE 802.3
management standard, in order to support a modular numbering scheme.
The classical example allows an implementor to represent field-
replaceable units as groups of ports, with the port numbering
matching the modular hardware implementation. System interconnect
segment - An internal segment allowing interconnection of ports
belonging to different physical entities into the same logical
manageable repeater. Examples of implementation might be backplane
busses in modular hubs, or chaining cables in stacks of hubs. Stack
- A scalable system that may include managed repeaters, in which
modularity is achieved by interconnecting a number of different
chassis. Module - A building block in a modular chassis. It
typically maps into one 'slot'; however, the range of configurations
may be very large, with several modules entering one slot, or one
module covering several slots.
125.1. OptMacAddr
Either a 6 octet address in the `canonical'
order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first
if a value is available or a zero length string.
126. SNMP-SSH-TM-MIB (revision 2009-06-09 00:00)
The Secure Shell Transport Model MIB. Copyright (c) 2009 IETF Trust
and the persons identified as authors of the code. All rights
reserved. Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met: - Redistributions of source code must retain the
above copyright notice, this list of conditions and the following
disclaimer. - Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with
the distribution. - Neither the name of Internet Society, IETF or
IETF Trust, nor the names of specific contributors, may be used to
endorse or promote products derived from this software without
specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE
COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
Expires August 17, 2014 [Page 251]
Internet-Draft SMIv2 Textual Conventions February 2014
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of
this MIB module is part of RFC 5592; see the RFC itself for full
legal notices.
126.1. SnmpSSHAddress
Represents either a hostname or IP address, along with a port
number and an optional user name.
The beginning of the address specification may contain a
user name followed by an '@' (US-ASCII character 0x40). This
portion of the address will indicate the user name that should
be used when authenticating to an SSH server. The user name
must be encoded in UTF-8 (per [RFC4252]). If missing, the
SNMP securityName should be used. After the optional user
name field and '@' character comes the hostname or IP
address.
The hostname is always in US-ASCII (as per RFC1033);
internationalized hostnames are encoded in US-ASCII as
specified in RFC 3490. The hostname is followed by a colon
':' (US-ASCII character 0x3A) and a decimal port number in
US-ASCII. The name SHOULD be fully qualified whenever
possible.
An IPv4 address must be in dotted decimal format followed
by a colon ':' (US-ASCII character 0x3A) and a decimal port
number in US-ASCII.
An IPv6 address must be in colon-separated format, surrounded
by square brackets ('[', US-ASCII character 0x5B, and ']',
US-ASCII character 0x5D), followed by a colon ':' (US-ASCII
character 0x3A) and a decimal port number in US-ASCII.
Values of this Textual Convention might not be directly usable
as transport-layer addressing information and may require
runtime resolution. As such, applications that write them
must be prepared for handling errors if such values are
not supported or cannot be resolved (if resolution occurs
at the time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may
have snmpSSHAddress values must fully describe how (and
when) such names are to be resolved to IP addresses and vice
versa.
Expires August 17, 2014 [Page 252]
Internet-Draft SMIv2 Textual Conventions February 2014
This Textual Convention SHOULD NOT be used directly in
object definitions since it restricts addresses to a
specific format. However, if it is used, it MAY be used
either on its own or in conjunction with
TransportAddressType or TransportDomain as a pair.
When this Textual Convention is used as a syntax of an
index object, there may be issues with the limit of 128
sub-identifiers, which is specified in SMIv2 (STD 58). It
is RECOMMENDED that all MIB documents using this Textual
Convention make explicit any limitations on index
component lengths that management software must observe.
This may be done either by including SIZE constraints on
the index components or by specifying applicable
constraints in the conceptual row DESCRIPTION clause or
in the surrounding documentation.
127. SNMP-TARGET-MIB (revision 2002-10-14 00:00)
This MIB module defines MIB objects which provide mechanisms to
remotely configure the parameters used by an SNMP entity for the
generation of SNMP messages. Copyright (C) The Internet Society
(2002). This version of this MIB module is part of RFC 3413; see the
RFC itself for full legal notices.
127.1. SnmpTagValue
An octet string containing a tag value.
Tag values are 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
character encoding scheme described in RFC 2279.
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.
The use of control codes should be avoided, and certain
Expires August 17, 2014 [Page 253]
Internet-Draft SMIv2 Textual Conventions February 2014
control codes are not allowed as described below.
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
representation is identical to the US-ASCII 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 [RFC1905].
An object of this type contains a single tag value
which is used to select a set of entries in a table.
A tag value is an arbitrary string of octets, but
may not contain a delimiter character. Delimiter
characters are defined to be one of the following:
- An ASCII space character (0x20).
- An ASCII TAB character (0x09).
- An ASCII carriage return (CR) character (0x0D).
- An ASCII line feed (LF) character (0x0A).
Delimiter characters are used to separate tag values
in a tag list. An object of this type may only
contain a single tag value, and so delimiter
characters are not allowed in a value of this type.
Note that a tag value of 0 length means that no tag is
defined. In other words, a tag value of 0 length would
never match anything in a tag list, and would never
select any table entries.
Some examples of valid tag values are:
- 'acme'
- 'router'
- 'host'
Expires August 17, 2014 [Page 254]
Internet-Draft SMIv2 Textual Conventions February 2014
The use of a tag value to select table entries is
application and MIB specific.
127.2. SnmpTagList
An octet string containing a list of tag values.
Tag values are 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
character encoding scheme described in RFC 2279.
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.
The use of control codes should be avoided, except as
described below.
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
representation is identical to the US-ASCII encoding.
An object of this type contains a list of tag values
which are used to select a set of entries in a table.
A tag value is an arbitrary string of octets, but
may not contain a delimiter character. Delimiter
characters are defined to be one of the following:
- An ASCII space character (0x20).
- An ASCII TAB character (0x09).
- An ASCII carriage return (CR) character (0x0D).
- An ASCII line feed (LF) character (0x0A).
Delimiter characters are used to separate tag values
Expires August 17, 2014 [Page 255]
Internet-Draft SMIv2 Textual Conventions February 2014
in a tag list. Only a single delimiter character may
occur between two tag values. A tag value may not
have a zero length. These constraints imply certain
restrictions on the contents of this object:
- There cannot be a leading or trailing delimiter
character.
- There cannot be multiple adjacent delimiter
characters.
Some examples of valid tag lists are:
- '' -- an empty list
- 'acme' -- list of one tag
- 'host router bridge' -- list of several tags
Note that although a tag value may not have a length of
zero, an empty string is still valid. This indicates
an empty list (i.e. there are no tag values in the list).
The use of the tag list to select table entries is
application and MIB specific. Typically, an application
will provide one or more tag values, and any entry
which contains some combination of these tag values
will be selected.
128. SNMP-TLS-TM-MIB (revision 2010-05-07 00:00)
The TLS Transport Model MIB Copyright (c) 2010 IETF Trust and the
persons identified as the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
128.1. SnmpTLSAddress
Represents an IPv4 address, an IPv6 address, or a
US-ASCII-encoded hostname and port number.
An IPv4 address must be in dotted decimal format followed by a
colon ':' (US-ASCII character 0x3A) and a decimal port number
Expires August 17, 2014 [Page 256]
Internet-Draft SMIv2 Textual Conventions February 2014
in US-ASCII.
An IPv6 address must be a colon-separated format (as described
in RFC 5952), surrounded by square brackets ('[', US-ASCII
character 0x5B, and ']', US-ASCII character 0x5D), followed by
a colon ':' (US-ASCII character 0x3A) and a decimal port number
in US-ASCII.
A hostname is always in US-ASCII (as per [RFC1033]);
internationalized hostnames are encoded in US-ASCII as domain
names after transformation via the ToASCII operation specified
in [RFC3490]. The ToASCII operation MUST be performed with the
UseSTD3ASCIIRules flag set. The hostname is followed by a
colon ':' (US-ASCII character 0x3A) and a decimal port number
in US-ASCII. The name SHOULD be fully qualified whenever
possible.
Values of this textual convention may not be directly usable
as transport-layer addressing information, and may require
run-time resolution. As such, applications that write them
must be prepared for handling errors if such values are not
supported, or cannot be resolved (if resolution occurs at the
time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may
have SnmpTLSAddress values must fully describe how (and
when) such names are to be resolved to IP addresses and vice
versa.
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific
format. However, if it is used, it MAY be used either on its
own or in conjunction with TransportAddressType or
TransportDomain as a pair.
When this textual convention is used as a syntax of an index
object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2 (STD 58). It is RECOMMENDED
that all MIB documents using this textual convention make
explicit any limitations on index component lengths that
management software must observe. This may be done either by
including SIZE constraints on the index components or by
specifying applicable constraints in the conceptual row
DESCRIPTION clause or in the surrounding documentation.
Expires August 17, 2014 [Page 257]
Internet-Draft SMIv2 Textual Conventions February 2014
128.2. SnmpTLSFingerprint
A fingerprint value that can be used to uniquely reference
other data of potentially arbitrary length.
An SnmpTLSFingerprint value is composed of a 1-octet hashing
algorithm identifier followed by the fingerprint value. The
octet value encoded is taken from the IANA TLS HashAlgorithm
Registry (RFC 5246). The remaining octets are filled using the
results of the hashing algorithm.
This TEXTUAL-CONVENTION allows for a zero-length (blank)
SnmpTLSFingerprint value for use in tables where the
fingerprint value may be optional. MIB definitions or
implementations may refuse to accept a zero-length value as
appropriate.
129. SNMP-USER-BASED-SM-MIB (revision 2002-10-16 00:00)
The management information definitions for the SNMP User-based
Security Model. Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3414; see the RFC itself
for full legal notices.
129.1. KeyChange
Every definition of an object with this syntax must identify
a protocol P, a secret key K, and a hash algorithm H
that produces output of L octets.
The object's value is a manager-generated, partially-random
value which, when modified, causes the value of the secret
key K, to be modified via a one-way function.
The value of an instance of this object is the concatenation
of two components: first a 'random' component and then a
'delta' component.
The lengths of the random and delta components
are given by the corresponding value of the protocol P;
if P requires K to be a fixed length, the length of both the
random and delta components is that fixed length; if P
allows the length of K to be variable up to a particular
maximum length, the length of the random component is that
maximum length and the length of the delta component is any
Expires August 17, 2014 [Page 258]
Internet-Draft SMIv2 Textual Conventions February 2014
length less than or equal to that maximum length.
For example, usmHMACMD5AuthProtocol requires K to be a fixed
length of 16 octets and L - of 16 octets.
usmHMACSHAAuthProtocol requires K to be a fixed length of
20 octets and L - of 20 octets. Other protocols may define
other sizes, as deemed appropriate.
When a requester wants to change the old key K to a new
key keyNew on a remote entity, the 'random' component is
obtained from either a true random generator, or from a
pseudorandom generator, and the 'delta' component is
computed as follows:
- a temporary variable is initialized to the existing value
of K;
- if the length of the keyNew is greater than L octets,
then:
- the random component is appended to the value of the
temporary variable, and the result is input to the
the hash algorithm H to produce a digest value, and
the temporary variable is set to this digest value;
- the value of the temporary variable is XOR-ed with
the first (next) L-octets (16 octets in case of MD5)
of the keyNew to produce the first (next) L-octets
(16 octets in case of MD5) of the 'delta' component.
- the above two steps are repeated until the unused
portion of the keyNew component is L octets or less,
- the random component is appended to the value of the
temporary variable, and the result is input to the
hash algorithm H to produce a digest value;
- this digest value, truncated if necessary to be the same
length as the unused portion of the keyNew, is XOR-ed
with the unused portion of the keyNew to produce the
(final portion of the) 'delta' component.
For example, using MD5 as the hash algorithm H:
iterations = (lenOfDelta - 1)/16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || random);
delta[i*16 .. (i*16)+15] =
temp XOR keyNew[i*16 .. (i*16)+15];
}
temp = MD5 (temp || random);
delta[i*16 .. lenOfDelta-1] =
Expires August 17, 2014 [Page 259]
Internet-Draft SMIv2 Textual Conventions February 2014
temp XOR keyNew[i*16 .. lenOfDelta-1];
The 'random' and 'delta' components are then concatenated as
described above, and the resulting octet string is sent to
the recipient as the new value of an instance of this object.
At the receiver side, when an instance of this object is set
to a new value, then a new value of K is computed as follows:
- a temporary variable is initialized to the existing value
of K;
- if the length of the delta component is greater than L
octets, then:
- the random component is appended to the value of the
temporary variable, and the result is input to the
hash algorithm H to produce a digest value, and the
temporary variable is set to this digest value;
- the value of the temporary variable is XOR-ed with
the first (next) L-octets (16 octets in case of MD5)
of the delta component to produce the first (next)
L-octets (16 octets in case of MD5) of the new value
of K.
- the above two steps are repeated until the unused
portion of the delta component is L octets or less,
- the random component is appended to the value of the
temporary variable, and the result is input to the
hash algorithm H to produce a digest value;
- this digest value, truncated if necessary to be the same
length as the unused portion of the delta component, is
XOR-ed with the unused portion of the delta component to
produce the (final portion of the) new value of K.
For example, using MD5 as the hash algorithm H:
iterations = (lenOfDelta - 1)/16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || random);
keyNew[i*16 .. (i*16)+15] =
temp XOR delta[i*16 .. (i*16)+15];
}
temp = MD5 (temp || random);
keyNew[i*16 .. lenOfDelta-1] =
temp XOR delta[i*16 .. lenOfDelta-1];
Expires August 17, 2014 [Page 260]
Internet-Draft SMIv2 Textual Conventions February 2014
The value of an object with this syntax, whenever it is
retrieved by the management protocol, is always the zero
length string.
Note that the keyOld and keyNew are the localized keys.
Note that it is probably wise that when an SNMP entity sends
a SetRequest to change a key, that it keeps a copy of the old
key until it has confirmed that the key change actually
succeeded.
130. SNMP-USM-DH-OBJECTS-MIB (revision 2000-03-06 00:00)
The management information definitions for providing forward secrecy
for key changes for the usmUserTable, and for providing a method for
'kickstarting' access to the agent via a Diffie-Helman key agreement.
130.1. DHKeyChange
Expires August 17, 2014 [Page 261]
Internet-Draft SMIv2 Textual Conventions February 2014
Upon initialization, or upon creation of a row containing an
object of this type, and after any successful SET of this value, a
GET of this value returns 'y' where y = g^xa MOD p, and where g is
the base from usmDHParameters, p is the prime from
usmDHParameters, and xa is a new random integer selected by the
agent in the interval 2^(l-1) <= xa < 2^l < p-1. 'l' is the
optional privateValueLength from usmDHParameters in bits. If 'l'
is omitted, then xa (and xr below) is selected in the interval 0
<= xa < p-1. y is expressed as an OCTET STRING 'PV' of length 'k'
which satisfies
k
y = SUM 2^(8(k-i)) PV'i
i=1
where PV1,...,PVk are the octets of PV from first to last, and
where PV1 <> 0.
A successful SET consists of the value 'y' expressed as an OCTET
STRING as above concatenated with the value 'z'(expressed as an
OCTET STRING in the same manner as y) where z = g^xr MOD p, where
g, p and l are as above, and where xr is a new random integer
selected by the manager in the interval 2^(l-1) <= xr < 2^l <
p-1. A SET to an object of this type will fail with the error
wrongValue if the current 'y' does not match the 'y' portion of
the value of the varbind for the object. (E.g. GET yout, SET
concat(yin, z), yout <> yin).
Note that the private values xa and xr are never transmitted from
manager to device or vice versa, only the values y and z.
Obviously, these values must be retained until a successful SET on
the associated object.
The shared secret 'sk' is calculated at the agent as sk = z^xa MOD
p, and at the manager as sk = y^xr MOD p.
Each object definition of this type MUST describe how to map from
the shared secret 'sk' to the operational key value used by the
protocols and operations related to the object. In general, if n
bits of key are required, the author suggests using the n
right-most bits of the shared secret as the operational key value.
131. SNMPv2-TC
Expires August 17, 2014 [Page 262]
Internet-Draft SMIv2 Textual Conventions February 2014
131.1. DisplayString
Represents textual information taken from the NVT ASCII
character set, as defined in pages 4, 10-11 of RFC 854.
To summarize RFC 854, the NVT ASCII repertoire specifies:
- the use of character codes 0-127 (decimal)
- the graphics characters (32-126) are interpreted as
US ASCII
- NUL, LF, CR, BEL, BS, HT, VT and FF have the special
meanings specified in RFC 854
- the other 25 codes have no standard interpretation
- the sequence 'CR LF' means newline
- the sequence 'CR NUL' means carriage-return
- an 'LF' not preceded by a 'CR' means moving to the
same column on the next line.
- the sequence 'CR x' for any x other than LF or NUL is
illegal. (Note that this also means that a string may
end with either 'CR LF' or 'CR NUL', but not with CR.)
Any object defined using this syntax may not exceed 255
characters in length.
131.2. PhysAddress
Represents media- or physical-level addresses.
131.3. MacAddress
Represents an 802 MAC address represented in the
`canonical' order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first, even though
802.5 (in contrast to other 802.x protocols) requires MAC
addresses to be transmitted most significant bit first.
Expires August 17, 2014 [Page 263]
Internet-Draft SMIv2 Textual Conventions February 2014
131.4. TruthValue
Represents a boolean value.
131.5. TestAndIncr
Represents integer-valued information used for atomic
operations. When the management protocol is used to specify
that an object instance having this syntax is to be
modified, the new value supplied via the management protocol
must precisely match the value presently held by the
instance. If not, the management protocol set operation
fails with an error of `inconsistentValue'. Otherwise, if
the current value is the maximum value of 2^31-1 (2147483647
decimal), then the value held by the instance is wrapped to
zero; otherwise, the value held by the instance is
incremented by one. (Note that regardless of whether the
management protocol set operation succeeds, the variable-
binding in the request and response PDUs are identical.)
The value of the ACCESS clause for objects having this
syntax is either `read-write' or `read-create'. When an
instance of a columnar object having this syntax is created,
any value may be supplied via the management protocol.
When the network management portion of the system is re-
initialized, the value of every object instance having this
syntax must either be incremented from its value prior to
the re-initialization, or (if the value prior to the re-
initialization is unknown) be set to a pseudo-randomly
generated value.
131.6. AutonomousType
Represents 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.
131.7. InstancePointer (obsolete)
Expires August 17, 2014 [Page 264]
Internet-Draft SMIv2 Textual Conventions February 2014
A pointer to either a specific instance of a MIB object or
a conceptual row of a MIB table in the managed device. In
the latter case, by convention, it is the name of the
particular instance of the first accessible columnar object
in the conceptual row.
The two uses of this textual convention are replaced by
VariablePointer and RowPointer, respectively.
131.8. VariablePointer
A pointer to a specific object instance. For example,
sysContact.0 or ifInOctets.3.
131.9. RowPointer
Represents a pointer to a conceptual row. The value is the
name of the instance of the first accessible columnar object
in the conceptual row.
For example, ifIndex.3 would point to the 3rd row in the
ifTable (note that if ifIndex were not-accessible, then
ifDescr.3 would be used instead).
131.10. RowStatus
The 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
Expires August 17, 2014 [Page 265]
Internet-Draft SMIv2 Textual Conventions February 2014
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
Expires August 17, 2014 [Page 266]
Internet-Draft SMIv2 Textual Conventions February 2014
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
--------------+--------------+-----------+-------------+-------------
Expires August 17, 2014 [Page 267]
Internet-Draft SMIv2 Textual Conventions February 2014
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
Expires August 17, 2014 [Page 268]
Internet-Draft SMIv2 Textual Conventions February 2014
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
Expires August 17, 2014 [Page 269]
Internet-Draft SMIv2 Textual Conventions February 2014
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,
Expires August 17, 2014 [Page 270]
Internet-Draft SMIv2 Textual Conventions February 2014
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.
Expires August 17, 2014 [Page 271]
Internet-Draft SMIv2 Textual Conventions February 2014
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
Expires August 17, 2014 [Page 272]
Internet-Draft SMIv2 Textual Conventions February 2014
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'.
Expires August 17, 2014 [Page 273]
Internet-Draft SMIv2 Textual Conventions February 2014
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).
Expires August 17, 2014 [Page 274]
Internet-Draft SMIv2 Textual Conventions February 2014
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.
131.11. TimeStamp
The 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.
131.12. TimeInterval
A period of time, measured in units of 0.01 seconds.
131.13. DateAndTime
Expires August 17, 2014 [Page 275]
Internet-Draft SMIv2 Textual Conventions February 2014
A 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.
131.14. StorageType
Describes 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.
Expires August 17, 2014 [Page 276]
Internet-Draft SMIv2 Textual Conventions February 2014
131.15. TDomain
Denotes a kind of transport service.
Some possible values, such as snmpUDPDomain, are defined in
the SNMPv2-TM MIB module. Other possible values are defined
in other MIB modules.
131.16. TAddress
Denotes a transport service address.
A TAddress value is always interpreted within the context of a
TDomain value. Thus, each definition of a TDomain value must
be accompanied by a definition of a textual convention for use
with that TDomain. Some possible textual conventions, such as
SnmpUDPAddress for snmpUDPDomain, are defined in the SNMPv2-TM
MIB module. Other possible textual conventions are defined in
other MIB modules.
132. SNMPv2-TM (revision 2002-10-16 00:00)
The MIB module for SNMP transport mappings. Copyright (C) The
Internet Society (2002). This version of this MIB module is part of
RFC 3417; see the RFC itself for full legal notices.
132.1. SnmpUDPAddress
Represents a UDP over IPv4 address:
octets contents encoding
1-4 IP-address network-byte order
5-6 UDP-port network-byte order
132.2. SnmpOSIAddress
Represents an OSI transport-address:
octets contents encoding
1 length of NSAP 'n' as an unsigned-integer
(either 0 or from 3 to 20)
2..(n+1) NSAP concrete binary representation
(n+2)..m TSEL string of (up to 64) octets
Expires August 17, 2014 [Page 277]
Internet-Draft SMIv2 Textual Conventions February 2014
132.3. SnmpNBPAddress
Represents an NBP name:
octets contents encoding
1 length of object 'n' as an unsigned integer
2..(n+1) object string of (up to 32) octets
n+2 length of type 'p' as an unsigned integer
(n+3)..(n+2+p) type string of (up to 32) octets
n+3+p length of zone 'q' as an unsigned integer
(n+4+p)..(n+3+p+q) zone string of (up to 32) octets
For comparison purposes, strings are
case-insensitive. All strings may contain any octet
other than 255 (hex ff).
132.4. SnmpIPXAddress
Represents an IPX address:
octets contents encoding
1-4 network-number network-byte order
5-10 physical-address network-byte order
11-12 socket-number network-byte order
133. SNMPv2-USEC-MIB (revision 1996-01-12 00:00)
The MIB module for SNMPv2 entities implementing the user- based
security model.
133.1. AgentID
Expires August 17, 2014 [Page 278]
Internet-Draft SMIv2 Textual Conventions February 2014
An agent's administratively-unique identifier.
The value for this object may not be all zeros or all 'ff'H.
The initial value for this object may be configured via an
operator console entry or via an algorithmic function. In
the later case, the following guidelines are recommended:
1) The first four octets are set to the binary equivalent
of the agent's SNMP network management private
enterprise number as assigned by the Internet Assigned
Numbers Authority (IANA). For example, if Acme
Networks has been assigned { enterprises 696 }, the
first four octets would be assigned '000002b8'H.
2) The remaining eight octets are the cookie whose
contents are determined via one or more enterprise-
specific methods. Such methods must be designed so as
to maximize the possibility that the value of this
object will be unique in the agent's administrative
domain. For example, the cookie may be the IP address
of the agent, or the MAC address of one of the
interfaces, with each address suitably padded with
random octets. If multiple methods are defined, then
it is recommended that the cookie be further divided
into one octet that indicates the method being used and
seven octets which are a function of the method.
134. SSPM-MIB (revision 2005-07-28 00:00)
This SSPM MIB module is applicable to probes implementing Synthetic
Source for Performance Monitoring functions. Copyright (C) The
Internet Society (2005). This version of this MIB module is part of
RFC 4149; see the RFC itself for full legal notices.
134.1. SspmMicroSeconds
A unit of time with resolution of MicroSeconds.
134.2. SspmClockSource
Expires August 17, 2014 [Page 279]
Internet-Draft SMIv2 Textual Conventions February 2014
An indication of the source of the clock as defined by the
NTP specification RFC1305 [RFC1305] definition of stratum:
Stratum (sys.stratum, peer.stratum, pkt.stratum): This is
an integer indicating the stratum of the local clock,
with values defined as follows:
0 unspecified
1 primary reference (e.g., calibrated atomic clock,
radio clock)
2-255 secondary reference (via NTP).
134.3. SspmClockMaxSkew
An indication of the accuracy of the clock as defined by
RFC1305. This variable indicates the maximum offset
error due to skew of the local clock over the
time interval 86400 seconds, in seconds.
135. SYSAPPL-MIB (revision 1997-10-20 00:00)
The MIB module defines management objects that model applications as
collections of executables and files installed and executing on a
host system. The MIB presents a system-level view of applications;
i.e., objects in this MIB are limited to those attributes that can
typically be obtained from the system itself without adding special
instrumentation to the applications.
135.1. RunState
This TC describes the current execution state of
a running application or process. The possible
values are:
running(1),
runnable(2), - waiting for a resource (CPU, etc.)
waiting(3), - waiting for an event
exiting(4),
other(5) - other invalid state
135.2. LongUtf8String
Expires August 17, 2014 [Page 280]
Internet-Draft SMIv2 Textual Conventions February 2014
To facilitate internationalization, this TC
represents information taken from the ISO/IEC IS
10646-1 character set, encoded as an octet string
using the UTF-8 character encoding scheme described
in RFC 2044 [10]. For strings in 7-bit US-ASCII,
there is no impact since the UTF-8 representation
is identical to the US-ASCII encoding.
135.3. Utf8String
To facilitate internationalization, this TC
represents information taken from the ISO/IEC IS
10646-1 character set, encoded as an octet string
using the UTF-8 character encoding scheme described
in RFC 2044 [10]. For strings in 7-bit US-ASCII,
there is no impact since the UTF-8 representation
is identical to the US-ASCII encoding.
136. T11-FC-FABRIC-ADDR-MGR-MIB (revision 2006-03-02 00:00)
The MIB module for the Fabric Address management functionality
defined by the Fibre Channel standards. For the purposes of this
MIB, Fabric Address Manager refers to the functionality of acquiring
DomainID(s) as specified in FC-SW-3, and managing Fibre Channel
Identifiers as specified in FC-FS. An instance of 'Fabric Address
Manager' software functionality executes in the Principal Switch, and
in each other switch. After an agent reboot, the values of read-
write objects defined in this MIB module are implementation-
dependent. Copyright (C) The Internet Society (2006). This version
of this MIB module is part of RFC 4439; see the RFC itself for full
legal notices.
136.1. T11FamDomainPriority
Expires August 17, 2014 [Page 281]
Internet-Draft SMIv2 Textual Conventions February 2014
Priority of a switch.
The Principal Switch selection is influenced by the
priority of the switches.
Some values of importance are:
1 : The highest priority in Principal Switch
selection, which is used by the administrator
to establish which switch becomes the Principal
Switch.
255 : Indicates that the switch is not capable of
acting as a Principal Switch.
136.2. T11FamDomainInterfaceRole
The 'designated' state/role of the Inter-Switch Link (ISL)
to which an interface connects, or (if not connected)
the state of the interface:
nonPrincipal (1) - non-Principal ISL
principalUpstream (2) - Upstream Principal ISL
principalDownsteam (3) - Downstream Principal ISL
isolated (4) - interface is isolated
down (5) - interface is down
unknown (6) - state/role is unknown
136.3. T11FamState
Expires August 17, 2014 [Page 282]
Internet-Draft SMIv2 Textual Conventions February 2014
The state of the Fabric Address Manager, as described in
Table 86 and Figure 15 of FC-SW-3.
- 'other' represents a switch that is in a state not
represented by any of the below enumerations.
- 'starting' represents a switch engaged in the process
represented by the first row in Table 86.
- 'unconfigured' represents a switch that requires
operator input before it can begin the process
represented by the first row in Table 86.
- 'principalSwitchSelection' represents a switch engaged
in the process represented by the second row in
Table 86, but not in states F0 or F1 of Figure 15.
- 'domainIdDistribution' represents a switch engaged in
the process represented by the third row in Table 86.
- 'buildFabricPhase' represents a switch that is in
state F0 of Figure 15.
- 'reconfigureFabricPhase' represents a switch that is
in state F1 of Figure 15.
- 'stable' represents a switch that has successfully
completed the process represented by the third row in
Table 86 and has at least one E_Port.
- 'stableWithNoEports' represents a switch that has
successfully completed the process represented by the
third row in Table 86 but has no E_Ports.
- 'noDomains' represents a switch that has completed
the process represented by the third row in Table 86
but failed to obtain a Domain_ID.
- 'disabled' represents any situation in which the
corresponding instance of t11FamEnable has the value
'false'.
- 'unknown' represents a switch that is confused about
what state it is in.
Expires August 17, 2014 [Page 283]
Internet-Draft SMIv2 Textual Conventions February 2014
137. T11-FC-FABRIC-CONFIG-SERVER-MIB (revision 2007-06-27 00:00)
The MIB module for the management of a Fabric Configuration Server
(FCS) in a Fibre Channel (FC) network. An FCS is defined by the FC-
GS-5 standard. This MIB provides the capabilities to trigger a
discovery of the configuration of one or more Fabrics, to retrieve
the results of such a discovery, as well as to control and monitor
the operation of an FCS. The discovered configuration contains
information about: - Interconnect Elements (IEs), i.e., switches,
hubs, bridges, etc., - Ports on IEs, and - Platforms that consist of
one or more FC nodes. Copyright (C) The IETF Trust (2007). This
version of this MIB module is part of RFC 4935; see the RFC itself
for full legal notices.
137.1. T11FcListIndex
An index that identifies a list of elements.
All elements that belong to the same list have the
same index value. This syntax is used for objects
which identify a list in the INDEX clause of a table
of elements of that type of list.
137.2. T11FcListIndexPointerOrZero
Objects with this syntax point to a list of elements
contained in a table, by holding the same value as the
object with syntax T11FcListIndex defined in the table's
INDEX clause, or, zero to indicate an empty list.
Note that such a table could have one row per list, or
it could have one row per element of a list.
The definition of an object with this syntax must
identify the table(s) into which it points.
137.3. T11FcIeType
The type of Interconnect Element (IE):
unknown(1) - an unknown IE.
other(2) - some other type of IE.
switch(3) - the IE is a switch.
hub(4) - the IE is a hub.
bridge(5) - the IE is a bridge.
Expires August 17, 2014 [Page 284]
Internet-Draft SMIv2 Textual Conventions February 2014
137.4. T11FcPortState
The state of a port:
unknown(1) - unknown state.
other(2) - some other state.
online(3) - port is in online state.
offline(4) - port is in offline state.
testing(5) - port is in testing state.
fault(6) - port is faulty.
137.5. T11FcPortTxType
The technology of the port transceiver:
unknown(1) - unknown (includes the 'null' type)
other(2) - some other technology
shortwave850nm(3) - Short wave laser - SN (850 nm)
longwave1550nm(4) - Long wave laser - LL (1550 nm)
longwave1310nm(5) - Long wave laser cost
reduced - LC (1310 nm)
electrical(6) - Electrical - EL.
tenGbaseSr850(7) - 10GBASE-SR 850nm laser
tenGbaseLr1310(8) - 10GBASE-LR 1310nm laser
tenGbaseEr1550(9) - 10GBASE-ER 1550nm laser
tenGbaseLx1300(10) - 10GBASE-LX4 WWDM 1300nm laser
tenGbaseSw850(11) - 10GBASE-SW 850nm laser
tenGbaseLw1310(12) - 10GBASE-LW 1310nm laser
tenGbaseEw1550(13) - 10GBASE-EW 1550nm laser
137.6. T11FcsRejectReasonExplanation
The reject reason code explanation:
noAdditionalExplanation(1)
- no additional explanation.
invNameIdForIEOrPort(2)
- the format of IE or port name is invalid.
ieListNotAvailable(3)
- IE list is not available.
ieTypeNotAvailable(4)
- IE type is not available.
domainIdNotAvailable(5)
- Domain ID is not available.
mgmtIdNotAvailable(6)
Expires August 17, 2014 [Page 285]
Internet-Draft SMIv2 Textual Conventions February 2014
- mgmt ID is not available.
fabNameNotAvailable(7)
- Fabric_Name is not available.
ielogNameNotAvailable(8)
- IE logical name is not available.
mgmtAddrListNotAvailable(9)
- mgmt address list is not available.
ieInfoListNotAvailable(10)
- IE info list is not available.
portListNotAvailable(11)
- port list is not available.
portTypeNotAvailable(12)
- port type is not available.
phyPortNumNotAvailable(13)
- physical port number is not available.
attPortNameListNotAvailable(14)
- attached port name list is not available.
portStateNotAvailable(15)
- port state is not available.
unableToRegIELogName(16)
- not able to register IE logical name.
platformNameNoExist(17)
- platform name does not exist.
platformNameAlreadyExists(18)
- platform name already exists.
platformNodeNameNoExists(19)
- platform node name does not exist.
platformNodeNameAlreadyExists(20)
- platform node name already exists.
resourceUnavailable(21)
- resource unavailable.
noEntriesInLunMap(22)
- zero entries in OS LUN Map.
invalidDeviceNameLength(23)
- invalid OS device name length.
multipleAttributes(24)
- multiple attributes of same type in
platform attribute block.
invalidAttribBlockLength(25)
- invalid platform attribute block length.
attributesMissing(26)
- required platform attributes not present.
Expires August 17, 2014 [Page 286]
Internet-Draft SMIv2 Textual Conventions February 2014
138. T11-FC-FSPF-MIB (revision 2006-08-14 00:00)
The MIB module for managing the Fabric Shortest Path First (FSPF)
protocol. FSPF is specified in FC-SW-4. Copyright (C) The Internet
Society (2006). This version of this MIB module is part of RFC 4626;
see the RFC itself for full legal notices.
138.1. T11FspfLsrType
Type of the Link State Record.
FC-SW-4 defines two types of LSRs and allows for the
possibility for more will be defined in the future:
01 - Switch Link Record
02 - Obsolete
240 - 255 - Vendor Specific
others - Reserved.
138.2. T11FspfLinkType
Type of an the FSPF Link. Presently defined values:
1 - Point-to-Point
240-255 - Vendor Specific
all others - Reserved.
138.3. T11FspfInterfaceState
The state of the FSPF Neighbor Finite State Machine
for the neighbor (switch) on a particular interface.
Possible values are :
down(1) - Down
init(2) - Init
dbExchange(3) - Database Exchange
dbAckwait(4) - Database AckWait
dbWait(5) - Database Wait
full(6) - Full (Connected)
138.4. T11FspfLastCreationTime
Expires August 17, 2014 [Page 287]
Internet-Draft SMIv2 Textual Conventions February 2014
This TC describes an object that stores the last time
it, and the row containing it, was created.
This can be used by management applications to determine
that a row has been deleted and re-created between reads,
causing an otherwise undetectable discontinuity in the
data.
139. T11-FC-NAME-SERVER-MIB (revision 2006-03-02 00:00)
The MIB module for the management of the functionality, which
realizes the FC-GS-4 requirements for Name Server (NS). Copyright
(C) The Internet Society (2006). This version of this MIB module is
part of RFC 4438; see the RFC itself for full legal notices.
139.1. T11NsGs4RejectReasonCode
The FC-GS-4 reject reason code for a request.
none(1)
- no error.
invalidCmdCode(2)
- request contained an invalid command code.
invalidVerLevel(3)
- request contained an invalid version number.
logicalError(4)
- there was a logical error.
invalidIUSize(5)
- the CT_IU (Information Unit) size was invalid.
logicalBusy(6)
- the module is busy.
protocolError(7)
- there was a protocol error.
unableToPerformCmdReq(8)
- the command specified in the req could not be
executed. The details of exactly what failed
will be in the corresponding reason code
explanation.
cmdNotSupported(9)
- the command is not supported.
serverNotAvailable(10)
- the identified server was not available.
couldNotEstabSession(11)
- a server session could not be established.
vendorError(12)
- a vendor-specific error.
Expires August 17, 2014 [Page 288]
Internet-Draft SMIv2 Textual Conventions February 2014
139.2. T11NsRejReasonCodeExpl
The reject reason code explanation:
noAdditionalExplanation(1)
- no additional explanation.
portIdentifierNotRegistered(2)
- Port Identifier not registered.
portNameNotRegistered(3)
- Port Name not registered.
nodeNameNotRegistered(4)
- Node Name not registered.
classOfServiceNotRegistered(5)
- Class of Service not registered.
nodeIpAddressNotRegistered(6)
- 'IP Address (Node)' value not registered.
ipaNotRegistered(7)
- Initial Process Associator (IPA) not registered.
fc4TypeNotRegistered(8)
- FC-4 TYPEs not registered.
symbolicPortNameNotRegistered(9)
- Symbolic Port Name not registered.
symbolicNodeNameNotRegistered(10)
- Symbolic Node Name not registered.
portTypeNotRegistered(11)
- 'Port Type' not registered.
portIpAddressNotRegistered(12)
- 'IP Address (Port)' value not registered.
fabricPortNameNotRegistered(13)
- Fabric Port Name not registered.
hardAddressNotRegistered(14)
- 'Hard Address' not registered.
fc4DescriptorNotRegistered(15)
- FC-4 Descriptor not registered.
fc4FeaturesNotRegistered(16)
- FC-4 Features not registered.
accessDenied(17)
- Access denied.
unacceptablePortIdentifier(18)
- Unacceptable Port Identifier.
databaseEmpty(19)
- Database is empty.
noObjectRegInSpecifiedScope(20)
- no object has been registered in the specified
Expires August 17, 2014 [Page 289]
Internet-Draft SMIv2 Textual Conventions February 2014
scope.
domainIdNotPresent(21)
- Domain ID not present.
portIdNotPresent(22)
- Port number not present.
noDeviceAttached(23)
- No device attached.
authorizationException(24)
- Authorization Exception.
authenticationException(25)
- Authentication Exception.
databaseFull(26)
- Database full.
140. T11-FC-ZONE-SERVER-MIB (revision 2007-06-27 00:00)
The MIB module for the management of Fibre Channel Zoning Servers,
both for Basic Zoning Management and for Enhanced Zoning Management,
as defined in the FC-GS-5 specification. FC-GS-5 defines (in-band)
management operations for manipulating the Zone Set Database, some
for use in Basic mode (e.g., 'Add Zone Set (AZS)', etc.), and some
for use in Enhanced mode (e.g., Create Zone Set (CZS)', etc.). When
Enhanced Zoning Management is in use, FC-GS-5 requires that these in-
band management operations be rejected unless they are issued within
the context of a GS-5 server session. The use of a server session
ensures serialized access to the Zoning Database since the Fabric
lock for the Zone Server must be obtained as a part of establishing
the server session to the Zone Server. Thus, if and when this MIB is
used for Enhanced Zoning Management, SNMP SetRequests that request
the modification of zoning definitions must be serialized with
respect to the GS-5 requests to modify the Zoning Database. This is
achieved by requiring that an SNMP management application must first
obtain the Fabric lock for the Zone Server before attempting to
modify any zoning definitions. The companion T11-FC-FABRIC-LOCK-MIB
module is defined as a means of obtaining the Fabric lock for the
Zone Server (or any other server). In Enhanced Zoning Management, a
Zone Server keeps track of changes requested in the zoning
definitions, but does not update its Zone Set Database unless there
is (and until there is) a 'commit' operation. To model this
behavior, this MIB module assumes that a Zone Server (in Enhanced
mode) takes a snapshot of its Zone Set Database as and when the
Fabric lock (for the Zone Server application) is obtained; this
snapshot is used to create what is herein called the 'copy' database.
It is this 'copy' database that is then updated by SNMP SetRequests
(while the Fabric is locked). If and when a 'commit' operation is
requested (while the Fabric is still locked), the 'copy' database is
then used to overwrite the previously committed contents of the Zone
Expires August 17, 2014 [Page 290]
Internet-Draft SMIv2 Textual Conventions February 2014
Set Database, and the new Zone Set Database is distributed to all
other switches in the Fabric. When the lock is released, any changes
made that were not 'committed' are discarded. When this MIB is used
for Basic Zoning Management, the same set of MIB objects as used for
Enhanced mode are used to make changes to the Database of a Zone
Server on a particular switch, but the changes take immediate effect
at that switch without an explicit commit. The distribution of those
changes to Zone Servers on other switches in the Fabric is
subsequently requested through the use of a separate set of MIB
objects. The management information specified in this MIB module
includes the Zoning Database for each of one or more Fibre Channel
Fabrics. A Zoning Database is a combination of the Fabric's Zone Set
Database and its Active Zone Set. The Active Zone Set is the Zone Set
currently enforced by the Fabric; a Zone Set Database is a database
of the Zone Sets available to be activated within a Fabric. All the
MIB objects representing a Zone Set Database are modifiable at any
time (irrespective of the value of any RowStatus object), whereas all
objects representing the Active Zone Set are always read-only (except
to deactivate it and/or activate a different one). Copyright (C) The
IETF Trust (2007). This version of this MIB module is part of RFC
4936; see the RFC itself for full legal notices.
140.1. T11ZsZoneMemberType
Represents the addressing mechanism by
which a member is identified:
01 - N_Port_Name
02 - Domain_ID and physical port
03 - N_Port_ID
04 - Node_Name
05 - Alias Name
06 - F_Port_Name
E0-FF (hex) - Vendor Specific.
140.2. T11ZsRejectReasonExplanation
The reason code explanation when rejecting a
Zone Server request:
'other'
- e.g., a reason code assigned too recently
to be included in this version of this MIB
'noAdditionalExplanation'
- there is no additional explanation
'zonesNotSupported'
Expires August 17, 2014 [Page 291]
Internet-Draft SMIv2 Textual Conventions February 2014
- Zones are not supported
'zoneSetNameUnknown'
- Zone Set name is not known
'noZoneSetActive'
- no Zone Set is currently active
'zoneNameUnknown'
- Zone name is unknown
'zoneStateUnknown'
- state of the Zone is not known
'incorrectPayloadLen'
- payload length is not correct
'tooLargeZoneSet'
- Zone Set is larger than permitted size
'deactivateZoneSetFailed'
- deactivation of Zone Set failed
'reqNotSupported'
- request is not supported
'capabilityNotSupported'
- capability is not supported
'zoneMemberIDTypeNotSupp'
- Zone Member Identifier Type is not supported
'invalidZoneSetDefinition'
- Zone Set definition is invalid
'enhancedZoningCmdsNotSupported'
- Enhanced Zoning commands are not supported
'zoneSetExists'
- Zone Set already exists
'zoneExists'
- Zone already exists
'aliasExists'
- Zone Alias already exists
'zoneSetUnknown'
- Zone Set unknown
'zoneUnknown'
- Zone unknown
'aliasUnknown'
- Zone Alias unknown
'zoneAliasTypeUnknown'
- unknown Zone attribute type
'unableEnhancedMode'
- Fabric unable to work in Enhanced Mode
'basicZoningCmdsNotSupported'
- Basic Zoning commands are not supported
'zoneAttribObjectExists'
- Zone attribute object already exists
'zoneAttribObjectUnknown'
Expires August 17, 2014 [Page 292]
Internet-Draft SMIv2 Textual Conventions February 2014
- Zone attribute object unknown
'requestInProcess'
- request in process
'cmitInProcess'
- CMIT in process
'hardEnforcementFailed'
- hard enforcement failed
'unresolvedReferences'
- unresolved references in the Zone Set Database
'consistencyChecksFailed'
- consistency checks failed.
140.3. T11ZoningName
This datatype is a refinement of an SnmpAdminString,
and is used to represent a name stored in a Fibre
Channel Zoning Data Structure.
The value begins with an ASCII letter (upper or lower
case) followed by zero or more characters from the set:
lower case letters, upper case letters, numbers, and
the symbols ($-^_).
The value does not include fill bytes.
141. T11-TC-MIB (revision 2006-03-02 00:00)
This module defines textual conventions used in T11 MIBs. Copyright
(C) The Internet Society (2006). This version of this MIB module is
part of RFC 4439; see the RFC itself for full legal notices.
141.1. T11FabricIndex
Expires August 17, 2014 [Page 293]
Internet-Draft SMIv2 Textual Conventions February 2014
A 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.
142. TCP-ESTATS-MIB (revision 2007-05-18 00:00)
Documentation of TCP Extended Performance Instrumentation variables
from the Web100 project. [Web100] All of the objects in this MIB
MUST have the same persistence properties as the underlying TCP
implementation. On a reboot, all zero-based counters MUST be
cleared, all dynamically created table rows MUST be deleted, and all
read-write objects MUST be restored to their default values. It is
assumed that all TCP implementation have some initialization code (if
nothing else to set IP addresses) that has the opportunity to adjust
tcpEStatsConnTableLatency and other read-write scalars controlling
the creation of the various tables, before establishing the first TCP
connection. Implementations MAY also choose to make these control
scalars persist across reboots. Copyright (C) The IETF Trust (2007).
This version of this MIB module is a part of RFC 4898; see the RFC
itself for full legal notices.
142.1. TcpEStatsNegotiated
Expires August 17, 2014 [Page 294]
Internet-Draft SMIv2 Textual Conventions February 2014
Indicates if some optional TCP feature was negotiated.
Enabled(1) indicates that the feature was successfully
negotiated on, which generally requires both hosts to agree
to use the feature.
selfDisabled(2) indicates that the local host refused the
feature because it is not implemented, configured off, or
refused for some other reason, such as the lack of
resources.
peerDisabled(3) indicates that the local host was willing
to negotiate the feature, but the remote host did not
do so.
143. TED-MIB (revision 2012-12-21 00:00)
This MIB module contains managed object definitions for TED in
support of MPLS/GMPLS TE Database. Copyright (c) 2013 IETF Trust and
the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
143.1. TedAreaIdTC
The area identifier of the IGP. If OSPF is used to advertise
LSA, this represents an ospfArea. If IS-IS is used, this
represents an area address.
143.2. TedRouterIdTC
The router identifier. If OSPF is used to advertise LSA, this
represents a Router ID. If IS-IS is used, this represents a
System ID.
143.3. TedLinkIndexTC
The link identifier. If OSPF is used, this represents an
ospfLsdbID. If IS-IS is used, this represents an isisLSPID.
If a locally configured link is used, this object represents an
arbitrary value, which is locally defined in a router.
Expires August 17, 2014 [Page 295]
Internet-Draft SMIv2 Textual Conventions February 2014
144. TE-LINK-STD-MIB (revision 2005-10-11 00:00)
Copyright (C) 2005 The Internet Society. This version of this MIB
module is part of RFC 4220; see the RFC itself for full legal
notices. This MIB module contains managed object definitions for
MPLS traffic engineering links as defined in 'Link Bundling in MPLS
Traffic Engineering (TE)'.
144.1. TeLinkBandwidth
This type is used to represent link bandwidth in bps. This
value is represented using a 4 octet IEEE floating point
format [IEEE]. The floating point representation is not
used to represent fractional value but rather to allow
specification of large numbers that cannot be expressed
with 32-bit integers.
144.2. TeLinkPriority
This type is used to represent a priority. Each connection
is assigned a priority. This priority is used when
accounting for bandwidth on TE links or component
links, for resource allocation and for rerouting purposes.
Value 0 is the highest priority. Value 7 is the lowest
priority.
144.3. TeLinkProtection
Link protection.
144.4. TeLinkSwitchingCapability
Switching capability as specified in the 'OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)' document. The values specified in this document
are not contiguous.
144.5. TeLinkEncodingType
Link encoding type as specified in 'Generalized
Multi-Protocol Label Switching (GMPLS) Signaling
Functional Description' document. The values
specified in this document are not contiguous.
Expires August 17, 2014 [Page 296]
Internet-Draft SMIv2 Textual Conventions February 2014
144.6. TeLinkSonetSdhIndication
This convention is used to indicate whether the interface
supports Standard or Arbitrary SONET/SDH. To simplify the
mapping process, the values used in this textual convention
match the values specified in the interface switching
capability specific information field, i.e., 0 for Standard
SONET/SDH and 1 for Arbitrary SONET/SDH.
145. TIME-AGGREGATE-MIB (revision 2006-04-27 00:00)
The MIB for servicing Time-Based aggregate objects. Copyright (C)
The Internet Society (2006). This version of this MIB module is part
of RFC 4498; see the RFC itself for full legal notices.
145.1. TAggrMOErrorStatus
This data type is used to model the error status of the
sampled MO instance. The error status for a sampled MO
instance is given in terms of two elements:
o The moIndex, which indicates the sample number of the MO
instance (starting at 1) in the value of the time-
aggregated MO instance.
o The moError, which indicates the error that was
encountered in sampling that MO instance.
The syntax in ASN.1 Notation will be
ErrorStatus :: = SEQUENCE {
moIndex Integer32,
moError SnmpPduErrorStatus
}
TAggrMOErrorStatus ::= SEQUENCE OF {
ErrorStatus
}
Note1: The command responder will supply values for all
the samples of the MO instance. If an error is
encountered for a sample, then the corresponding
value will have an ASN.1 value NULL, and an error
will be flagged in the corresponding
TAggrMOErrorStatus object.
Only MOs for which errors have been encountered will
the corresponding moIndex and moError values be set.
Note2: The error code for the component MO instances will be
in accordance with the SnmpPduErrorStatus TC defined
in the DISMAN-SCHEDULE-MIB[RFC3231].
Expires August 17, 2014 [Page 297]
Internet-Draft SMIv2 Textual Conventions February 2014
145.2. TimeAggrMOValue
This data type is used to model the time-aggregated MOs. It
will be a sequence of values. The syntax in ASN.1 Notation
will be
MOSampleValue :: = SEQUENCE {
value ObjectSyntax
}
TimeAggrMOValue ::= SEQUENCE OF {
MOSampleValue
}
where the first MOSampleValue, if any, will always be the
timestamp of the first sample in the aggregated object. The
subsequent values are the values of the MO instance sampled
at the specified intervals for the specified number of times.
Note: The command generator will need to know the
constituent MO instance and the sampling interval to
correctly interpret TimeAggrMOValue.
145.3. CompressedTimeAggrMOValue
This data type is used to model the compressed
TAgMOs.
146. TN3270E-MIB (revision 1998-07-27 00:00)
This module defines a portion of the management information base
(MIB) for managing TN3270E servers.
146.1. SnaResourceName
Expires August 17, 2014 [Page 298]
Internet-Draft SMIv2 Textual Conventions February 2014
The textual convention for defining an SNA resource
name. A fully qualified SNA resource name, consisting
of a 1 to 8 character network identifier (NetId), a
period ('.'), and a 1 to 8 character resource name
(ResName).
The NetId and ResName are constructed from the
uppercase letters 'A' - 'Z' and the numerics '0' - '9',
all encoded in ASCII, with the restriction that the
first character of each must be a letter. Blanks are
not allowed.
Earlier versions of SNA permitted three additional
characters in NetIds and ResNames: '#', '@', and '$'.
While this use of these characters has been retired,
a Management Station should still accept them for
backward compatibility.
Note: This Textual Convention is not subject to
internationalization, and does not use the character
encodings used by the Utf8String Textual Convention.
146.2. Tn3270eTraceData
Expires August 17, 2014 [Page 299]
Internet-Draft SMIv2 Textual Conventions February 2014
An octet string representing trace data from the
Telnet half of a TN3270E session, from the SNA half,
or from both. The octet string contains a sequence
of trace elements, with the trace elements in the
string ordered from earliest to latest.
Each trace element has the following form:
+---+---+----+----------------------+
!length !type!data !
+---+---+----+----------------------+
where:
length = two-octet length of the data portion of the
trace element, not including the length and
type octets
type = one-octet code point characterizing the data;
defined values are:
X'01' telnet PDU from the server to the client
X'02' telnet PDU from the client to the server
X'03' SNA data from the server to the SNA host
X'04' SNA data from the SNA host to the server
data = initial part of a PDU.
It is implementation-dependent where the 'initial part of
a PDU' starts. For SNA data, however, the starting point
SHOULD be the first byte of the TH. For IP data the
starting point SHOULD be the first byte of the IP header.
It is left to implementations to determine how much of
each PDU to return in a trace element.
The zero-length string indicates that no trace
data is available.
147. TOKENRING-STATION-SR-MIB (revision 1994-12-16 10:00)
The MIB module for managing source routes in end-stations on IEEE
802.5 Token Ring networks.
147.1. SourceRoute
Expires August 17, 2014 [Page 300]
Internet-Draft SMIv2 Textual Conventions February 2014
Represents a Source Route, containing an
embedded sequence of bridge and ring ID's,
as used by 802.5 Source Routing.
148. TRANSPORT-ADDRESS-MIB (revision 2002-11-01 00:00)
This MIB module provides commonly used transport address definitions.
Copyright (C) The Internet Society (2002). This version of this MIB
module is part of RFC 3419; see the RFC itself for full legal
notices.
148.1. TransportDomain
A value that represents a transport domain.
Some possible values, such as transportDomainUdpIpv4, are
defined in this module. Other possible values can be
defined in other MIB modules.
148.2. TransportAddressType
Expires August 17, 2014 [Page 301]
Internet-Draft SMIv2 Textual Conventions February 2014
A value that represents a transport domain. This is the
enumerated version of the transport domain registrations
in this MIB module. The enumerated values have the
following meaning:
unknown(0) unknown transport address type
udpIpv4(1) transportDomainUdpIpv4
udpIpv6(2) transportDomainUdpIpv6
udpIpv4z(3) transportDomainUdpIpv4z
udpIpv6z(4) transportDomainUdpIpv6z
tcpIpv4(5) transportDomainTcpIpv4
tcpIpv6(6) transportDomainTcpIpv6
tcpIpv4z(7) transportDomainTcpIpv4z
tcpIpv6z(8) transportDomainTcpIpv6z
sctpIpv4(9) transportDomainSctpIpv4
sctpIpv6(10) transportDomainSctpIpv6
sctpIpv4z(11) transportDomainSctpIpv4z
sctpIpv6z(12) transportDomainSctpIpv6z
local(13) transportDomainLocal
udpDns(14) transportDomainUdpDns
tcpDns(15) transportDomainTcpDns
sctpDns(16) transportDomainSctpDns
This textual convention can be used to represent transport
domains in situations where a syntax of TransportDomain is
unwieldy (for example, when used as an index).
The usage of this textual convention implies that additional
transport domains can only be supported by updating this MIB
module. This extensibility restriction does not apply for the
TransportDomain textual convention which allows MIB authors
to define additional transport domains independently in
other MIB modules.
148.3. TransportAddress
Expires August 17, 2014 [Page 302]
Internet-Draft SMIv2 Textual Conventions February 2014
Denotes a generic transport address.
A TransportAddress value is always interpreted within the
context of a TransportAddressType or TransportDomain value.
Every usage of the TransportAddress textual convention MUST
specify the TransportAddressType or TransportDomain object
which provides the context. Furthermore, MIB authors SHOULD
define a separate TransportAddressType or TransportDomain
object for each TransportAddress object. It is suggested that
the TransportAddressType or TransportDomain is logically
registered before the object(s) which use the
TransportAddress textual convention if they appear in the
same logical row.
The value of a TransportAddress object must always be
consistent with the value of the associated
TransportAddressType or TransportDomain object. Attempts
to set a TransportAddress object to a value which is
inconsistent with the associated TransportAddressType or
TransportDomain must fail with an inconsistentValue error.
When this textual convention is used as a 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-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers.
148.4. TransportAddressIPv4
Represents a transport address consisting of an IPv4
address and a port number (as used for example by UDP,
TCP and SCTP):
octets contents encoding
1-4 IPv4 address network-byte order
5-6 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
Expires August 17, 2014 [Page 303]
Internet-Draft SMIv2 Textual Conventions February 2014
148.5. TransportAddressIPv6
Represents a transport address consisting of an IPv6
address and a port number (as used for example by UDP,
TCP and SCTP):
octets contents encoding
1-16 IPv6 address network-byte order
17-18 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
148.6. TransportAddressIPv4z
Represents a transport address consisting of an IPv4
address, a zone index and a port number (as used for
example by UDP, TCP and SCTP):
octets contents encoding
1-4 IPv4 address network-byte order
5-8 zone index network-byte order
9-10 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
148.7. TransportAddressIPv6z
Expires August 17, 2014 [Page 304]
Internet-Draft SMIv2 Textual Conventions February 2014
Represents a transport address consisting of an IPv6
address, a zone index and a port number (as used for
example by UDP, TCP and SCTP):
octets contents encoding
1-16 IPv6 address network-byte order
17-20 zone index network-byte order
21-22 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
148.8. TransportAddressLocal
Represents a POSIX Local IPC transport address:
octets contents encoding
all POSIX Local IPC address string
The Posix Local IPC transport domain subsumes UNIX domain
sockets.
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
When this textual convention is used as a 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-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers.
148.9. TransportAddressDns
Expires August 17, 2014 [Page 305]
Internet-Draft SMIv2 Textual Conventions February 2014
Represents a DNS domain name followed by a colon ':'
(ASCII character 0x3A) and a port number in ASCII.
The name SHOULD be fully qualified whenever possible.
Values of this textual convention are not directly useable as
transport-layer addressing information, and require runtime
resolution. As such, applications that write them must be
prepared for handling errors if such values are not
supported, or cannot be resolved (if resolution occurs at the
time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may
have TransportAddressDns values must fully describe how (and
when) such names are to be resolved to IP addresses and vice
versa.
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
When this textual convention is used as a 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-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers.
149. TRIP-TC-MIB (revision 2004-09-02 00:00)
Initial version of TRIP (Telephony Routing Over IP) MIB Textual
Conventions module used by other TRIP-related MIB Modules. Copyright
(C) The Internet Society (2004). This version of this MIB module is
part of RFC 3872, see the RFC itself for full legal notices.
149.1. TripItad
The values for identifying the IP Telephony
Administrative Domain (ITAD).
Expires August 17, 2014 [Page 306]
Internet-Draft SMIv2 Textual Conventions February 2014
149.2. TripId
The TRIP Identifier uniquely identifies a LS within its
ITAD. It is a 4 octet unsigned integer that may, but not
necessarily, represent the IPv4 address of a Location
Server. Where bytes 1-4 of the Unsigned32 represent
1-4 bytes of the IPv4 address in network-byte order. For
an IPv6 network, TripId will not represent the IPv6
address.
149.3. TripAddressFamily
A type of address for a TRIP route. Address families
defined within this MIB module are:
Code Address Family
1 Decimal Routing Numbers
2 PentaDecimal Routing Numbers
3 E.164 Numbers
255 An other type of address family
149.4. TripAppProtocol
The application protocol used for communication with TRIP
Location Servers. Protocols defined in this MIB Module
are:
Code Protocol
1 SIP
2 H.323-H.225.0-Q.931
3 H.323-H.225.0-RAS
4 H.323-H.225.0-Annex-G
255 An other type of application protocol
149.5. TripCommunityId
The range of legal values for a TRIP Community
Identifier.
149.6. TripProtocolVersion
The version number of the TRIP protocol.
Expires August 17, 2014 [Page 307]
Internet-Draft SMIv2 Textual Conventions February 2014
149.7. TripSendReceiveMode
The operational mode of the TRIP application. Possible
values are:
1 - Send Receive mode
2 - Send only mode
3 - Receive Only mode
150. UPS-MIB (revision 1994-02-23 00:00)
The MIB module to describe Uninterruptible Power Supplies.
150.1. PositiveInteger
This data type is a non-zero and non-negative value.
150.2. NonNegativeInteger
This data type is a non-negative value.
151. URI-TC-MIB (revision 2007-09-10 00:00)
This MIB module defines textual conventions for representing URIs, as
defined by RFC 3986 STD 66.
151.1. Uri
Expires August 17, 2014 [Page 308]
Internet-Draft SMIv2 Textual Conventions February 2014
A Uniform Resource Identifier (URI) as defined by STD 66.
Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII
encoding, and MUST be normalized as described by RFC 3986
Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary
percent-encoding is removed, and all case-insensitive
characters are set to lowercase except for hexadecimal
digits, which are normalized to uppercase as described in
Section 6.2.2.1.
The purpose of this normalization is to help provide unique
URIs. Note that this normalization is not sufficient to
provide uniqueness. Two URIs that are textually distinct
after this normalization may still be equivalent.
Objects using this TEXTUAL-CONVENTION MAY restrict the
schemes that they permit. For example, 'data:' and 'urn:'
schemes might not be appropriate.
A zero-length URI is not a valid URI. This can be used to
express 'URI absent' where required, for example when used
as an index field.
Where this TEXTUAL-CONVENTION is used for an index field,
it MUST be subtyped to restrict its length. There is an
absolute limit of 128 subids for an OID, and it is not
efficient to have OIDs whose length approaches this
limit.
151.2. Uri255
Expires August 17, 2014 [Page 309]
Internet-Draft SMIv2 Textual Conventions February 2014
A Uniform Resource Identifier (URI) as defined by STD 66.
Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII
encoding, and MUST be normalized as described by RFC 3986
Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary
percent-encoding is removed, and all case-insensitive
characters are set to lowercase except for hexadecimal
digits, which are normalized to uppercase as described in
Section 6.2.2.1.
The purpose of this normalization is to help provide unique
URIs. Note that this normalization is not sufficient to
provide uniqueness. Two URIs that are textually distinct
after this normalization may still be equivalent.
Objects using this TEXTUAL-CONVENTION MAY restrict the
schemes that they permit. For example, 'data:' and 'urn:'
schemes might not be appropriate.
A zero-length URI is not a valid URI. This can be used to
express 'URI absent' where required, for example when used
as an index field.
STD 66 URIs are of unlimited length. Objects using this
TEXTUAL-CONVENTION impose a length limit on the URIs that
they can represent. Where no length restriction is
required, objects SHOULD use the 'Uri' TEXTUAL-CONVENTION
instead. Objects used as indices SHOULD subtype the 'Uri'
TEXTUAL-CONVENTION.
151.3. Uri1024
Expires August 17, 2014 [Page 310]
Internet-Draft SMIv2 Textual Conventions February 2014
A Uniform Resource Identifier (URI) as defined by STD 66.
Objects using this TEXTUAL-CONVENTION MUST be in US-ASCII
encoding, and MUST be normalized as described by RFC 3986
Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary
percent-encoding is removed, and all case-insensitive
characters are set to lowercase except for hexadecimal
digits, which are normalized to uppercase as described in
Section 6.2.2.1.
The purpose of this normalization is to help provide unique
URIs. Note that this normalization is not sufficient to
provide uniqueness. Two URIs that are textually distinct
after this normalization may still be equivalent.
Objects using this TEXTUAL-CONVENTION MAY restrict the
schemes that they permit. For example, 'data:' and 'urn:'
schemes might not be appropriate.
A zero-length URI is not a valid URI. This can be used to
express 'URI absent' where required, for example when used
as an index field.
STD 66 URIs are of unlimited length. Objects using this
TEXTUAL-CONVENTION impose a length limit on the URIs that
they can represent. Where no length restriction is
required, objects SHOULD use the 'Uri' TEXTUAL-CONVENTION
instead. Objects used as indices SHOULD subtype the 'Uri'
TEXTUAL-CONVENTION.
152. UUID-TC-MIB (revision 2013-04-05 00:00)
This MIB module defines TEXTUAL-CONVENTIONs representing Universally
Unique IDentifiers (UUIDs). Copyright (c) 2013 IETF Trust and the
persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
152.1. UUID
Universally Unique Identifier information. The syntax must
Expires August 17, 2014 [Page 311]
Internet-Draft SMIv2 Textual Conventions February 2014
conform to RFC 4122, Section 4.1.
152.2. UUIDorZero
Universally Unique Identifier information. The syntax must
conform to RFC 4122, Section 4.1.
The semantics of the value zero-length OCTET STRING are
object-specific and must therefore be defined as part of
the description of any object that uses this syntax.
153. VDSL2-LINE-TC-MIB (revision 2009-09-30 00:00)
This MIB Module provides Textual Conventions to be used by the VDSL2-
LINE-MIB module for the purpose of managing VDSL2, ADSL, ADSL2, and
ADSL2+ lines. Copyright (c) 2009 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met: - Redistributions of source code must retain the above
copyright notice, this list of conditions and the following
disclaimer. - Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with
the distribution. - Neither the name of Internet Society, IETF or
IETF Trust, nor the names of specific contributors, may be used to
endorse or promote products derived from this software without
specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE
COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This version of
this MIB module is part of RFC 5650; see the RFC itself for full
legal notices.
153.1. Xdsl2Unit
Expires August 17, 2014 [Page 312]
Internet-Draft SMIv2 Textual Conventions February 2014
Identifies a transceiver as being either xTU-C or xTU-R.
A VDSL2/ADSL/ADSL2 or ADSL2+ line consists of two
transceivers: an xTU-C and an xTU-R.
In the case of ADSL/ADSL2 and ADSL2+, those two transceivers are
also called atuc and atur.
In the case of VDSL2, those two transceivers are also called
vtuc and vtur.
Specified as an INTEGER, the two values are:
xtuc(1) -- central office transceiver
xtur(2) -- remote site transceiver
153.2. Xdsl2Direction
Identifies the direction of a band in a VDSL2/ADSL/ADSL2/
ADSL2+ link.
The upstream direction is a transmission from the remote end
(xTU-R) towards the central office end (xTU-C). The downstream
direction is a transmission from the xTU-C towards the xTU-R.
Specified as an INTEGER, the values are defined as
follows:
153.3. Xdsl2Band
Identifies a band in a VDSL2/ADSL/ADSL2/ADSL2+ link.
For a band in the upstream direction, transmission is from the
remote end (xTU-R) towards the central office end (xTU-C).
For a band in the downstream direction, transmission is from
the xTU-C towards the xTU-R.
For ADSL, ADSL2 and ADSL2+, which use a single band in the
upstream direction and a single band
in the downstream direction,
the only relevant values are upstream(1) and downstream(2).
For VDSL2, which uses multiple bands in each transmission
direction, a band in the upstream direction is indicated by any
of us0(3), us1(5), us2(7), us3(9), or us4(11), and a band in
the downstream direction is indicated by any of ds1(4),
ds2(6), ds3(8), or ds4(10).
For VDSL2, the values upstream(1) and downstream(2) may be used
when there is a need to refer to the whole upstream or
downstream traffic (e.g., report the average signal-to-noise
ratio on any transmission direction).
Specified as an INTEGER, the values are defined as
follows:
Expires August 17, 2014 [Page 313]
Internet-Draft SMIv2 Textual Conventions February 2014
153.4. Xdsl2TransmissionModeType
A set of xDSL line transmission modes, with one bit
per mode. The notes (F) and (L) denote Full-Rate and
Lite/splitterless, respectively:
Bit 00 : Regional Std. (ANSI T1.413) (F)
Bit 01 : Regional Std. (ETSI DTS/TM06006) (F)
Bit 02 : G.992.1 POTS non-overlapped (F)
Bit 03 : G.992.1 POTS overlapped (F)
Bit 04 : G.992.1 ISDN non-overlapped (F)
Bit 05 : G.992.1 ISDN overlapped (F)
Bit 06 : G.992.1 TCM-ISDN non-overlapped (F)
Bit 07 : G.992.1 TCM-ISDN overlapped (F)
Bit 08 : G.992.2 POTS non-overlapped (L)
Bit 09 : G.992.2 POTS overlapped (L)
Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L)
Bit 11 : G.992.2 with TCM-ISDN overlapped (L)
Bit 12 : G.992.1 TCM-ISDN symmetric (F) --- not in G.997.1
Bit 13-17: Reserved
Bit 18 : G.992.3 POTS non-overlapped (F)
Bit 19 : G.992.3 POTS overlapped (F)
Bit 20 : G.992.3 ISDN non-overlapped (F)
Bit 21 : G.992.3 ISDN overlapped (F)
Bit 22-23: Reserved
Bit 24 : G.992.4 POTS non-overlapped (L)
Bit 25 : G.992.4 POTS overlapped (L)
Bit 26-27: Reserved
Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F)
Bit 29 : G.992.3 Annex I All-Digital overlapped (F)
Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F)
Bit 31 : G.992.3 Annex J All-Digital overlapped (F)
Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L)
Bit 33 : G.992.4 Annex I All-Digital overlapped (L)
Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1,
wide U/S (F)
Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2,
narrow U/S(F)
Bit 36 : G.992.3 Annex L POTS overlapped, mode 3,
wide U/S (F)
Bit 37 : G.992.3 Annex L POTS overlapped, mode 4,
narrow U/S (F)
Bit 38 : G.992.3 Annex M POTS non-overlapped (F)
Bit 39 : G.992.3 Annex M POTS overlapped (F)
Bit 40 : G.992.5 POTS non-overlapped (F)
Expires August 17, 2014 [Page 314]
Internet-Draft SMIv2 Textual Conventions February 2014
Bit 41 : G.992.5 POTS overlapped (F)
Bit 42 : G.992.5 ISDN non-overlapped (F)
Bit 43 : G.992.5 ISDN overlapped (F)
Bit 44-45: Reserved
Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F)
Bit 47 : G.992.5 Annex I All-Digital overlapped (F)
Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F)
Bit 49 : G.992.5 Annex J All-Digital overlapped (F)
Bit 50 : G.992.5 Annex M POTS non-overlapped (F)
Bit 51 : G.992.5 Annex M POTS overlapped (F)
Bit 52-55: Reserved
Bit 56 : G.993.2 Annex A
Bit 57 : G.993.2 Annex B
Bit 58 : G.993.2 Annex C
Bit 59-63: Reserved
153.5. Xdsl2RaMode
Specifies the rate adaptation behavior for the line.
The three possible behaviors are:
manual (1) - No Rate-Adaptation. The initialization
process attempts to synchronize to a
specified rate.
raInit (2) - Rate-Adaptation during initialization process
only, which attempts to synchronize to a rate
between minimum and maximum specified values.
dynamicRa (3)- Dynamic Rate-Adaptation during initialization
process as well as during Showtime.
153.6. Xdsl2InitResult
Specifies the result of full initialization attempt; the
six possible result values are:
noFail (0) - Successful initialization
configError (1) - Configuration failure
configNotFeasible (2) - Configuration details not supported
commFail (3) - Communication failure
noPeerAtu (4) - Peer ATU not detected
otherCause (5) - Other initialization failure reason
153.7. Xdsl2OperationModes
The VDSL2 management model specified includes an xDSL Mode
object that identifies an instance of xDSL Mode-Specific
PSD Configuration object in the xDSL Line Profile. The
Expires August 17, 2014 [Page 315]
Internet-Draft SMIv2 Textual Conventions February 2014
following classes of xDSL operating mode are defined.
The notes (F) and (L) denote Full-Rate and Lite/splitterless,
respectively:
+-------+--------------------------------------------------+
| Value | xDSL operation mode description |
+-------+--------------------------------------------------+
1 - The default/generic PSD configuration. Default
configuration will be used when no other matching
mode-specific configuration can be found.
2 - Regional Std. (ANSI T1.413) (F)
3 - Regional Std. (ETSI DTS/TM06006) (F)
4 - G.992.1 POTS non-overlapped (F)
5 - G.992.1 POTS overlapped (F)
6 - G.992.1 ISDN non-overlapped (F)
7 - G.992.1 ISDN overlapped (F)
8 - G.992.1 TCM-ISDN non-overlapped (F)
9 - G.992.1 TCM-ISDN overlapped (F)
10 - G.992.2 POTS non-overlapped (L)
11 - G.992.2 POTS overlapped (L)
12 - G.992.2 with TCM-ISDN non-overlapped (L)
13 - G.992.2 with TCM-ISDN overlapped (L)
14 - G.992.1 TCM-ISDN symmetric (F) --- not in G.997.1
15-19 - Unused. Reserved for future ITU-T specification.
20 - G.992.3 POTS non-overlapped (F)
21 - G.992.3 POTS overlapped (F)
22 - G.992.3 ISDN non-overlapped (F)
23 - G.992.3 ISDN overlapped (F)
24-25 - Unused. Reserved for future ITU-T specification.
26 - G.992.4 POTS non-overlapped (L)
27 - G.992.4 POTS overlapped (L)
28-29 - Unused. Reserved for future ITU-T specification.
30 - G.992.3 Annex I All-Digital non-overlapped (F)
31 - G.992.3 Annex I All-Digital overlapped (F)
32 - G.992.3 Annex J All-Digital non-overlapped (F)
33 - G.992.3 Annex J All-Digital overlapped (F)
34 - G.992.4 Annex I All-Digital non-overlapped (L)
35 - G.992.4 Annex I All-Digital overlapped (L)
36 - G.992.3 Annex L POTS non-overlapped, mode 1,
wide U/S (F)
37 - G.992.3 Annex L POTS non-overlapped, mode 2,
narrow U/S(F)
38 - G.992.3 Annex L POTS overlapped, mode 3,
wide U/S (F)
39 - G.992.3 Annex L POTS overlapped, mode 4,
narrow U/S (F)
40 - G.992.3 Annex M POTS non-overlapped (F)
41 - G.992.3 Annex M POTS overlapped (F)
42 - G.992.5 POTS non-overlapped (F)
Expires August 17, 2014 [Page 316]
Internet-Draft SMIv2 Textual Conventions February 2014
43 - G.992.5 POTS overlapped (F)
44 - G.992.5 ISDN non-overlapped (F)
45 - G.992.5 ISDN overlapped (F)
46-47 - Unused. Reserved for future ITU-T specification.
48 - G.992.5 Annex I All-Digital non-overlapped (F)
49 - G.992.5 Annex I All-Digital overlapped (F)
50 - G.992.5 Annex J All-Digital non-overlapped (F)
51 - G.992.5 Annex J All-Digital overlapped (F)
52 - G.992.5 Annex M POTS non-overlapped (F)
53 - G.992.5 Annex M POTS overlapped (F)
54-57 - Unused. Reserved for future ITU-T specification.
58 - G.993.2 Annex A
59 - G.993.2 Annex B
60 - G.993.2 Annex C
153.8. Xdsl2PowerMngState
Objects with this syntax uniquely identify each power
management state defined for the VDSL2/ADSL/ADSL2 or ADSL2+
link.
In VDSL2, only L0 and L3 states are defined.
The possible values are:
l0(1) - L0: Full power. Synchronized and
full transmission (i.e., Showtime).
l1(2) - L1: Low power with reduced net data rate
(for G.992.2 only).
l2(3) - L2: Low power with reduced net data rate
(for G.992.3, G.992.4 and G.992.5).
l3(4) - L3: Idle power management state / No
power.
153.9. Xdsl2ConfPmsForce
Objects with this syntax are configuration parameters
that specify the desired power management state transition
for the VDSL2/ADSL/ADSL2 or ADSL2+ link.
In VDSL2, only L0 and L3 states are defined:
l3toL0 (0) - Perform a transition from L3 to L0
(Full power management state).
l0toL2 (2) - Perform a transition from L0 to L2
(Low power management state).
l0orL2toL3 (3) - Perform a transition into L3 (Idle
power management state).
Expires August 17, 2014 [Page 317]
Internet-Draft SMIv2 Textual Conventions February 2014
153.10. Xdsl2LinePmMode
Objects with this syntax are configuration parameters
that reference the power modes/states into which the xTU-C or
xTU-R may autonomously transit.
It is a BITS structure that allows control of the following
transit options:
allowTransitionsToIdle (0) - xTU may autonomously transit
to idle (L3) state.
allowTransitionsToLowPower (1)- xTU may autonomously transit
to low-power (L1/L2)
state.
153.11. Xdsl2LineLdsf
Objects with this syntax are configuration parameters
that control the Loop Diagnostic mode for a VDSL2/ADSL/ADSL2
or ADSL2+ link. The possible values are:
inhibit (0) - Inhibit Loop Diagnostic mode
force (1) - Force/Initiate Loop Diagnostic mode
153.12. Xdsl2LdsfResult
Expires August 17, 2014 [Page 318]
Internet-Draft SMIv2 Textual Conventions February 2014
Possible failure reasons associated with performing
Dual Ended Loop Test (DELT) on a DSL line.
Possible values are:
none (1) - The default value in case LDSF was never
requested for the associated line.
success (2) - The recent command completed
successfully.
inProgress (3) - The Loop Diagnostics process is in
progress.
unsupported (4) - The NE or the line card doesn't support
LDSF.
cannotRun (5) - The NE cannot initiate the command, due
to a nonspecific reason.
aborted (6) - The Loop Diagnostics process aborted.
failed (7) - The Loop Diagnostics process failed.
illegalMode (8) - The NE cannot initiate the command, due
to the specific mode of the relevant
line.
adminUp (9) - The NE cannot initiate the command, as
the relevant line is administratively
'Up'.
tableFull (10)- The NE cannot initiate the command, due
to reaching the maximum number of rows
in the results table.
noResources (11)- The NE cannot initiate the command, due
to lack of internal memory resources.
153.13. Xdsl2LineBpsc
Objects with this syntax are configuration parameters
that control the bits per subcarrier measurement for a
VDSL2/ADSL/ADSL2 or ADSL2+ link. The possible values are:
idle (1) - Idle state
measure (2) - Measure the bits per subcarrier
153.14. Xdsl2BpscResult
Expires August 17, 2014 [Page 319]
Internet-Draft SMIv2 Textual Conventions February 2014
Possible failure reasons associated with performing
a bits per subcarrier measurement on a DSL line.
Possible values are:
none (1) - The default value, in case a measurement
was never requested for the associated
line.
success (2) - The recent measurement request completed
successfully.
inProgress (3) - The bits per subcarrier measurement is
in progress.
unsupported (4) - The bits per subcarrier request
mechanism is not supported.
failed (5) - The measurement request has failed and no
results are available.
noResources (6) - The NE cannot initiate the command, due
to lack of internal memory resources.
153.15. Xdsl2LineReset
This type is used to request a line reset to occur.
idle (1) - This state indicates that there is
currently no request for a line reset.
reset (2) - This state indicates that a line reset
request has been issued.
153.16. Xdsl2LineProfiles
Objects with this syntax reference the list of
ITU-T G.993.2 implementation profiles supported by an
xTU, enabled on the VDSL2 line or active on that line.
153.17. Xdsl2LineClassMask
Expires August 17, 2014 [Page 320]
Internet-Draft SMIv2 Textual Conventions February 2014
VDSL2 PSD Mask Class.
The limit Power Spectral Density masks are grouped in
the following PSD mask classes:
Class 998 Annex A: D-32, D-48, D-64, D-128.
Class 997-M1c Annex B: 997-M1c-A-7.
Class 997-M1x Annex B: 997-M1x-M-8, 997-M1x-M.
Class 997-M2x Annex B: 997-M2x-M-8, 997-M2x-A, 997-M2x-M,
997E17-M2x-NUS0, 997E30-M2x-NUS0.
Class 998-M1x Annex B: 998-M1x-A, 998-M1x-B, 998-M1x-NUS0.
Class 998-M2x Annex B: 998-M2x-A, 998-M2x-M, 998-M2x-B,
998-M2x-NUS0, 998E17-M2x-NUS0,
998E17-M2x-NUS0-M, 998E30-M2x-NUS0,
998E30-M2x-NUS0-M.
Class 998ADE-M2x Annex B: Annex B: 998-M2x-A, 998-M2x-M,
998-M2x-B, 998-M2x-NUS0,
998ADE17-M2x-A, 998ADE17-M2x-B,
998ADE17-M2x-NUS0-M,
998ADE30-M2x-NUS0-A,
998ADE30-M2x-NUS0-M.
Class 998-B Annex C: POTS-138b, POTS-276b per C.2.1.1
in G.993.2, TCM-ISDN per C.2.1.2
in G.993.2.
Class 998-CO Annex C: POTS-138co, POTS-276co per C.2.1.1
in G.993.2.
Class HPE-M1 Annex B: HPE17-M1-NUS0, HPE30-M1-NUS0.
153.18. Xdsl2LineLimitMask
The G.993.2 limit PSD mask for each class of profile.
The profiles are grouped in following profile classes:
- Class 8: Profiles 8a, 8b, 8c, 8d.
- Class 12: Profiles 12a, 12b.
- Class 17: Profile 17a.
- Class 30: Profile 30a.
153.19. Xdsl2LineUs0Disable
Indicates if US0 is disabled for each limit PSD mask.
The profiles are grouped in following profile classes:
- Class 8: Profiles 8a, 8b, 8c, 8d.
- Class 12: Profiles 12a, 12b.
- Class 17: Profile 17a.
Expires August 17, 2014 [Page 321]
Internet-Draft SMIv2 Textual Conventions February 2014
- Class 30: Profile 30a.
153.20. Xdsl2LineUs0Mask
The US0 PSD masks to be allowed by the near-end xTU on
the line. This parameter is only defined for G.993.2 Annex A.
It is represented as a bitmap (0 if not allowed and 1 if
allowed) with the following definitions.
153.21. Xdsl2SymbolProtection
This type specifies the minimum impulse noise protection
for the bearer channel if it is transported over DMT symbols
with a subcarrier spacing of 4.3125 kHz.
The possible values are:
'noProtection' (i.e., INP not required), 'halfSymbol' (i.e., INP
length is 1/2 symbol), and 1-16 symbols in steps of 1
symbol.
153.22. Xdsl2SymbolProtection8
This type specifies the minimum impulse noise protection
for the bearer channel if it is transported over DMT symbols
with a subcarrier spacing of 8.625 kHz.
The possible values are:
'noProtection' (i.e., INP not required) and 1-16 symbols in
steps of 1 symbol.
153.23. Xdsl2MaxBer
Objects with this syntax are configuration parameters
that reference the maximum Bit Error Rate (BER).
The possible values are:
eminus3 (1) - Maximum BER=E^-3
eminus5 (2) - Maximum BER=E^-5
eminus7 (3) - Maximum BER=E^-7
153.24. Xdsl2ChInitPolicy
Expires August 17, 2014 [Page 322]
Internet-Draft SMIv2 Textual Conventions February 2014
This syntax serves for channel configuration parameters
that reference the channel initialization policy.
The possible values are:
policy0 (1) - Policy 0 according to the applicable standard.
policy1 (2) - Policy 1 according to the applicable
standard.
153.25. Xdsl2ScMaskDs
Each one of the 4096 bits in this OCTET STRING array
represents the corresponding subcarrier in the downstream
direction.
A bit value of one indicates that a subcarrier is masked.
153.26. Xdsl2ScMaskUs
Each one of the 4096 bits in this OCTET STRING array
represents the corresponding subcarrier in the upstream
direction. A bit value of one indicates that a subcarrier
is masked.
153.27. Xdsl2CarMask
This type defines an array of bands. Each band is
represented by 4 octets and there is a maximum of 32 bands
allowed.
Each band consists of a 16-bit start subcarrier index followed by
a 16-bit stop subcarrier index.
The subcarrier index is an unsigned number in the range 0 to
NSC-1.
153.28. Xdsl2RfiBands
This type defines a subset of downstream PSD mask
breakpoints used to notch radio frequency interference (RFI)
bands.
Each RFI band is represented by 4 octets: a 16-bit start
subcarrier index followed by a 16-bit stop subcarrier
index.
There is a maximum of 16 RFI bands allowed.
The subcarrier index is an unsigned number in the range 0 to
NSC-1.
Expires August 17, 2014 [Page 323]
Internet-Draft SMIv2 Textual Conventions February 2014
153.29. Xdsl2PsdMaskDs
This is a structure that represents up to 32 PSD mask
breakpoints.
Each breakpoint occupies 3 octets: The first
two octets hold the index of the subcarrier associated with the
breakpoint. The third octet holds the PSD reduction at the
breakpoint from 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units
of 0.5 dBm/Hz.
The subcarrier index is an unsigned number in the range 0 to
NSCds-1.
153.30. Xdsl2PsdMaskUs
This is a structure that represents up to 16 PSD mask
breakpoints.
Each breakpoint occupies 3 octets: The first two octets hold the
index of the subcarrier associated with the breakpoint. The
third octet holds the PSD reduction at the breakpoint from 0
(0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of
0.5 dBm/Hz.
The subcarrier index is an unsigned number in the range 0 to
NSCus-1.
153.31. Xdsl2Tssi
This is a structure that represents up to 32 transmit
spectrum shaping (TSSi) breakpoints.
Each breakpoint is a pair of values occupying 3 octets with the
following structure:
First 2 octets - Index of the subcarrier used in the context of
the breakpoint.
Third octet - The shaping parameter at the breakpoint.
The shaping parameter value is in the range 0 to 126 (units of
-0.5 dB). The special value 127 indicates that the subcarrier is
not transmitted.
The subcarrier index is an unsigned number in the range 0 to
NSC-1.
Expires August 17, 2014 [Page 324]
Internet-Draft SMIv2 Textual Conventions February 2014
153.32. Xdsl2LastTransmittedState
This parameter represents the last successful transmitted
initialization state in the last full initialization performed
on the line. States are per the specific xDSL technology and
are numbered from 0 (if G.994.1 is used) or 1 (if G.994.1 is
not used) up to Showtime.
153.33. Xdsl2LineStatus
Objects with this syntax are status parameters
that reflect the failure status for a given endpoint of a
VDSL2/ADSL/ADSL2 or ADSL2+ link.
This BITS structure can report the following failures:
noDefect (0) - This bit position positively reports
that no defect or failure exist.
lossOfFraming (1) - Loss of frame synchronization.
lossOfSignal (2) - Loss of signal.
lossOfPower (3) - Loss of power. Usually this failure may
be reported for CPE units only.
initFailure (4) - Recent initialization process failed.
Never active on xTU-R.
153.34. Xdsl2ChInpReport
This type is used to indicate the method used to compute the
Actual Impulse Noise Protection (ACTINP). If set to
'inpComputedUsingFormula', the ACTINP is computed
according to the INP_no_erasure formula (9.6/G.993.2).
If set to 'inpEstimatedByXtur', the ACTINP is the value
estimated by the xTU receiver.
inpComputedUsingFormula (1) - ACTINP computed using
INP_no_erasure formula.
inpEstimatedByXtur (2) - ACTINP estimated by
the xTU receiver.
153.35. Xdsl2ChAtmStatus
Expires August 17, 2014 [Page 325]
Internet-Draft SMIv2 Textual Conventions February 2014
Objects with this syntax are status parameters that
reflect the failure status for the Transmission Convergence (TC)
layer of a given ATM interface (data path over a VDSL2/ADSL/
ADSL2 or ADSL2+ link).
This BITS structure can report the following failures:
noDefect (0) - This bit position positively
reports that no defect or failure
exists.
noCellDelineation (1) - The link was successfully
initialized, but cell delineation
was never acquired on the
associated ATM data path.
lossOfCellDelineation (2)- Loss of cell delineation on the
associated ATM data path.
153.36. Xdsl2ChPtmStatus
Objects with this syntax are status parameters that
reflect the failure status for a given PTM interface (packet
data path over a VDSL2/ADSL/ADSL2 or ADSL2+ link).
This BITS structure can report the following failures:
noDefect (0) - This bit position positively
reports that no defect or failure exists.
outOfSync (1) - Out of synchronization.
153.37. Xdsl2UpboKLF
Defines the upstream power backoff force mode (UPBOKLF).
The three possible mode values are:
auto(1) - The VDSL Transceiver Unit (VTUs) will
autonomously determine the
electrical length.
override(2) - Forces the VTU-R to use the electrical
length, kl0, of the CO-MIB (UPBOKL) to
compute the UPBO.
disableUpbo(3) - Disables UPBO such that UPBO is not
utilized.
Expires August 17, 2014 [Page 326]
Internet-Draft SMIv2 Textual Conventions February 2014
153.38. Xdsl2BandUs
Each value identifies a specific band in the upstream
transmission direction (excluding the US0 band.).
The possible values that identify a band are as follows:
us1(5) - Upstream band number 1 (US1).
us2(7) - Upstream band number 2 (US2).
us3(9) - Upstream band number 3 (US3).
us4(11) - Upstream band number 4 (US4).
153.39. Xdsl2LinePsdMaskSelectUs
This type is used to define which upstream PSD mask is
enabled. This type is used only for Annexes J and M of ITU-T
Recommendations G.992.3 and G.992.5.
adlu32Eu32 (1), - ADLU-32 / EU-32
adlu36Eu36 (2), - ADLU-36 / EU-36
adlu40Eu40 (3), - ADLU-40 / EU-40
adlu44Eu44 (4), - ADLU-44 / EU-44
adlu48Eu48 (5), - ADLU-48 / EU-48
adlu52Eu52 (6), - ADLU-52 / EU-52
adlu56Eu56 (7), - ADLU-56 / EU-56
adlu60Eu60 (8), - ADLU-60 / EU-60
adlu64Eu64 (9) - ADLU-64 / EU-64
153.40. Xdsl2LineCeFlag
This type is used to enable the use of the optional
cyclic extension values. If the bit is set to '1', the optional
cyclic extension values may be used. Otherwise, the cyclic
extension shall be forced to the mandatory length (5N/32).
enableCyclicExtension (0) - Enable use of optional
Cyclic Extension values.
153.41. Xdsl2LineSnrMode
Expires August 17, 2014 [Page 327]
Internet-Draft SMIv2 Textual Conventions February 2014
This type is used to enable the transmitter-referred
virtual noise. The value of 1, indicates that virtual
noise is disabled. The value of 2, indicates that virtual
noise is enabled.
virtualNoiseDisabled (1) - virtual noise is disabled.
virtualNoiseEnabled (2) - virtual noise is enabled.
153.42. Xdsl2LineTxRefVnDs
This is a structure that represents up to 32 PSD mask
breakpoints.
Each breakpoint occupies 3 octets: The first two octets hold the
index of the subcarrier associated with the breakpoint. The
third octet holds the PSD reduction at the breakpoint from 0
(-140 dBm/Hz) to 200 (-40 dBm/Hz) using units of 0.5 dBm/Hz.
A special value of 255 indicates a noise level of 0 W/Hz.
The subcarrier index is an unsigned number in the range 0 to
NSCds-1.
153.43. Xdsl2LineTxRefVnUs
This is a structure that represents up to 16 PSD mask
breakpoints.
Each breakpoint occupies 3 octets: The first two octets hold the
index of the subcarrier associated with the breakpoint. The
third octet holds the PSD reduction at the breakpoint from 0
(-140 dBm/Hz) to 200 (-40 dBm/Hz) using units of 0.5 dBm/Hz.
A special value of 255 indicates a noise level of 0 W/Hz.
The subcarrier index is an unsigned number in the range 0 to
NSCus-1.
153.44. Xdsl2BitsAlloc
This type specifies an array of nibbles, where each nibble
indicates the bits allocation for a subcarrier.
Each nibble has a value in the range 0 to 15 to indicate
the bits allocation.
153.45. Xdsl2MrefPsdDs
Expires August 17, 2014 [Page 328]
Internet-Draft SMIv2 Textual Conventions February 2014
Objects with this syntax are MEDLEY Reference PSD status
parameters in the downstream direction. This is expressed as
the set of
breakpoints exchanged at initialization.
The OCTET STRING contains up to 48 pairs of values in the
following structure:
Octets 0-1 -- Index of the first subcarrier used in the
context of a first breakpoint.
Octets 2-3 -- The PSD level for the subcarrier indicated
in octets 0-1.
Octets 4-7 -- Same, for a second breakpoint
Octets 8-11 -- Same, for a third breakpoint
And so on until
Octets 188-191 -- Same, for a 48th breakpoint.
The subcarrier index is an unsigned number in the range 0
to NSCds-1.
The PSD level is an integer value in the 0 to 4095 range. It is
represented in units of 0.1 dB offset from -140 dBm/Hz.
153.46. Xdsl2MrefPsdUs
Objects with this syntax are MEDLEY Reference PSD status
parameters in the upstream direction. This is expressed
as the set of
breakpoints exchanged at initialization.
The OCTET STRING contains up to 32 pairs of values in the
following structure:
Octets 0-1 -- Index of the first subcarrier used in the
context of a first breakpoint.
Octets 2-3 -- The PSD level for the subcarrier indicated
in octets 0-1.
Octets 4-7 -- Same, for a second breakpoint
Octets 8-11 -- Same, for a third breakpoint
And so on until
Octets 124-127 -- Same, for a 32nd breakpoint.
The subcarrier index is an unsigned number in the range 0
to NSCus-1.
The PSD level is an integer value in the 0 to 4095 range. It is
represented in units of 0.1 dB offset from -140 dBm/Hz.
154. VDSL-LINE-EXT-SCM-MIB (revision 2005-04-28 00:00)
The VDSL-LINE-MIB found in RFC 3728 defines objects for the
Expires August 17, 2014 [Page 329]
Internet-Draft SMIv2 Textual Conventions February 2014
management of a pair of VDSL transceivers at each end of the VDSL
line. The VDSL-LINE-MIB configures and monitors the line code
independent parameters (TC layer) of the VDSL line. This MIB module
is an optional extension of the VDSL-LINE-MIB and defines objects for
configuration and monitoring of the line code specific (LCS) elements
(PMD layer) for VDSL lines using SCM coding. The objects in this
extension MIB MUST NOT be used for VDSL lines using Multiple Carrier
Modulation (MCM) line coding. If an object in this extension MIB is
referenced by a line which does not use SCM, it has no effect on the
operation of that line. Naming Conventions: Vtuc -- VDSL transceiver
at near (Central) end of line Vtur -- VDSL transceiver at Remote end
of line Vtu -- One of either Vtuc or Vtur Curr -- Current Atn --
Attenuation LCS -- Line Code Specific Max -- Maximum Mgn -- Margin
PSD -- Power Spectral Density Rx -- Receive Snr -- Signal to Noise
Ratio Tx -- Transmit Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC 4069: see the RFC itself
for full legal notices.
154.1. VdslSCMBandId
This data type is used as the syntax for the VDSL SCM Band
Identity. Attributes with this syntax identify the SCM Band
referred to. Specified as an INTEGER, the possible values
are:
optionalBand (1) -- the optional Band range [25kHz - 138kHz]
firstDownstreamBand (2) -- first Downstream Band
firstUpstreamBand (3) -- first Upstream Band
secondDownstreamBand (4) -- second Downstream Band
secondUpstreamBand (5) -- second Upstream Band
thirdDownstreamBand (6) -- third Downstream Band
thirdUpstreamBand (7) -- third Upstream Band
155. VDSL-LINE-MIB (revision 2004-02-19 00:00)
The MIB module defining objects for the management of a pair of VDSL
transceivers at each end of the VDSL line. Each such line has an
entry in an ifTable which may include multiple transceiver lines. An
agent may reside at either end of the VDSL line. However, the MIB is
designed to require no management communication between them beyond
that inherent in the low-level VDSL line protocol. The agent may
monitor and control this protocol for its needs. VDSL lines may
support optional Fast or Interleaved channels. If these are
supported, additional entries corresponding to the supported channels
must be created in the ifTable. Thus a VDSL line that supports both
channels will have three entries in the ifTable, one for each
Expires August 17, 2014 [Page 330]
Internet-Draft SMIv2 Textual Conventions February 2014
physical, fast, and interleaved, whose ifType values are equal to
vdsl(97), fast(125), and interleaved(124), respectively. The
ifStackTable is used to represent the relationship between the
entries. Naming Conventions: Vtuc -- (VTUC) transceiver at near
(Central) end of line Vtur -- (VTUR) transceiver at Remote end of
line Vtu -- One of either Vtuc or Vtur Curr -- Current Prev --
Previous Atn -- Attenuation ES -- Errored Second. SES -- Severely
Errored Second UAS -- Unavailable Second LCS -- Line Code Specific
Lof -- Loss of Frame Lol -- Loss of Link Los -- Loss of Signal Lpr --
Loss of Power xxxs -- Sum of Seconds in which xxx has occured (e.g.,
xxx = Lof, Los, Lpr, Lol) Max -- Maximum Mgn -- Margin Min -- Minimum
Psd -- Power Spectral Density Snr -- Signal to Noise Ratio Tx --
Transmit Blks -- Blocks Copyright (C) The Internet Society (2004).
This version of this MIB module is part of RFC 3728: see the RFC
itself for full legal notices.
155.1. VdslLineCodingType
This data type is used as the syntax for the VDSL Line
Code. Attributes with this syntax identify the line coding
used. Specified as an INTEGER, the three values are:
other(1) -- none of the following
mcm(2) -- Multiple Carrier Modulation
scm(3) -- Single Carrier Modulation
155.2. VdslLineEntity
Identifies a transceiver as being either Vtuc or Vtur.
A VDSL line consists of two transceivers, a Vtuc and a
Vtur. Attributes with this syntax reference the two sides
of a line. Specified as an INTEGER, the two values are:
vtuc(1) -- central site transceiver
vtur(2) -- remote site transceiver
156. VPN-TC-STD-MIB (revision 2005-11-15 00:00)
This MIB contains TCs for VPNs. Copyright (C) The Internet Society
(2005). This version of this MIB module is part of RFC 4265; see the
RFC itself for full legal notices.
Expires August 17, 2014 [Page 331]
Internet-Draft SMIv2 Textual Conventions February 2014
156.1. VPNId
The purpose of a VPN-ID is to uniquely identify a VPN.
The Global VPN Identifier format is:
3 octet VPN Authority, Organizationally Unique Identifier
followed by 4 octet VPN index identifying VPN according
to OUI
156.2. VPNIdOrZero
This textual convention is an extension of the
VPNId textual convention that defines a non-zero-length
OCTET STRING to identify a physical entity. This extension
permits the additional value of a zero-length OCTET STRING.
The semantics of the value zero-length OCTET STRING are
object-specific and must therefore be defined
as part of the description of any object that uses this
syntax. Examples of usage of this extension are
situations where none or all VPN IDs need to be
referenced.
157. VRRP-MIB (revision 2000-03-03 00:00)
This MIB describes objects used for managing Virtual Router
Redundancy Protocol (VRRP) routers.
157.1. VrId
A number which, along with an interface index (ifIndex),
serves to uniquely identify a virtual router on a given VRRP
router. A set of one or more associated addresses is assigned
to a VRID.
158. VRRPV3-MIB (revision 2012-02-13 00:00)
This MIB describes objects used for managing Virtual Router
Redundancy Protocol version 3 (VRRPv3). Copyright (c) 2012 IETF
Trust and the persons identified as authors of the code. All rights
reserved. Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to the
Expires August 17, 2014 [Page 332]
Internet-Draft SMIv2 Textual Conventions February 2014
license terms contained in, the Simplified BSD License set forth in
Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
Documents (http://trustee.ietf.org/license-info). This version of
the MIB module is part of RFC 6527. Please see the RFC for full
legal notices.
158.1. Vrrpv3VrIdTC
The value of the Virtual Router Identifier noted as
(VRID) in RFC 5798. This, along with interface index
(ifIndex) and IP version, serves to uniquely identify
a virtual router on a given VRRP router.
159. WWW-MIB (revision 1999-02-25 14:00)
This WWW service MIB module is applicable to services realized by a
family of 'Document Transfer Protocols' (DTP). Examples of DTPs are
HTTP and FTP.
159.1. WwwRequestType
The WwwRequestType defines the textual identification of
request types used by a document transfer protocol. For
the proper values for a given DTP, refer to the protocol
mappings for that DTP.
159.2. WwwResponseType
The WwwResponseType defines the different response values
used by document transfer protocols. For the proper values
for a given DTP, refer to the protocol mappings for that
DTP.
159.3. WwwOperStatus
The operational status of a WWW service. 'down' indicates
that the service is not available. 'running' indicates
that the service is operational and available. 'halted'
indicates that the service is operational but not
available. 'congested' indicates that the service is
operational but no additional inbound associations can be
accommodated. 'restarting' indicates that the service is
currently unavailable but is in the process of restarting
Expires August 17, 2014 [Page 333]
Internet-Draft SMIv2 Textual Conventions February 2014
and will be available soon.
159.4. WwwDocName
The server relative name of a document. If the URL were
http://www.x.org/standards/search/search.cgi?string=test
then the value of this textual convention would resolve
to '/standards/search/search.cgi'. This textual convention
uses the character set for URIs as defined in RFC 2396
section 2.
160. Security Considerations
None.
Author's Address
Expires August 17, 2014 [Page 334]