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]